You do not want to think like a programmer

From the translator:

I am the technical leader of Bookmate. The most important thing for me is to gather such guys with whom I don’t have to act as a regular translator from business to programmer. Life is too short for that.
This article was thrown to me by Alex Gusev - a person from whom I learned a lot and continue to learn every working day. Thank you, Alex!
He threw the link in Skype with the words "wow, dude wrote my manifesto."
And I totally agree with him.

———————

Teaching you to think like a programmer - often introductory books and programming courses indicate their purpose in this way. Of course, this is better than too narrow a “teach Java”. Do not take it literally. A more honest and accurate wording would be to “teach analytically to decompose tasks”. But let this initial, curved sequence of words - “think like a programmer” - serve as a warning and a reminder.
')
After all, in fact, you do not want to think like a programmer.


It all starts small when you first learn good coding practices. Never use global variables - pack all data into objects. Write getters and setters to hide the internal representation of the data. Use const wherever possible. Only one class declaration per file, please. Format the source code so that it is convenient to read and understand others. Take the time to align the equal signs so that you get beautiful, neat columns.

Over time, this develops into thinking in the programming and quoting patterns of “Perfect Code”. All these people who do not understand want you to add features that are difficult to embed in your beautiful architecture. Do they not understand that complexity is the enemy? You come to the realization that every time a useful program is written in Perl or PHP is a shame for all computer science. Lisp is the right way to go and should be used even if you do not have access to most of the libraries that make Python such an essential tool. Once you start proving that static typing is better than dynamic typing, and preach TDD, then that's all gone.

All this is not so bad in itself, but all together it captures your mind. You have to be crazy about the domain in which you are working - how to make a game without these boring tutorials, which is the most expressive set of tools for a photo application - and not from these endless "programmer" thoughts.

I often see people trying to learn how to do something (websites, computer games or, for example, write songs), simply successfully completing a project for a project every day / week / month. I adore this way! It is absolutely direct, exciting and inspirational. This is a great learning path! The first projects are all about getting something (anything) working. This is followed by the processing of familiar things. Write a snake, for example. Or tetris.

If you have already embarked on such a journey, then the best first step is to research your own ideas. Do not copy what your predecessors copied from those before them. Experiment. Do crazy things. Implementing only what was invented earlier, you make yourself a implementer, an engineer of other people's ideas, a programmer. Use the opportunity to earn the reputation of the creator of the new.

And suddenly you will understand how to code.

PS Translation edited by Vladimir Kharitonov