Skip to content
Home » How to Think Like a Developer

How to Think Like a Developer

It may come as no surprise to you that software development is a complicated and confusing business at the best of times. It is one of the professions that truly sits at the heart of the intersection between maths, engineering, craft and art. This is not to say that all developers are tortured souls who have to express themselves in code. The best ones usually do have highly creative ability which goes along with their more technical side.

Attention to detail is required to make code work ‘right’ for a customer. Detailed work sometimes sits in opposition with the creative instinct. When a customer states a problem to an average developer, the creative part of the developer’s brain likes to start to think about how they can fix that. They like to think of ‘solutions’. A good developer will not jump to a solution or a conclusion about how a problem should be solved until they have more background. And while it’s easy to spend your time looking busy as a developer, resisting the urge to code and to think about a problem in more detail can be hard.

Thinking about a customer problem creates tension. The developer has a new challenge; a problem to solve. They need to make sense of the challenge, write good code, try things out, but at the same time express themselves uniquely in the solution. They also need to balance their creative and practical sides. On top of that they have a manager and a client looking at the clock.

For a developer, thinking about a problem more usually (not always) results in a better solution. However this ‘thinking time’ can appear to everyone else like a waste of time. Managers and customers get edgy if developers are sitting around chewing pencils and blowing off steam at the coffee corner. This can look like inaction whereas it’s really an important part of the creative process.

A developer can’t just spend the whole day coding and thinking. Their brain needs distraction to really get working on a solution. Ask a developer how many times they’ve come up with the solution to a difficult problem in the shower or while out running or even in a dream. This is a real phenomenon and it happens. A lot.

Developers become immersed in problem solving to the point that communication and sometimes ‘normal’ social behaviours can sometimes be difficult. This can sometimes last right up until they crack the code. Then they can relax, the tension dissappears.

So, back to our scenario. The client has tension because they want their new feature. The developer has tension because they are working on it in their heads. Their management has tension because they don’t see much action. How does this work out?

The human solution to solving problems is straightforward and universal. We break a problem down into chunks, and then we tackle the chunks. So how do we solve this thing called ‘tension’? We divide it into areas which we can understand and solve those areas individually.

The software development world first invented Waterfall and then it invented Agile. They are two different approaches with the same goal. They both attempt to solve tension by dividing software development into chunks (in Agile, slightly smaller chunks) both of time but also of desired outcomes. These approaches let us create a window into the developer’s as well as the customer’s minds. Neither of these approaches are perfect but they are there to help all of us to better understand areas of uncertainty and doubt when making software.

Software creation is a collaborative process. Developer, manager, customer. We all need to work together. Waterfall and Agile, project management techniques and the various technical tools we have at our disposal help us make sense of this collaboration but ultimately they only help. 

True understanding that generates trust is the best way to move forward in any software development engagement.