You’re not writing code, you’re solving problems

We’re programmers, so writing code is what we do, is it not ? As the title suggests, our job is a bit more complicated than stroking keys on a keyboard in front of a screen all day. If you go beyond programming languages, and frameworks and processes, beyond test suites and sprints and Jira tickets, you will always find a problem that needs to be solved. 

I would say that we, as programmers, are, first and foremost, problem solvers. We take a problem that someone else has and, using all the tools at our disposal, produce a solution.

The software is not the purpose

Let’s get this out of the way first: the software, in and of itself, is not the purpose of our work. The software you write must be connected to a real world problem, otherwise you will be left with a useless, albeit pretty, program. More than this, the software you write should be evaluated, first and foremost, by how well it solves the problem. The software is a tool you use to solve a particular problem. Take the best software you can think of: it’s clean, easy to read and uses all the right patterns in all the right ways. If the software doesn’t do what you need it to do, it’s useless. 

Understand the problem

The very first step of software development should be to understand the problem. Take whatever time necessary to fully understand exactly what you are trying to do. This applies to both small tasks and whole projects. I would argue it applies even more to whole projects. Problems that arise from diligently working on the wrong problem are hard to fix. Most of the time, they involve huge refactorings and scraping large chunks of work (chunks that you spent a lot of time creating). Not to mention the embarrassment you will face when you have to explain to your client why the  whole app is wrong. 

Perfect is the enemy of good enough

Now that I have made my case that you should focus on solving the problem, not to write code, I want to remind you of the Pareto principle, or more commonly known as the 80/20 rule. As programmers, we sometimes get so caught up by a cool problem that we are solving, that we forget ask ourselves “Am I working on the right problem, though?”. From time to time it’s worth to take a break and look at why you are doing what you are doing. Here are a few questions that can help you: How much value is there in solving this? Is there another, quicker, way to do this ? Can I think of an acceptable compromise that would be far easier to implement ? 

These questions are not always something you can solve on your own (unless you’re working on your own project). It’s worth having a chat with the stakeholders and see what they really care about. If you can, gather feedback from your users. More often than not a quick A/B test can go a long way towards answering what should you do next. Experiment and iterate! Your project doesn’t have to be perfect to succeed, it has to be perfectible. 

Choose your battles

Not every problem requires a technological solution. You don’t need an app for every other thing. Everything comes at a cost. The code you write is costing you time and resources (to write and run). In addition, the more code you have, the more code you have to maintain and the bigger the chance something will go wrong. A small manual step in your process can save you a lot of development and a lot of potential problems. Sometimes a manual step is the right way to go, especially at the beginning of your project. It will give you a chance to find out just how important that step is, how often it needs to happen, how much value it adds to your project. In addition, it gives you the time to think about your process in depth, and a manual step can provide you with the flexibility that software cannot. To put it simply, it’s easier to change a process that is done by hand than to update the software to do something new. Netflix, before they were the huge streaming behemoth we know today, started off by manually emailing their subscribers DVD’s. (source)

The best code you can write, is no code at all

As I’m sure you have noticed by now, adding code comes with risks. Sooner or later, bugs will appear. There is a non-linear relation between the number of lines of code you have and the effort involved in maintaining it. To put this on other words: More code means more problems. 

Try to make your code someone else’s problem. I found that usually, time spent looking around for a ready-made solution is time well spent. We have reached a time in software development where you have a library or an API for almost anything. I strongly encourage you to use ready-made solutions for common things: like authentication (auth0 / firebase authentication), payments (stripe seems to be quite popular nowadays). 

In addition, I think it’s worth looking into ready-made solutions for your whole project. Let’s take WordPress for example. This website runs on WordPress, and I got a fully functioning website without writing a single a line of code yet. 

Another interesting project, that seems to be gaining popularity, is webflow. It allows you to quickly build your website using a mostly drag-and-drop interface. 

Further reading

• Jack of all trades — a case for a general programmer
• Things to do when you’re not writing code
• Soft skills do matter