Programming is a very broad field. It’s an umbrella term for hundreds of different activities that millions of programmers do every day. From research to design, from experimentation to code review and debugging, these could all be classified inside of programming. No wonder then, that learning how to program is such a daunting task.

In this article, I split the act of programming into the four main tasks that I perform 80% of the time, and give tips to improve on each on them. By looking at programming with this split, I’m able to realize what areas I’m the weakest at, and focus my efforts on improving that specific area.

Before I tell you what my tasks are though, take a moment to think about yours. How would you break down the act of programming? What tasks do you do often, and which ones do you struggle with the most? Do you most often find yourself reading documentation? Or do you constantly fight with the debugger? Write down the activities that take up most of you programming time.

Go on, do it.

For me, programming is split into 4 major tasks. Most other tasks are either very small, or are there to aid the 4 major tasks. The 4 tasks I do constantly at my job are:

• Design: When I’m trying to define the problem I’m trying to solve and the constraints I have. The goal of this task is to come up with a solution to the problem, and it usually doesn’t involve writing code at all (although it might involve reading very specific sections of code).

• Experimentation: When I’m trying out the solution I designed, and see how it fares in the real world. The goal of this task is to materialize a dirty but working solution, and there is usually some measure of code writing involved (although, the less code, the better).

• Cleanup: When the solution is working but not ready to be reviewed by others, I usually need to spend some amount of time cleaning out all the hacks. The goal of this task is to take a working solution and polish it until it’s production-ready, and there’s usually some measure of planning and some measure of coding involved.

• Debugging: When the solution we implemented is not working as expected, this is the act of figuring out the problem and fixing it. There is usually very little coding involved, but a lot of thinking. The most important part here is to not open the code unless you have a specific hypothesis in mind.

Being aware of what category you are at any given point has the benefit of helping you formulate better questions, and therefore find better answers, quickly. I encourage you to write down your split (or copy mine!). When you’re programming, constantly ask yourself what task are you performing, and what the goal of the task is. If you weren’t doing that before, this will probably skyrocket your productivity (and enjoyment) while coding.

Now that we have a common framework to think about programming, I will expand on each of those core tasks in future posts, and I’ll write about how I’m trying to get better at each of them. If you want to follow along,

I hope it has been useful,

Borja