Embrace bored

Be bored.

No news in Facebook news feed
No news in Facebook news feed

Be at peace with your thoughts, and let them consume you. Put down your phone, disconnect from social networks.

Don’t seek stimulation just for the sake of it 

Think about your problems. But don’t dwell on them.

Boredom makes you brilliant. 

Boredom makes you more creative 

Procrastinate. It’s good for you. 

Not working will help you work.

Grab a coffee. 

Smoke a pipe or three.  

In Praise of Boredom – Maria Konnikova

If you’re stuck, get away and think.

Give yourself time. 🕒 It’s a precious gift.

development leadership quickfix ux wtf

De-pluralisation: strategic blinkers

The process of de-pluralisation takes all your existing problems and combines them into one simple manageable problem: “it’s JavaScript”, “it’s Windows”, “it’s the CDO” with a simple manageable solution “kill it”. Like all simple solutions it’s almost always wrong.

“People aren’t complying with our data quality. Users keep putting in wrong email addresses.”

“The new computer system will fix that”

“Users complain that there’s too many steps to sign off expenses”

“Each step will be faster in the new computer system”

“Staff have low job satisfaction”

“New computer system!”

“Our users aren’t interested in that new feature”

“New computer system!”

“We’ve been hacked with a social engineering attack”


Changing one thing is rarely the answer. There are many pain points and problems we all face day to day. It’s tempting to try and fix them all together, but unless you understand why the problem exists and what the parameters are to fix that problem, you can’t fix it.

Sometimes New Computer System (TM) will fix multiple problems, if they’ve been defined and the system has been designed to do so. But don’t expect it to fix everything because it’s new. That’s how to make people disenchanted.

If you think one system will rule them all, you may as well throw your team in the fire now before you waste time and money on a misguided transformation.

development leadership programming

! Not the lazy programmer

There’s been a popular stereotype about good programmers being productively lazy. Automating tasks to avoid work. It’s an easy thing to share but I don’t think it’s quite true. It’s about reducing inefficiency.

It’s not that developers don’t want to work, we want to do interesting work. Not repetitive work, not work that gets binned, not work to make life miserable for ourselves or others, and not work that can be done easier, cheaper and faster in a different way.

At it’s heart, software is a process that turns data, sometimes with human input, into other data, and sometimes into information and insight. Great developers understand processes, sub-processes and the connections between them, and inefficiencies smell. They distract, like a stone in the shoe, or a dam in the river. Sometimes we can quickly throw out the stone and run faster. Sometimes it takes years of rubbing away, fighting the blockages, until the path is clear.

Sometimes we shave yaks (and btw, check out that gif), Not because we’re too lazy to climb the mountain, but because we know we’ll have a better chance of getting there with a warm coat and a good plan.

Don’t be lazy. Be efficient. Be effective. And route around or remove any blockages in the way.

code development leadership programming

Engineers, ethics and scapegoats

Uncle Bob talked about the VW software engineers on his Clean Coder Blog. Go and read it.

There’s two important issues here. One is that the official line is that the engineers acted alone and no-one else knew what they were doing, in any QA, in any road testing, in any future tweak over the many years these cars were for sale. Although I note there’s no suggestion it was an accident, or an oversight, as in other European engineering failures.

So, if we accept this was a deliberate action, and that the engineers were aware of the consequences, at least in terms of the NOx and CO2 outputs in US and EU tests respectively, and this wasn’t a misconfiguration or falsely triggered test mode, then the engineers have some professional ethical questions to answer. I don’t know the full story about the process that led to this software being developed, signed off, and released, but it’s a good time to consider what our ethics should mean.

I hope you would all enforce ethics in your code, and would challenge any questionable decision from within or outwith the team. This is our first duty as professional developers, to ensure the integrity of what we produce, to ensure it meets all legal and appropriate quality standards, and does not mislead.

Unfortunately, it can be easier said than done. Standing up once and saying, this is wrong, can be scary, even when you have documents and a team backing you up, but when time pressure or financial threats hang over a decision, it’s far easier for that fear to turn into inaction or compliance with a bad decision.

So, before you get into that position, review your code of ethics, from your company, and from your professional body (in my case, the BCS Code of Conduct). If your company doesn’t have one, make one. Defer to a professional body if that’s easier, but make sure everyone knows it, and knows that the company will support them if they refuse to do something because it breaches the code.

It’s much harder to be a scapegoat when no code was breached. Take pride in your profession.


Paperless and warning free

there's a dog driving that car?
Do you have a licence

As a quick follow up to my post on the new process for endorsements following the demise of the paper counterpart driving licence.

First, a clarification, the change in the DVLA is for the paper counterpart to the photo id licence, not the paper licence that existed before the photo id licences. Many people will have been switched to photo id by moving house though, so it’s only the hardcore who won’t be included.

I got confirmation from the car hire firm 24 hours in advance that I needed to print out my endorsements sheet, by which point I no longer had access to a working printer, so I was glad I’d tried it beforehand. The guy at the desk noted that it was a new scheme, and also mentioned that if I hadn’t printed it out, they would need to call a DVLA verification phone number which is very busy when it’s not shut. So still a number of teething problems to sort out.

Do if you are hiring a car, get yourself over to dvla in advance (any time within 21 days) and get your endorsement sheet printed. It might just save you from long queues and grumpy car hire staff.

code development programming quickfix

Rabbit Hole Code

In an attempt to steer my referrer logs away from the HTC Hero, I wanted to get back to something I mentioned on Twitter a while back. I want to talk about rabbit holes in your code.

After a while, all code will have at least one rabbit hole in it. You know you’ve found one when a simple looking change starts you scratching a little deeper because the fix isn’t working or there’s a code smell you can’t quite figure out. You peek, you dig, and suddenly you realise that a 5 minute job has taken half a day.

It’s time to step back and evaluate. Take the red pill or the blue pill. Do you paper over the cracks as best as you can or do you find out how deep the rabbit hole goes? Take the first option and you’re taking the technical debt deeper in to the red, but take the second and you run the risk of not fixing bug zero : shipping.

There’s no magic answer to the question. I can’t tell you which pill to take, but please watch out for rabbit holes in your code. Be prepared to deal with them. And be prepared to live with them. Every architecture has pain points that lead to rabbit holes, but some have more than others.

How have you dealt with your rabbit holes?