
7 habits of high-performance programmers
- Transfer
Novice programmers spend a lot of time gaining the knowledge needed to complete the interview. They solve problems and improve their resumes. But the most interesting part begins after the programmer receives the desired position - in some startup, in Google, in Amazon or elsewhere. It often turns out that the knowledge and skills that helped a person find a job do not correspond to what you need to know and be able to perform his daily tasks.
The author of the article, the translation of which we are publishing today, says that the team in which he works was inspired by the story.

TechLead'a about 7 habits of high-performance programmers. The team members decided to express their own thoughts on this issue. Here, in the form of tips, provides an analysis of 7 skills of effective programmers.

Everyone except you writes awful code. That is why the ability of a programmer to work with someone else's code is a valuable skill. This skill gives the one who possesses it a lot of good.
The programmer needs to be able to understand someone else's code. After all, this is his job. It doesn’t matter how confusing such code is or how poorly written it is. By the way, “someone else's code” may be what was written by the programmer himself, say, a year ago.
This skill positively affects the programmer in two ways. Firstly, the ability to read someone else’s code makes it possible to understand how poor-quality code works. Looking through the work of others, you can find out which techniques are workers and which are not. Secondly, and more importantly, it helps to reveal the peculiarities of the perception of someone else’s code by other people, to find out which code is perceived easily and which is difficult.
If you read someone else’s code and find something in it that you don’t like, try not to be silent about it. This will raise your credibility in the eyes of colleagues.
Pay attention to those with whom you work, on how important it is to write code that is easy to maintain, on how important good comments are. This will further strengthen your status in the team.
Your own code should be designed in such a high quality that it would be clear and without documentation. In fact, good programmers do not need to document the code. This is a waste of time, the time that would be better spent on programming and on meetings.
The ability to understand low-quality code, among other things, helps in making changes to such code. Sometimes this means editing code in which someone is not very good at it. For example, one day we came across a script that involved technologies such as PowerShell, Python, and Perl. In Perl, we did not understand very well. However, we managed to understand the project quite deeply, managed to understand the essence of what was happening and make the necessary changes to the code. This became possible due to the fact that we understood the code that we needed to change, including the code of Perl scripts.
The ability to understand someone else's code increases the value of the programmer because he can understand how even sophisticated systems are arranged, such that when you look at them, someone else will simply give up.
There are many skills that take time to master. One of them, which, we are sure, worth mastering, is to develop an understanding of which projects you should not deal with and which projects with a high degree of probability can result in a "race for survival."
In large companies, there are always many projects that programmers are working on. But not all of these projects will be completed. Not all of them will be beneficial. Among them may be those that do not have a commercial meaning (at least for the programmer). Some projects, generally promising ones, may suffer from managerial shortcomings. This does not mean that you should give up some ideas immediately after you realize that you do not agree with those who offer them. However, if the author of the idea cannot clearly explain what benefit the company can bring to the project after its completion, then perhaps such a project is not worth starting.
In addition, some projects may be overly technology-oriented rather than solving a particular problem. This sometimes, even at the very beginning of the work, allows us to understand that the completion of such a project will not bring much benefit.
In order to learn at a glance to recognize unpromising projects, you need to take part in many such projects. Therefore, if you are at the initial stage of a programmer’s career, do not spend too much time trying to assess the prospects of all the projects that get to you. Over time, you will develop an inner instinct, guided by which you can quickly recognize projects that are doomed to failure.

Whatever you work, you cannot do without meetings. This applies to absolutely everyone. The fact is that you need to find a common language with project managers, users, customers. However, meetings have one unpleasant feature: sometimes they suddenly take up almost the entire working day. That is why it is very important to learn to avoid unnecessary meetings. Perhaps it would be better not to “avoid meetings,” but to strive to “control the time spent on meetings.” The purpose of this is to spend time only on those meetings that are really necessary, on those that contribute to the development of projects.
The most common time management method that goes to meetings is to allocate a two-hour block every day, which turns into a continuous meeting. Many set up recurring meetings for the time they consider most appropriate. These meetings are used to discuss work issues.
Another way to manage time is to come to work earlier than others in order to manage your business. For example, we prefer to do just that. And by the way, if you come to the office early, it will be much calmer to work there than usual. Most people coming early are alike. They do this in order to have time to cope with their work. Therefore, they do not interfere with the work of others.
In our case, this is important for individual team members. The fact is that our work takes time to fully concentrate on a certain task. At this time, we do not communicate with anyone. Of course, there are situations when, to solve a problem, you need to discuss it with someone and work together. But after all the questions are resolved, the developer only needs to write code. In general, we are talking about getting into a certain comfort zone in which the programmer can constantly keep in mind everything that is connected with the task he is solving. If he is constantly interrupted, he may have difficulty quickly returning to what he was distracted with.

