Script Monkey – A day in the life of a coder...

Script Monkey sometimes reflects on roadblocks and issues in order to learn how not to get stuck next time.

I was working away happily on a website, and all was going well. In fact, I was ahead of my time estimate and looking like I might finish the work early, see my kids and enjoy a movie.

All I had to do to finish was insert a class name into some elements using PHP and JavaScript, then I could use a CSS style sheet to change the colour of a box when the user had entered unsuitable data.

This is something I have done many times before, using different languages and approaches. Easy, or so I thought.

I went through the usual processes I follow, but as I had done this so many times before, I skipped a step of hard coding everything first to style it.

I coded the PHP, had data flying around, received the data, processed it and used it to control the content of a web page. Nice... it was mid-afternoon.

What do you do when your code simply refuses to work?

I then spent 3 hours trying to colour in a border around an element with a data error. No matter what I tried or how I debugged, the blooming colour refused to set.

I tried everything; I mean everything.

I got annoyed. This did not help.
I got frustrated. This did not help.
I deleted a bunch of work and re-coded it. This did not help.
I poked the monitor quite hard, and it made some nice patterns. This did not help.
I gibbered and giggled like a loon for a bit. This did not help.
In the end, I gave up, stomped downstairs, and put the kettle on, then sat in the garden. This helped.

Why do experienced coders make beginner mistakes?

As I sat slurping my cuppa, I ruminated on why I could not solve what I had approached as a simple problem. The answer came quite quickly, I had underestimated my opposition. Never underestimate your opposition. In this case, I was my own opposition, or rather my arrogance that I knew everything involved.

I had been trying to style completely the wrong element, but in my locked-in thinking that I knew exactly what to do, I did not stop once to ask myself whether I had made a schoolboy error. As soon as I relaxed, stepped back from the issue, and thought it through, the answer presented itself with immediacy.

Experience is a double-edged sword. It lets you work quickly because you stop thinking about the steps you have taken a hundred times before. But that same autopilot means you stop checking them too. A beginner would have checked which element they were styling, simply because they were not sure. I was sure, and I was wrong.

How do you debug a problem you are too close to?

Since that afternoon, I keep a short list of questions to ask myself whenever a "simple" job starts eating hours:

Am I working on the thing I think I am? Open the browser's developer tools, inspect the element and confirm the class has actually landed where you expect it.
Have I skipped a step? Hard code the end result first. If the box will not turn red with the class typed in by hand, the problem is in the CSS, not the PHP or JavaScript.
Can I explain it out loud? Describe the problem, line by line, to a colleague, a pet or a rubber duck. Mistakes have a habit of revealing themselves halfway through a sentence.
What is the easiest way this should work? Then ask whether you are actually taking that route.

Why does stepping away from a problem work?

It feels like giving up, but walking away is often the fastest route to an answer. When we stare at a problem, our attention narrows onto the approach we have already chosen, and we keep trying variations of the same wrong idea. Relax, and the mind wanders more widely, making connections that tunnel vision shuts out. Many coders will tell you their best fixes arrived in the shower, on a walk or, in my case, in the garden with a cup of tea.

All I had to do was approach the problem logically and by asking myself what the easiest way should have been, then ask myself if I was taking the easy route and the problem resolved. A different perspective, approached calmly and logically and 15 minutes after my cuppa, the site was working and it was dinner and a movie with the kids.

Sometimes the problem is not the code at all. It is the way we have defined the problem. If you enjoy thinking about how we think, you might also like my piece on philosophy in business, or for a more practical fix, how to trap Error 2501 in MS Access.