Learnings part 4

9) Business decisions should not be taken personally.

Getting fired always hurts one way or another. It hurts you – you wont be getting paid for that job any more. It hurts your boss – It isn’t pleasant knowing you are putting someone in that position and it hurts your colleagues.

However, do not to take it personally. The decision should have been made for the good of the company and the company is more important than just a single person (if it isn’t then you have other issues, but we wont dive into that here). Being able to maintain a healthy working environment, with work getting completed and money brought in is the primary need and anything that affects that balance needs to be dealt with even if it does put you in a bad position.

Perhaps it isn’t getting fired, perhaps a change in hours or on call pattern, but whatever they ask you can always say no – you don’t need to suffer in a job.

We live in a world of increased job mobility and it isn’t likely to improve any time soon.

10) Never shit on your peers.

Out of all the start-ups I have worked with/for, the most successful ones were the start-ups with founders/management that weren’t trying to play games to squeeze every little bit of work out of their staff. Get some good will and the staff will do miracles when needed; screw them and they will just do their hours and leave it at that.

The same goes for colleagues. Screw them around too much and they will only do things for you that doesn’t disadvantage them at all.

Learnings part 3

6) You don’t need to suffer in a job

It has taken me a long time to realise it, but the most important things in life are not how much money you bring home or how many hours you spend at work. You wont be lying on your deathbed thinking “I wish I had spent more time at work”.

What is important to you will vary person to person, but I would guess it is likely to be one or more of the following: family, friends, physical health, mental health or perhaps even certain good causes.

As someone who has both been hurt in a car accident and burnt-out and come back, this has been a hard learning experience, but something I do believe.

7) Don’t be afraid of change. Change is where learning happens.

If you do the same tasks the same way every day for 10 years you are unlikely to learn much. To learn you need to be exposed to new ideas and change.

The one thing stops us changing things, and by extension learning, is fear. Fear of the unknown and fear of breaking things. We can solve both of these to some extent by culture.

Pairing up can reduce the fear of the unknown, you have someone else to reassure and provide support when you need it.

Fear of breaking things is harder, but not impossible. Understanding that failures happen no matter what, having processes to deal with failures and not dealing out blame during or after the event all go some way towards making changes less fearful.

8) Don’t be too quick to change something that is working until you understand why it works.

We all understand that change is necessary in business; the outside world isn’t standing still and we need to adapt to these changes. Changing things therefore is an everyday task; a task we need to retain our market fit and to improve the business.

The problem is that if we are too accepting of change that we will continue changing stuff when it doesn’t need it and when doing so will be a detriment to the business.

I have seen this is many places; people that need to change something to feel they have made some input into a problem, people that like to shake things up a little, or even people who like to make others uncomfortable because they can.

The one thing all these have in common is that these are changes without a good reason or a plan. There is no testing and no rationale as to why this is going to be a benefit; it is just a change for change-sake.


Learnings part 2

This post will be a little shorter than the previous one, but I hope you still find some value in it.

3) People will be nice when they perceive things going their way.

Everyone loves good news. It lifts mood and makes them far more hopeful about the future. They tend to also be easier to get along with and more generous in time and money or other resources.

This includes you!

4) Things wont always go your way.

While the old adage ‘make hay while the sun shines’ still holds true. You should also be prepared for times when things aren’t going your way. Hold back some cash. Have a plan B (and plan Z) and just generally keep options open.

5) Great people will help you reach goals even when things aren’t going their way.

The most successful people I have ever met are not the people willing to stab someone in the back to get ahead; it is the type of person who sees you fall and goes out of their way to make sure you are okay.

This produces a lot of goodwill and it tends to come back to them many times. People remember the kind word when they are low and the helping hand when they are on the ground.

Sure, there will be people who try to take advantage of this, but they will be in the minority.

Is coding art?

I was recently asked this question and after lengthy contemplation I have to argue that as most people practice it no, it is not art.

I am not trying to take away from the great works of these people. Far from it. Being ‘art’ is just a label. It doesn’t make it better or worse than anything else.

So why am I stating that most code is not art? It comes down to a few reasons:

  • The act of writing source code is creative, but it is not the finished work.
  • The finished work for most languges (except for raw machine code and some interpreted languages) is not the work of the coder but actually the result of the compiler, the coder generally can’t predict what exact form the output from the input will be, only the function.
  • The only form we can really judge the creator on is the user interface (and perhaps the resource requirements (64k code competitions for example)), but this is very different from putting pigment on canvas or other similar processes we easily define as ‘art’.
  • If we are only able to judge the creators code on the function and not the form, then it isn’t art. It is creative but not art as such.

