Seven Signs You Won't Become a Programmer

The people who write the code can be divided into two types: coders and programmers. Dmitry Sokolov, co-founder of Alef Development, explains how to distinguish them from each other using examples from working practice, and explains why it is extremely important to love code, try not to use "dirty" programming methods and solve a problem not quickly, but efficiently.

What is the difference?

First, it's worth understanding the terms. Any person whose IQ allows you to engage in intellectual activity can be a coder. He solves a set of typical problems according to the model. In general, this is no more difficult than solving school and college problems in mathematics.

The programmer is a way of thinking. He does not fall into a stupor when faced with a problem, the solution of which he does not know on the fly. The programmer comes up with his own approaches to work and seeks to figure out how all systems and algorithms are arranged from the inside.

The fundamental differences between a programmer and a coder are:

falling in love with business (if a person in his life has not written a single line of code for himself, because he likes it, he is hardly a programmer);

approach to programming as an art (striving to build an architecture that pleases the eye, and finding beautiful solutions to problems, and, most importantly, getting genuine pleasure from this).

Everything else is a consequence of these basic differences:

the programmer looks at any task more broadly, thinking over and providing for all the features, and the coder solves the problem superficially and very rarely looks beyond the formulation;

the programmer is interested in his solution working as best as possible - the coder wants to pass the problem as soon as possible.

For example, we have a task "to make a program that, when a button is pressed, calculates the nearest prime number, starting from the number entered in the input field, and displays it on the screen."

A typical coder's approach is to find the first available prime number search algorithm on the Internet and implement it. Or find ready-made code, add a button, attach click handling to it, check a couple of times. That's it, the program is ready what is a computer engineer.

Possible programmer approach :

find different algorithms for finding prime numbers, study them and choose the most suitable one,

implement it,

implement validation of the entered data and consider an error notification if the number is written in an invalid format,

test the algorithm on a large number of different examples and come to the conclusion that the calculation takes a lot of time for large primes,

add a loading indicator and lock the button to avoid re-clicking.

The programmer will try to avoid solving the problem in "dirty" ways if there is another way out.

Here's a real-life example . In the database of one system, there was an unspoken pattern: object identifiers began with numbers corresponding to the date of their creation (908157567437 - meant that the object was created in 2009, August 15).

This was not a documented feature; such a conclusion could only be drawn from observations. There was no guarantee that it would always work this way. At the same time, there was a reliable opportunity to find out the creation date of an object by referring to another table via a link - this method required more time and effort.

There were people who, due to banal laziness, made reports for many years, using the pattern of coincidence of the first digits of the identifier. In January 2010, this pattern suddenly stopped working, and all dates in the reports began to display incorrectly.

The error happened because people saved time and didn't pull the actual data from the table. A good programmer, on the other hand, cannot sleep well if the problem is solved using assumptions instead of facts.

In this example, the failure was easy to spot and fix. But it so happens that the error does not appear for years, it arises in some difficult case and disappears again, and everyone around is racking their brains about what it was. If such negligence takes place in a program to control a rover, a nuclear power plant reactor or an aircraft autopilot, the price can be very high.

It is important to note the wording "will try to avoid" given in the thesis above. In real life, a good programmer still sometimes resorts to "dirty" solutions, weighing the pros, cons, and the cost of the issue.  

Let's say that a programmer needs a tool to analyze a large amount of specific data one-time. It will take a week of work to develop a beautiful architecture, but you can complete the task in 30 minutes. It will turn out ugly, but the tool will work as it should and will never be needed again. The art of being a good programmer also lies in deliberately violating "beauty" when warranted.