When you look at some high-class programmers, you get the feeling that they started using GitHub on the very first day of their lives. They understand the meaning of each command and parameter, they easily cope with their affairs.
But others first encounter GitHub at their first job. For them, GitHub is a real hell, built from obscure teams and mysterious processes. They are never completely sure of what they are doing. That is why all sorts of "cheat sheets" on GitHub are very popular.
The above is true for any version control system. If it is used correctly, it is very useful. If you use it incorrectly, it terribly interferes with work. A simple PR or commit can easily turn into a nightmare that takes a programmer several hours. This time will be spent on unraveling the intricacies of branches and forks. In addition, if you regularly forget about downloading the latest version of the repository to your machine, you can constantly deal with merge conflicts. There is nothing good about it.
If you need a “cheat sheet” on GitHub - do it.
Learn how to work productively with GitHub. In this case, it does not matter how exactly you achieve this.

Some novice programmers have the following trait: they try, in one project, to realize everything they know. The point here is that they strive to use their knowledge about object-oriented programming, data structures, design patterns, and new technologies in every piece of code they create. This unnecessarily complicates the code due to the fact that with this approach, the programmer’s task can easily be affected by, for example, those design patterns that he has already implemented in practice.
There is a balance between overly complex project structures and simple code. Design patterns and object-oriented programming are designed to simplify code in large-scale projects. However, the more we resort to abstracting and encapsulation, the more black boxes there are in our solutions, the more difficult it is to debug the code for such solutions.
This recommendation, in fact, can be given to anyone - at least a financial analyst, at least a programmer. But it can be noted that there is a feeling that everyone wants something special from technicians. For example, if you are a data analysis engineer, then you may be offered tasks that are much wider than what you are supposed to do. Some teams need some sort of data sample, others need summary data, and others need new pipelines.
It should be noted that the ability to prioritize and the ability to say no can actually be two separate skills. However, these skills are very closely related to each other. Where there is a need for one of them, the second is usually needed. Prioritization is when time is spent only on what has a serious impact on the company. And the ability to say no is a refusal to do the work that someone else should do.
Learning what we are talking about can be difficult, as people often strive to solve every problem that they are set. This is especially true for those who have just unlearned and got their first job. Previously, in their studies, they were given tasks that they coped well with. Now, at work, they expect the same and strive to not disappoint anyone.
Here you need to understand that in large companies there are an infinite number of tasks. The most important thing is to take on only those tasks that can be solved.
There are many skills that are not tested in an interview. They are rarely available at school. Often this situation arises only because of the characteristics of the learning environment, and not because someone does not want to show students the real tasks that they may face in reality.

There is one skill for which it is difficult to organize a test during an interview. Situations in which it is needed are difficult to reproduce while studying. It is about the ability to see the mistakes that the end user of a software system can make. We usually call this "thinking through the use cases of the program."
Actually, this “scenario thinking” is just a rather soft name for what is called “protection from the fool”.
For example, since most of the programmer’s job is to support the code, he often has to change the code, which is closely related to something else. Even a simple change of something requires a search for all those places where it is used. For example, an object, method, API of a certain system can change. If you make an unreasoned change to the system, it can “break” the work of completely unexpected parts of the program. Moreover, we are talking about changes of any scale - even something like a type change in the database.
This skill also includes the ability to find and analyze borderline situations that may arise when working with the system. This also includes the ability to comprehend a high-level decision scheme at the design stage.
This also applies to the development of larger parts of systems, such as modules or microservices. When starting to solve such problems, you need to think about how exactly the entities that you plan to create will be used. You need to think about the scenarios of their misuse, about the various options for their use, and that what you create may be used in completely unobvious at first glance ways.
The process of writing code is only part of the job of solving a certain problem. It’s easy to create a program that works well on your computer. But the code someone else is working with can easily behave quite differently than originally expected. How will the code you write be used in production? What systems will he have to interact with? What processes can it become part of? Wouldn't he seem too primitive and limited to a programmer who would have to support him after a few years? These are very difficult questions.
In this article, we presented you with an overview of 7 skills that are common to high-performance programmers. We hope that you have found among them those that you will want to develop yourself.
Dear readers! What would you advise to master for someone who strives for professionalism in programming?