This last points I think is the important ones. Building architecture is a hybrid of art (form) and engineering (function) and I think we should look at programming from a similar perspective.

Modern architecture uses a lot of computer assistance to design a building; from calculating loads and resource requirements to in some cases designing the actual form of the building itself with only minor tweaks from the architect. This is a very wide range and we accept that (although arguments still exist both ways).

So can programming be art? I think so, especially where the source code itself is the output. Take ‘Obfuscated Perl’ contents as an example. The code is the thing to be admired, the function merely a selection criteria. The ‘Brain fuck’ language is a little less clear cut as the language is still compiled, but the only real use is the challenge of writing or understanding the code. I suppose in this context it could be looked at as performance art, except that generally you are performing alone.

Logitech G510 Keyboard (GB) under Wheezy

My previous keyboard (a cheap and nasty replacement for an IBM Model M) started to die recently.

It wasn’t a massive failure, just some keys not registering first time – not useful when coding where accuracy is important.

So after looking through the options and talking to friends I realised that a great keyboard would set me back well over £100. So I looked for cheaper alternatives.

A friend suggested looking at gaming keyboards. There are a lot of cheap gaming keyboards on the market and most of them are complete crap. One name that has been around for a while and does have some good reviews is Logitech.

After considering the options I settled on a G510 (as there were some cheaper and pristine 2nd hand models on ebay going cheap).


There wasn’t so much of an unboxing as an opening of the reasonably well-packed jiffy bag.

I liked what I saw. So I swapped it out with my old keyboard on my Debian Wheezy workstation.

Suprisingly it worked. Out of the box the media keys and normal keys worked absolutely fine. The display was fixed at g510 in blue and a blue backlight on the keys, but it was a good start. I could live with this level of function worst case.

I initially tried installing the g15daemon and apps. After solving the /dev/input/uinput issue in the initscript and getting a version of the library that supported the g510 we looked like we were getting somewhere. I hit a few stumbling blocks and tried the alternative option…

The Gnome15 project is suprisingly well polished. After adding the repo and installing their gnome-suite-fallback metapackage and rebooting (logout alone didn’t seem to get me all the way there) I had a fully working keyboard. I was suprised; happy but very suprised.

The notification area control app doesn’t have many functions, but it has enough to make it very useful.

Screenshot from 2014-10-09 17:52:40

The first tab controlled the backlight and whether the display cycles between the various enabled plugins.

Screenshot from 2014-10-09 17:52:43

The second controls the various macros (my media profile inherits the macros from the default profile and so has none of its own)

Screenshot from 2014-10-09 17:52:46

…and the third controls which plugins are enabled.

The way I am using it is to have a default profile that only enables a couple of plugins (primarily the pommodoro plugin for coding) and a second profile that I have with my media player displaying on the screen. This seems to work well enough for me to start with.

Overall I am happy with the keyboard. The build quality is good and the key-response while a little spongy is usable. I would certainly be tempted to go up the range a little to get something with better switches as funds allow.

Edited to add:

Low light use

Not massively bright, but certainly enough to code or game by. The monitors kick out a lot of light, but in a terminal session where the screen is mostly black, the backlight is certainly bright enough if you do need to look at the keyboard (like when I am one key out from the home positition).

20141009_183109 20141009_183418



A few months ago I posted a list on twitter about 10 things I have learnt in my career; things that I wish I’d have known at the start of my career.

In the next few posts I will expand on these points.

1) Short term fixes will 90% of the time become long term production processes.

Much as we like to believe that a quick fix will be just that; that we will come back to it when we have time and fix it properly, it is rare we will ever find the time to do so.

This isn’t about intentions or anything else. It simply comes down to two facts:

  • This problem isn’t an irritating enough ‘itch’ any more and so you aren’t compelled to scratch it.
  • Once it is in production it becomes business critical and it becomes far harder to do anything to change it.

This ends up being an excellent argument to fix it right the first time. Alas, in this business driven environment it is hard to commit the resources to doing it right when ‘good enough’ will fit the business need.

2) You will never have full requirements, if you do they are out of date.

TL;DR version: Agile and similar iterative processes are the right way to do things. Business and technology changes too quickly.

When I learnt about Computer Science in the early 90s there was no agile. Waterfall was the normal method taught and people used it – and projects failed.

Not all projects; that would just be silly and not a total failure. Just enough failure to mean that projects didn’t fit the changing business needs particularly well.

With the advent of drag and drop UI builders and languages like VB (much that I hate the language) apps were quicker to develop and fairly consistant in their UI.

