Great Programmers, in my perspective.

It is not enough to know programming languages to be a great programmer — an aptitude is essential.

Curled from Turing

I have worked with different programmers for over four years, and each year, I always find something, a quality, that great programmers have. So I compiled them all:

1. They always write easy-to-understand code. I know there have been arguments regarding whether or not programmers should use comments to explain their code. I, for one, believe that every bit of code (function, in this regard if JavaScript, followed by parentheses ()) can be named so that there’ll be no need to write comments for collaborators to understand what they have written. However, I am not ready for this argument today. Whatever is your preference, make sure you make life easy for people who work with you and those you’d hand over to. The antics between colleagues should not be transcribed in the comments (Yes, I happened to find some) because they only make everything incomprehensible to those who come later if those people move elsewhere. Use descriptive names, usually verbs in the imperative form.
2. Variables have names that are immediately legible and with a precise meaning. File1, File2, 1, and 2 are not suitable even for the Hello World of the Fundamentals of Informatics exams.
3. They do not rewrite 30 times, in 30 consecutive functions, the same “blessed” block of code that always does the same thing. Instead, create a function and call that.
4. They know how to get by. Every five minutes, the neighbor at his/her desk doesn’t bother asking him/her how an X function works or how a Y function works.
5. They constantly question their actions. There is no, “but it works well.” Things have to work because they HAVE to work, not because “this is how it works.”
6. They never say, “it’s bug-free.” Brings a lot of bad luck.
7. They do not say, “it’s impossible to do it.” It can be difficult, it may be that you are unable to do it, but impossible is nothing.
8. They know the real effect of their code on the underlying machine. Therefore, they do not write quadruple grafted for loops unless there is a good reason for doing so.
9. They know how to adapt to new languages. Languages ​​pass. Knowing languages ​​like C and C ++ is like knowing Latin: maybe you don’t need them directly, but they help you learn other languages. The structures are roughly always more or less similar, except in some fields. You are out if the language has passed and you have not adapted.
10. They know structures, and patterns but do not abuse them.
11. They do not say “Ah yes yes!” when you talk to them about new technology, pretending to know it. Being cool is useless. We are in a world where new technologies appear one day and the other.
12. They indent code in a consistent style.
13. They use a convention for naming variables, functions, and classes and respect it throughout the project.
14. Humility is recognizing that one is not born learned and that if the program does not work, it is not the computer’s fault, it is not the customer’s fault, and it is not the fault of a virus. It’s the programmer’s fault. Great programmers never tell the customer, “It works for me.”
15. Extraordinary resourcefulness in trying new tools, without fear of working hard to learn. Better to struggle to learn than to reinvent hot water.
16. They use farsightedness in understanding how the program they are asked to do and complementary wealth in asking customers what they cannot imagine, analyze the problem in advance, and define all the input and output data flows before starting to write the code.
17. From what “beyond” do they go from the assigned task (when the time available allows it): great programmers must be able to see the whole and ask themselves questions that no one cared to ask them.
18. From the kind of bug their code produces: in general, it’s a waste of resources, time, and money, having to send your code back all the time because something doesn’t work. Many programmers do not test their code: they think it will be fine, and, out of laziness, they close the task. In addition, he/she must be able to contextualize the problem, avoiding just fixing the reported bug. If then, with a minimum of reasoning, one can understand that it can lead to other issues, which is the most common mistake that I find. Great programmers still produce BUGs, but not this way.
19. From their interest: having a person who does not think, who is lazy, who does not care what he/she is doing, and who only thinks about disconnecting to start playing, is the most obvious sign that he/she is not a great programmer.
20. From how he/she writes the code: the style he/she uses says it all about a programmer. The code must be ordered, indented, commented, and above all, it must be understandable.
21. From what he/she accepts and quickly learns from his/her mistakes to improve himself/herself: those who take it “personally” or get annoyed and keep making the same mistakes repeatedly are the worst.

Many thanks for riding with me for this long.

Drops Pen.

How about a clap, or two. Nah maybe three?

Kindly join my slack channel, https://join.slack.com/t/jobsmeetdevs/shared_invite/zt-198t6j9l2-kKRbt3VsLz1YMmw3TVq6kw for premium content as I tend to build a bridge across software development and recruiting. A bridge that won’t collapse when you’re on it.