TechLead'a about 7 habits of high-performance programmers. The team members decided to express their own thoughts on this issue. Here, in the form of tips, provides an analysis of 7 skills of effective programmers.
1. Learn to read someone else's code

Everyone except you writes awful code. That is why the ability of a programmer to work with someone else's code is a valuable skill. This skill gives the one who possesses it a lot of good.
The programmer needs to be able to understand someone else's code. After all, this is his job. It doesn’t matter how confusing such code is or how poorly written it is. By the way, “someone else's code” may be what was written by the programmer himself, say, a year ago.
This skill positively affects the programmer in two ways. Firstly, the ability to read someone else’s code makes it possible to understand how poor-quality code works. Looking through the work of others, you can find out which techniques are workers and which are not. Secondly, and more importantly, it helps to reveal the peculiarities of the perception of someone else’s code by other people, to find out which code is perceived easily and which is difficult.
If you read someone else’s code and find something in it that you don’t like, try not to be silent about it. This will raise your credibility in the eyes of colleagues.
Pay attention to those with whom you work, on how important it is to write code that is easy to maintain, on how important good comments are. This will further strengthen your status in the team.
Your own code should be designed in such a high quality that it would be clear and without documentation. In fact, good programmers do not need to document the code. This is a waste of time, the time that would be better spent on programming and on meetings.
The ability to understand low-quality code, among other things, helps in making changes to such code. Sometimes this means editing code in which someone is not very good at it. For example, one day we came across a script that involved technologies such as PowerShell, Python, and Perl. In Perl, we did not understand very well. However, we managed to understand the project quite deeply, managed to understand the essence of what was happening and make the necessary changes to the code. This became possible due to the fact that we understood the code that we needed to change, including the code of Perl scripts.
The ability to understand someone else's code increases the value of the programmer because he can understand how even sophisticated systems are arranged, such that when you look at them, someone else will simply give up.
2. Develop a flair for unsuccessful projects
There are many skills that take time to master. One of them, which, we are sure, worth mastering, is to develop an understanding of which projects you should not deal with and which projects with a high degree of probability can result in a "race for survival."
In large companies, there are always many projects that programmers are working on. But not all of these projects will be completed. Not all of them will be beneficial. Among them may be those that do not have a commercial meaning (at least for the programmer). Some projects, generally promising ones, may suffer from managerial shortcomings. This does not mean that you should give up some ideas immediately after you realize that you do not agree with those who offer them. However, if the author of the idea cannot clearly explain what benefit the company can bring to the project after its completion, then perhaps such a project is not worth starting.
In addition, some projects may be overly technology-oriented rather than solving a particular problem. This sometimes, even at the very beginning of the work, allows us to understand that the completion of such a project will not bring much benefit.
In order to learn at a glance to recognize unpromising projects, you need to take part in many such projects. Therefore, if you are at the initial stage of a programmer’s career, do not spend too much time trying to assess the prospects of all the projects that get to you. Over time, you will develop an inner instinct, guided by which you can quickly recognize projects that are doomed to failure.
3. Avoid meetings

Whatever you work, you cannot do without meetings. This applies to absolutely everyone. The fact is that you need to find a common language with project managers, users, customers. However, meetings have one unpleasant feature: sometimes they suddenly take up almost the entire working day. That is why it is very important to learn to avoid unnecessary meetings. Perhaps it would be better not to “avoid meetings,” but to strive to “control the time spent on meetings.” The purpose of this is to spend time only on those meetings that are really necessary, on those that contribute to the development of projects.
The most common time management method that goes to meetings is to allocate a two-hour block every day, which turns into a continuous meeting. Many set up recurring meetings for the time they consider most appropriate. These meetings are used to discuss work issues.
Another way to manage time is to come to work earlier than others in order to manage your business. For example, we prefer to do just that. And by the way, if you come to the office early, it will be much calmer to work there than usual. Most people coming early are alike. They do this in order to have time to cope with their work. Therefore, they do not interfere with the work of others.
In our case, this is important for individual team members. The fact is that our work takes time to fully concentrate on a certain task. At this time, we do not communicate with anyone. Of course, there are situations when, to solve a problem, you need to discuss it with someone and work together. But after all the questions are resolved, the developer only needs to write code. In general, we are talking about getting into a certain comfort zone in which the programmer can constantly keep in mind everything that is connected with the task he is solving. If he is constantly interrupted, he may have difficulty quickly returning to what he was distracted with.
4. Master GitHub