Extreme programming and agile was an extension to this. They didn’t have all the answers but they changed the model from upfront design to incremental improvement. You could put a mostly working app in front of a user in a few hours and the user could start to understand what you were describing.

This accelerated the pace of the IT industry. We now see an MVP as an integral part of most startup’s business plan and the only people left doing waterfall or similar development methods are mission critical application developers (flight systems for aircraft and spacecraft, process controllers etc.) and government contractors who are lagging behind the times by about 20 years – although it is nice to see this is changing.

2a) Design with change in mind

This wasn’t in the original set, but I think it is important.

If you design and build tightly coupled systems then sure, you will get maximum performance out of the system. The problem is that changes to the system become difficult; changes to part of the system end up requiring changes elsewhere as the interfaces and data structures change.

With this in mind I tend to recommend loose-coupling using well defined interfaces now. Using interfaces like REST or Message Buses and interchange formats such as JSON (and XML if you really must) you can avoid the need to make changes in multiple places as business requirements change.

Life and Work

I currently have just under a month left before I leave Synety. I haven’t yet got anything concrete lined up, so I am looking at options…

Do I go and work for another startup? Do I start my own startup? Do I go back and do consulting? Do I go corporate again? Do I look at something else?

It is a hard decision and one I am kinda agonising over at present. :(

Mopsa – RIP

Last Friday I was getting Mopsa one of Sam’s owls in from the weathering when we were both startled by one of the ferrets jumping at the bars.

I loosened my grip in that split second as Mopsa baited (tried to take flight) and she was free.

She flew up to the top of the soil stack and refused to come down even when offered food; one of the problems of keep them above flight weight.

She obviously wasn’t that comfortable there as every time she spotted one of the dogs next door she scrunched up and pretended to be a stick.

After about an hour of trying to coax her down she had had enough and flew off.

This was especially worrisome as she still had her jesses and leash attached, making her more prone to entanglement.

I put the word out on the internet and made sure local police were aware but heard nothing until this morning.

I received a call from a local man who said he had found her, but alas not alive.

Up until this moment I had held some small hope that she might come back to us alive.

I slowly walked up the road box in hand to collect her, tears in my eyes and trying not break down crying.

When I spoke to him he said that he had also seen a report of another owl missing in Diseworth (a village or two over) and could I be sure it was our owl?

Hope? Could she still be out there?

This was swiftly dashed.

She had managed to remove both her leash and one of her jesses, but this hadn’t saved her. She had died anyway and been found in a pond.

I now sitting here with tears streaming down my face at the crushing realisation that it was my fault she ended this way; that she died through my stupidity.

RIP Mopsa, you will be missed.


As I walk about the house I can still her her faint ter-wit echoing around.

2014-04-17 19.08.392014-03-20 19.10.57cropped2013-12-22 09.37.26

.UK Registry notice

I just received this notice, it doesn’t affect me directly, but is certainly interesting in that it may mean a lot of premium .uk domains being up for grabs soon…

Nominet, the .UK registry, has introduced a new Data Quality Policy. This policy requires that both the registrant name and address be verified against a third-party data source. For each domain registration or update, Nominet will try to validate the registrant name and address using their own data sources. If Nominet is not able to complete this validation, they will ask the registrar to have the data verified. Domains that do not complete the verification within 30 days will be suspended and can no longer be renewed or transferred.

Nominet will require registrars to enforce this policy starting September 22, 2014.

Thoughts on incubators

I recently saw a video that essentially said that we don’t need incubators anymore; that they don’t really give people what they need; that people can work from their kitchen because they have broadband at home.

I’ve worked for a number of startups, most in places where incubators didn’t have a good foothold, but a couple have gone that route.

I don’t think this is necessarily true that incubators are unneeded anymore. While anyone can get broadband pretty much anywhere, this is not the only thing that an incubator can provide.

An incubator should be providing support, access to potential investors, access to expertise among other things. The absence of any of these things at the right time will reduce the chances of a successful business growing out of your startup. They can increase the chance of success, how much depends on the incubator.

Growing without an ecosystem around you is certainly possible, but you are going to need to search for these needs yourself when you require them.

So is it worth it?

As with all things; it depends. Are you going to benefit from the tech heavy expertise that you will find in an incubator? Do the costs differences between space there and cheaper elsewhere justify the price? From what I have seen, often yes. Is it for everybody? Nope. If you rely on cheaper workers then an incubator heavy area (just like a tech heavy area) will often push the costs up quite markedly. Greater demand but not a massive amount of extra supply.