10 differences between a good and a normal programmer

Suppose we have 1 normal programmer and 1 good programmer (2 times more experienced and with a salary 2 times more). Does this mean that a good programmer will write the same program 2 times faster? Or that having a budget of $ 1000, no matter what programmer we give up the work, we get the same program? Or maybe if we hire 2 normal programmers, then they will work as efficiently and quickly as 1 good programmer? No - unfortunately, linear algebra is not applicable to programmers. In this article I will try to explain why it is impossible to add and subtract linearly the experience of programmers.

After all, if programmers could be added and subtracted as apples in elementary mathematics lessons, then everything would be too simple and even uninteresting. There are certain factors that make the difference between apples from math lessons and programmers.

Differences between a good and a normal programmer
If a programmer takes 2 times more money, then it is logical to assume that he is 2 times better. What really stands behind this abstract "better", and how does a good programmer differ from a normal one?

• A good programmer writes code somewhere with the same speed as a normal one (we all poke our fingers on the keyboard with a similar speed). Sometimes it is even slower (often it’s boring for a good programmer to write something trivial, and he can easily be distracted by stimuli).
• But a good programmer has a lot more abilities for abstract design. If you plant 2 ignoramuses to prove the Pythagorean theorem, then they will not prove it. 100 ignoramuses will not prove it in 2 weeks, but 1 educated mathematician will be able to prove it in an hour. A good programmer will also be able to correctly design a program when 2 normal programmers show the worst result (and this result does not depend on the number of programmers, it depends on their quality).
• A good programmer writes more reliable programs. Partly due to the fact that he knows how to design them correctly, partly due to the fact that he just knows how to write code without errors (after all, he is better than the others, after all). Very often this factor comes to the surface only a few months or years later - the program turns out to be confusing and difficult to support. A good programmer is much more likely to prevent this entanglement than a normal programmer.
• 1 good programmer is more productive than 2 normal programmers. In addition to the design and reliability of programs, there is another factor: interpersonal communication. The fewer people form a team, the less time will be spent on internal communication.
• The quality of the programmer is directly proportional to the way he knows how to work with the customer / project manager / any entity that stands above him and who tells him that he needs to program. We all saw this picture, where we designed a swing for children on a tree, and in the end we got something terrible. A good programmer initially lays down the necessary flexibility in his program so that if someone halfway up in the head changes his mind, he can be transferred to a new program without spending a lot of crutches on it. Also a good programmer is able to eliminate misunderstandings. He does not write as he or the customer thought, but he wants a clear idea of ​​the expected result from the client.

Profit from all this
Well, let's say, but how can you benefit from all this? I would personally extract it in the following way:

• In the team of programmers there should be a spread in professionalism. For the success of the company need smart programmers and normal programmers. They are both good and know how to work well together.
  • Smart programmers will solve the most complex tasks and take on the issues of design and overall vision.
  • Normal programmers will perform more routine tasks, but it will be interesting for them, and they will be more productive and financially efficient (why pay a good programmer 1000 for solving this task if a normal programmer for 500U can solve it almost in the same time frame? )
  • As a bonus, smart programmers will develop and raise the qualifications of normal programmers.
  • And one more bonus: everyone will be happy. Good programmers will be satisfied with their work, because they do not need to do routine work, and normal programmers will be happy, because they have the opportunity to learn and grow by looking at their elder brothers.
• Better to take quality than quantity. If I need to increase the speed of development or somehow increase the "resource" of programmers, then I would first of all try to increase the qualifications of programmers, not their number. This way I save on interpersonal communication costs.
• Perhaps this point does not intersect tightly with the above, but I would also pay attention to the effectiveness of each of the team members. Efficiency and professionalism are two different things. Professionalism is potential, and efficiency is how much this potential is revealed. Efficiency depends on various factors:
  • Emotional relationship between team members.
  • External stimuli (noise, hunger, programmer-neighbor, which distracts every half hour, and much more)
  • Interest in the task (any person works less efficiently if he does not internally agree with what is required of him)