When you look at some high-class programmers, you get the feeling that they started using GitHub on the very first day of their lives. They understand the meaning of each command and parameter, they easily cope with their affairs.
But others first encounter GitHub at their first job. For them, GitHub is a real hell, built from obscure teams and mysterious processes. They are never completely sure of what they are doing. That is why all sorts of "cheat sheets" on GitHub are very popular.
The above is true for any version control system. If it is used correctly, it is very useful. If you use it incorrectly, it terribly interferes with work. A simple PR or commit can easily turn into a nightmare that takes a programmer several hours. This time will be spent on unraveling the intricacies of branches and forks. In addition, if you regularly forget about downloading the latest version of the repository to your machine, you can constantly deal with merge conflicts. There is nothing good about it.
If you need a “cheat sheet” on GitHub - do it.
Learn how to work productively with GitHub. In this case, it does not matter how exactly you achieve this.
5. Write simple code that is easy to maintain

Some novice programmers have the following trait: they try, in one project, to realize everything they know. The point here is that they strive to use their knowledge about object-oriented programming, data structures, design patterns, and new technologies in every piece of code they create. This unnecessarily complicates the code due to the fact that with this approach, the programmer’s task can easily be affected by, for example, those design patterns that he has already implemented in practice.
There is a balance between overly complex project structures and simple code. Design patterns and object-oriented programming are designed to simplify code in large-scale projects. However, the more we resort to abstracting and encapsulation, the more black boxes there are in our solutions, the more difficult it is to debug the code for such solutions.
6. Learn to say no and prioritize
This recommendation, in fact, can be given to anyone - at least a financial analyst, at least a programmer. But it can be noted that there is a feeling that everyone wants something special from technicians. For example, if you are a data analysis engineer, then you may be offered tasks that are much wider than what you are supposed to do. Some teams need some sort of data sample, others need summary data, and others need new pipelines.
It should be noted that the ability to prioritize and the ability to say no can actually be two separate skills. However, these skills are very closely related to each other. Where there is a need for one of them, the second is usually needed. Prioritization is when time is spent only on what has a serious impact on the company. And the ability to say no is a refusal to do the work that someone else should do.
Learning what we are talking about can be difficult, as people often strive to solve every problem that they are set. This is especially true for those who have just unlearned and got their first job. Previously, in their studies, they were given tasks that they coped well with. Now, at work, they expect the same and strive to not disappoint anyone.
Here you need to understand that in large companies there are an infinite number of tasks. The most important thing is to take on only those tasks that can be solved.
There are many skills that are not tested in an interview. They are rarely available at school. Often this situation arises only because of the characteristics of the learning environment, and not because someone does not want to show students the real tasks that they may face in reality.
7. Learn to think about how your development will be used.

There is one skill for which it is difficult to organize a test during an interview. Situations in which it is needed are difficult to reproduce while studying. It is about the ability to see the mistakes that the end user of a software system can make. We usually call this "thinking through the use cases of the program."
Actually, this “scenario thinking” is just a rather soft name for what is called “protection from the fool”.
For example, since most of the programmer’s job is to support the code, he often has to change the code, which is closely related to something else. Even a simple change of something requires a search for all those places where it is used. For example, an object, method, API of a certain system can change. If you make an unreasoned change to the system, it can “break” the work of completely unexpected parts of the program. Moreover, we are talking about changes of any scale - even something like a type change in the database.
This skill also includes the ability to find and analyze borderline situations that may arise when working with the system. This also includes the ability to comprehend a high-level decision scheme at the design stage.
This also applies to the development of larger parts of systems, such as modules or microservices. When starting to solve such problems, you need to think about how exactly the entities that you plan to create will be used. You need to think about the scenarios of their misuse, about the various options for their use, and that what you create may be used in completely unobvious at first glance ways.
The process of writing code is only part of the job of solving a certain problem. It’s easy to create a program that works well on your computer. But the code someone else is working with can easily behave quite differently than originally expected. How will the code you write be used in production? What systems will he have to interact with? What processes can it become part of? Wouldn't he seem too primitive and limited to a programmer who would have to support him after a few years? These are very difficult questions.
Summary
In this article, we presented you with an overview of 7 skills that are common to high-performance programmers. We hope that you have found among them those that you will want to develop yourself.
Dear readers! What would you advise to master for someone who strives for professionalism in programming?
