I had an interesting conversation last night about that old bugbear, the annual performance review. No matter how many well-meaning attempts have been made with SMART targets or peer review systems, every annual review I've had or given during my professional career has gone something like this: Here are a »
What has linked all of the high-performing teams and organisations I've worked for or with? That title is a bit of a clue: it's a bias for action. What this means is they believe the way to solve a problem or to improve things is to do something. A team »
I've just finished what was a very rough journey into a fully-automated deployment infrastructure at a large scale. At times it felt more like I was in a bizarre far-future version of a Victorian penny dreadful, complete with roguish charlatans and cliff-hanger disasters. But we battled through it all and »
I've got a confession to make: I secretly enjoy rewriting code when requirements change. I get to think again about what I was doing and my assumptions, tidy up the lingering technical debt, make a few performance optimisations and abstract things a little bit so I don't have to worry »
Here's an article that I found in my backlog, and realised I never got round to publishing. When I wrote it I was thinking predominately about startups, but on reflection there's a lot of relevance to organisations of any size; particularly ones that are going through a lot of change, »
Firefighting is one of the biggest and most common causes of lost productivity and morale in software development. It usually manifests as developers being pulled off their project to urgently fix something - the live site is spewing 500 errors, there's a button in the wrong place, or a senior »