I’m intending to distribute these incessantly at the DIBI Web Conference, which I’ll be attending and I’m really excited about. You coming too? I for one am not going to miss an opportunity to see Jeffrey Zeldman, Faruk Ateş, Jeremy Keith, Brian Suda and many more.

Blame is the cure, cure anything!

When problems come up, often the first stance we take is to blame the client: “We told him not to do that!”, “Why doesn’t she just leave that alone?”, “How come he’s using that?”. These are typical reactions, especially when we’re close to the end of a project or have been under pressure. When we place blame, we’re immediately shifting responsibility to someone else. If you’re moaning about the client (or whomever you’ve placed the blame on) while working on the problem you don’t truly wish to solve the problem. You’re probably hoping it’ll just go away, get passed onto another developer, or it magically solves itself. Taking responsibility for a problem is the first step in solving it. When a problem comes up, I take responsibility for the solution of the problem, not the problem itself or the cause of it. This frees my mind of blame and the mental baggage it holds. I have a challenge and I’m going for it.

Setting the scene

When it comes to solving the problem, I always try to step back and do a few checks before digging in. How big is the problem? Is this an absolute showstopper, or just a minor irritation? I try not to let the urgency of the problem affect me, either. That can be quite difficult when a site is down, data is corrupt, or something equally critical. I always try to remain cool, stand back and assess the damage. With experience one can start to estimate how long it might take to fix the issue. If it looks like a massive undertaking and the issue is critical, start considering a temporary workaround.

In order to solve a problem efficiently it’s imperative to gather as much information as possible. This includes things like it’s history – “Yes, this also happened a couple of weeks ago!”, any people involved – “Oh, Paul made some changes the other day to the code-base.”, technology used, third party libraries, browsers, etc. I try to establish a decent overview of the whole issue by talking to anyone involved. The one who assigned the problem to you usually doesn’t know the whole story, so instead of trusting that single voice, why not check with a couple of other people? Having three (or more) people explaining the same problem is very useful in pinpointing the source of the problem.

Don’t be afraid to ask questions, even if they might seem basic or silly. More often than not you might be talking to the person who messed up and caused the issue. That person is likely to be on the defensive side so make sure you’re addressing the issue itself, not placing blame or criticising.

In the thick of it

Armed with information, it’s time to start digging. I always try to replicate the issue myself to get a good feel for it. I might prod here and there to see if everything is behaving normally, i.e. remove the css, quick validation, different browsers, check html structure basics (main tags such as html, head, body, form), doctype, etc. This functions as a little sanity check for me. Seemingly huge problems often have the simplest fixes and it’s worth doing a quick sanity check before diving in.

There are many different methods of approaching a problem. My most favoured one is the process of elimination; take something out and see what happens. If nothing happens, take more out, until something does. This way you slowly get closer and closer to the source of the problem. This method doesn’t fit every time, but with front end development I find it to be most efficient. With the process of elimination, ideally you want to start pretty close to the source. This is where the information gathering comes in. The more information you have, the closer you should be to the source of the problem.

One thing I’m not afraid of doing is deleting and starting over again. Sometimes when you’re given a legacy code which would take hours to understand or the function you’re trying to build isn’t working quite right, I’ve found that the quickest solution is to start over again. It takes skill (and a bit of courage) to realise when you’ve reached that stage. If you’ve been building something from scratch for a few hours it can be hard to abandon it. But believe me, it works really well. When you start again with a clean slate (or an empty class), all the thinking you’ve been doing for the past few hours is much more focused and clear. Your code will be leaner, more optimised and faster. With the benefit of hindsight, you might even drop in more comments. Word of advice though – don’t forget to save your previous attempt.

Eureka!

When you reach that wonderful point of spotting the cause of the problem, allow yourself a little internal gloating. I take pride in the process of solving an issue and in the solution itself. After hours and hours of trial and error I find it very satisfying to finally nail it. If people are interested, take time to explain how you found the problem and how you solved it. By doing that you’ll be ticking a few boxes: Committing it better to your memory in more summarised way (helpful if this issue resurfaces), sharing knowledge and teaching others, practicing communication (story-telling) and as a final review of the solution. It’s essential to take time to review the solution you came up with. I’ve discovered in the middle of a narration that my solution wasn’t nearly as water-tight as I thought.

Last thoughts

Building websites is usually the work of many people. That being the case, the issues themselves are also the work of many people. Then it goes without saying that any solution to a problem will be the same. Don’t take a problem and try and solve it in isolation. Even if I’ve taken sole responsibility for the solution I try my best to share it with the rest of the team. With one more problem solved, we’ll all feel like we’re moving forward.