Skip to Content

How I approach a coding problem


Programming is hard. You are constantly required to deliver high quality solutions with management often not understanding the underlying complexity. What makes this more difficult is that every problem is it’s own little snowflake; being a combination of different factors such as legacy code, time constraints & the person that wrote the broken functionality being on leave this week. To help combat this daily struggle, I’ve adopted a very systematic approach which not only helps to improve the overall quality of what I deliver but also aids in keeping me focused. These steps are:

  • Set the Goal
  • Get a Overview
  • Start Coding
  • Review

Set the Goal

Firstly, I need a clear picture of what I’m trying to achieve. This can be to refactor a certain piece of code, fix a bug, complete a feature etc. This clear picture is essential for focusing and helps prevent myself from going on a refactoring tangent. I usually just write this goal down in a file or on my desk if I’m feeling hardcore.

Get a Overview

This is where people usually start when jumping into a problem. They try to get a overview of the existing code and establish mental models of how everything flows. It is important to take your time here, a wrong model can cause hours of wasted time or even introduce new bugs! Luckily you’re on leave next week so it’s not your problem. Here I just run through the flow in code, however sometimes I find the need to create a visual representation of the problem, for example, a flow diagram.

Start Coding

In a way similar to the scientific method, I attempt to solve the problem by:

  1. Constructing a hypothesis

  2. Testing by experimenting

  3. Analysing the result

After multiple iterations, I would hopefully arrive at a solution. It is okay to get stuck and ask help from team members or the community, creating software is a extremely collaborative process. Just remember to try first!


Okay, so I have a solution, but I don’t stop here. It’s now time to review to ensure quality. This involves me going through a checklist of questions. These are the qualities I would like in the solution. This list is continually updated, but at this stage includes:

  • Did I follow the style guide for the project?

  • Did I keep the solution simple? Not attempting to be too clever?

  • Is the code DRY?

  • Are there any magic number in the code?

  • Are there lengthy conditionals that should be rather stored in a variable?

  • Is there unneeded conditional nesting? Can levels of indentation be removed by exiting functions early or with other strategies?

  • Did I favour immutability & purity?

  • Did I limit the code to one line per thought?

  • For variable & method naming:

  • Did I use intention revealing names?

  • Did I use pronounceable names?

  • Was I consistent with my naming conventions? For example, I either used fetch or retrieve but never both.

  • Did I use obscure language features that could cause problems down the line?

  • Are my functions small, compossible and only do one thing?

  • Did I show the intent of what I’m doing well?

  • Is there dead/commented code I should remove?

  • Did I try to reinvent the wheel or am I using/improving existing abstractions

  • Did I leave the codebase in a better condition than I found it?


Unfortunately, it is not always possible to meet all the points on the list. This can be due to time constraints, but the important part for me is that an effort was made to improve on the solution.

A special thanks to Richard and Pedre for reviewing this post.