Problem solving lessons relearnt

I've had one of those days. I set out early this morning aware that I had a tough task ahead of me at work. By the end of the day I've made very little progress.

The silly thing is that I know exactly what mistakes I've made today that have hindered my progress and what's worse, I've made the same mistakes before.

Don't spend too long in front of the computer

This might sound a bit daft since you are supposed to be programming and you can't do that unless you are in front of you computer. However, sometimes walking away from the computer for five minutes, and potentially taking your mind off your problem, can really help. Constantly thinking about the same thing can make you mind go stale. You need to freshen up, take some air, have a cup of tea or have a chat with somebody to take your mind off the problem just for a while. All of a sudden an alternative solution might pop into your head. This is just common sense.

My problem was one of threading, which can be tricky domain, and the mistake I made was that I thought the solution was so simple that I threw myself straight into code. After a couple of hours, and little progress, I took a step back and drew a simple diagram to make sure I understood the problem properly. Whilst the act of drawing the diagram didn't shed any light on this occasion it took my eyes off the screen for a moment and changed the way I was thinking about things. In addition, the diagram will be handy when I speak to others about the problem...

Do ask for help

You can do this in a number of ways but the best way is to ask those around you. I'm lucky in that I work at a software house so there are loads of people that I can mosey on up to and chat with about a technical problem and even discuss some ins and outs of the technical detail. If you work on your own or don't work with others that have a similar technical mindset you can see out help and advice from forums, Twitter, email and instant messenger to name but a few. Don't wollow in the same problem for too long without looking for a fresh take on a problem. For me, this is one scenario where pair programming is really useful. By pairing on a problem you are less likely to run out of ideas because you will be constantly talking about the decisions you are making.

Don't decide it needs a complete re-write at 6pm

This is exactly what I did today and I got myself into a right mood. What I generally mean is don't make big decisions or changes right at the end of the day. I didn't get out of work until around 8pm having only partially re-written the code I wanted to. Then, whilst sitting on the train having aired my brain a bit, I decided I didn't actually need to re-write everything. There are still alternative solutions that I've not tried out yet. There are still other reasons why tests might be failing. I've not discussed the problem with others who may come up with a better solution.

Do learn from you mistakes

Today has been an example where it appears that I've not learnt from making similar mistakes in the past. But in actual fact I've probably corrected the mistakes a little quicker than I have previously so I have learnt, I just need to remind myself of these best practices more often. It's not like putting your finger on the tail of a wasp - you may do it once, but never again. The problems I've described here sneak up on you and before you know it you have spent three hours staring at the same area of code without making any progress. Maybe if I then went out and harrassed a wasp I would learn faster?

One of the great things about working in software engineering is that you have the opportunity to be learning nearly all the time. You don't just learn software engineering best practices but also common sense, problem solving best practices. Hopefully next time I'll only waste a fraction of a day before I realise the error of my ways.

Get posts via email

My name is Phil Leggetter. I'm Head of Developer Relations at Nexmo and a real-time web evangelist and consultant.

I frequently write articles and give talks on Realtime Web Technologies and general Web technology. Get in touch if you'd like me to talk at your event or write an article for you. I'm also very interested in developer experience and productivity, APIs and customer service.