Programmer's portrait

Have you ever wondered about features of a programmer that makes one distinctively productive. Maybe you are trying to find out what it is that keeps us from achieving our goals. I bet you have. I do it too. The world is moving and so are our lives. A paradoxical statement is that to embrace the change we have to stop for a moment and conduct a little retrospective of our work. This is when we come up with ideas for improving the daily routine. Most of them are great and might have a valuable impression on our lives, however, their implementation is a troublesome task on its own. After my own retrospective, the decision has emerged that in order to go from goal A to goal B it would be helpful to write down all the most precious hints. So without further ado, let me introduce the features that (in my opinion) help shaping the best programmers.


Lack of organization is a sin not only for programmers but for every person who does not want to waste the time. We love to complain about having too much on our heads. Maybe better organization could help in finding just enough time for something special, whether it is unfinished task in work, an addictive book or just some relaxation. In the name of the KISS principle, to provide myself with the simplest tool for task organization I use Google Calendar (or a sheet of paper). Before start of the day or the day before I try to outline all the tasks that I am about to tackle, review tasks from the previous days or think about their priority. In the best possible scenario this gives great sens of achievement or, if things go badly wrong and you finish up the day with a bag full of unfinished responsibilities, at least you can take advantage of fast feedback on when you are doing something wrong. This also helps in avoiding procrastination because there is always a clear view of what to do at any given time, which is our most valuable resource that we do not want to wast.


When you are a well organized person you probably have some place to keep notes on daily basis. After so many years of studies and work we usually end up with notebooks full of knowledge picked up during laboratories, lectures, etc. When studying there is a clear target - exams. It is worth continuing this habit because, although targets might be less obvious, there is no end in learning. Along with the notes goes the ability to use them effectively. For example, when opening your computer for the next time think about all the steps you have to do before being productive. Maybe they can be automated in some way or the other? Review your bash history, create a script, make notes during the process. After that you probably end up with better work flow and notes that you can come back to at any time for the reuse.

Being stubborn

In the programmers’ work it is common to come across difficulties in terms of problem solving. When there is something wrong with our code we have basically two options. Either we can stubbornly stuck with the problem scratching our had and full of frustration that something is not going the way it should or we could accept the problem, undertake the right distance, consult the problem with our colleagues. Usually the later is more effective and allows resolving issues in the fastest possible way. The next time you are stuck just take a 5 minute break to do something else or grab next task in your task queue.

Strings attached

The title means we should look at things objectively, judging only using facts and choosing always the right tool for the job. On the other side we have a tendency to attach to the tools that we are most comfortable with that we have used in the past repetitively. Of course it is fine as long as we do not overlook the tool that would help us in finding solution for the given problem much faster. This also implies constantly going outside your comfort zone, which might sound not appealing at first but will definitely bring some long term benefits. This is a general remark but in my case it refers to researching new programming languages remembering to find a rational cause for using any given language.

Ctrl + c, ctrl+v

These days there is massive amount of resources that can help us resolving problems. It is sometimes very easy to google a solution to the problem and use the power shortcut to make the program do the things it suppose to. This being said, the help we get now does not justify for lack of understanding of used solutions. Without knowing every action that we take, we are not doing much more than the machines that we are working with. General rule: investigate software internals and take time on understanding the problem.

Teamwork makes the dream work

Programing is a job where most of the time you need 100% focus without any interruptions. Once you grab that state of thinking about nothing more then the problem that is to be solved it is unpleasant to be grabbed out from your thoughts. However, this is not always the case. There are times when things are not going the way we would like them to go. When something like that happens do not hesitate to consult problem with your colleagues. Maybe somebody has already came across the same problem and have already find solution for it.

Work flow automation

A funny definition of a program for people who does not have many things in common with IT might be that a programmer is a person who does “stuff” on computers. As simple as it sounds this reminds me that we should not only create with the help of computers but let the computers do things by itself by automating jobs that we have done more than once in the same manner.


This are all principles that I have learned from others or deducted from my work (they will definitely evolve over time). All of this sounds great but usually the simplest things are the hardest to implement. To bring another source of verification in the form of community feedback I would like to encourage you to share your own features. What do you think about all of this? I am more than interested in reading it all in the comments.