7 habits of highly efficient programmers
Novice programmers spend a lot of time gaining the knowledge they need to pass an interview. They solve problems and improve their resumes. But the most interesting begins after the programmer gets the desired position - in some startup, on Google, on Amazon or anywhere else. It often happens that the knowledge and skills that helped a person to find a job do not correspond to what you need to know and be able to perform his everyday 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 TechLead's story about the 7 habits of high-performance programmers. The team members decided to express their own thoughts on this issue. Here, in the form of advice, the analysis of 7 skills of effective programmers is given.
All but you write a terrible 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 another's code. In the end, this is his job. It doesn’t matter how confusing the similar code looks, or how badly it is written. “Alien code”, by the way, may be what was written by the programmer himself, say, a year ago.
This skill positively affects the programmer in two ways. First, the ability to read someone else's code makes it possible to understand how a poor-quality code works. Looking through the work of others, you can find out which techniques are working 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 must be designed so well that it is clear and without documentation. In fact, good programmers have no need to document the code. This is a waste of time, the time that it would be better to spend on programming and holding meetings.
The ability to understand poor-quality code, among other things, helps in making changes to such a code. Sometimes this means editing code in which someone doesn’t understand very well. For example, once we got a script that involved technologies such as PowerShell, Python, and Perl. We didn't understand Perl very well. However, we managed to understand the project deeply enough, managed to understand the essence of what is happening and make the necessary changes to the code. This was 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 over-complex systems are designed, such that when looking at someone else's hands are simply falling.
There are many skills that take time to master. One of them, which, we are sure, is worth mastering, is to develop an understanding of which projects you should not engage in, and which projects are most likely to result in a “race for survival”.
In large companies, there are always many projects on which programmers work. But not all of these projects will be completed. Not all of them will benefit. Among them may be those that do not have a commercial sense (at least - for the programmer). Some projects, in general - promising, may suffer from managerial shortcomings. This does not mean that you should abandon certain ideas immediately after you understand that you do not agree with those who offer them. However, if the author of the idea cannot clearly explain how the company can benefit from the project after its completion, then perhaps such a project is not worth starting.
In addition, some projects may be overly focused on technology, rather than on solving some problem. This sometimes, even at the very beginning of work, makes it clear that the completion of such a project will not be of particular use.
In order to learn at a glance to recognize hopeless 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 projects you receive. Over time, you will develop an internal sense, guided by which you can quickly identify projects that are doomed to failure.
Whoever you work, you can not do without meetings. This applies to absolutely everyone. The fact is that you need to find a common language with project managers, users, clients. 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 that goes to meetings.” The purpose of this is to spend time only on those meetings that are really needed, on those that contribute to the development of projects.
The most common time management method that goes into meetings is that a two-hour block is allocated daily, which turns into a continuous meeting. Many appoint recurring meetings for the time they consider the most appropriate. These meetings are used to discuss business issues.
Another way to manage time is to come to work earlier than others in order to have time to cope with your business. We, for example, prefer to do just that. And by the way, if you come to the office early, it will be much quieter to work there than usual. Most of the people coming early are like each other. 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, work together. But after all 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 all that is connected with the task he solves. If he is constantly interrupted, he may have difficulties with a quick return to what he was distracted by.
When you look at some highly skilled programmers, you get the feeling that they started using GitHub on the first day of their life. 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 incomprehensible commands 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 foregoing holds 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 a few hours. This time will be spent on disentangling 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 the resolution of merge conflicts. There is nothing good about it.
If you need a "cheat sheet" on GitHub - make it.
Learn how to work productively with GitHub. In this case, it does not matter how you achieve it.
Some novice programmers have the following trait: they are trying, in one project, to implement everything they know. The point here is that they strive to use in each fragment of the code they create their knowledge about object-oriented programming, about data structures, about design patterns, and about new technologies. This unnecessarily complicates the code due to the fact that with such an approach the design problems solved by the programmer can easily be affected, for example, by the design patterns that he has already implemented in practice.
There is a balance between too complex project structures and simple code. Design patterns and object-oriented programming are aimed at simplifying code in large-scale projects. However, the more we resort to abstraction and encapsulation, the more black boxes we have in our solutions - the harder it is to debug the code of such solutions.
This recommendation, in fact, can be given to anyone - even a financial analyst, even a programmer. But it can be noted that there is a feeling that everyone wants something special from technical specialists. For example, if you are a data analyst, you may be offered tasks that are much wider than what you are supposed to do. Some teams need some kind of data sampling, others need summary data, and the third need new pipelines.
It should be noted that the ability to prioritize and the ability to say "no", in fact, can be two separate skills. However, these skills are very closely related. Where the need arises for one of them, the second is usually needed. Prioritization is when time is spent only on something that has a major impact on the company. And the ability to say “no” is a refusal to do work that someone else must do.
Learning what we are talking about may not be easy, as people often strive to solve every problem they are given. This is especially true for those who have just graduated and got their first job. Earlier, in school, they were given tasks with which they coped well. Now, at work, they expect the same and strive to not disappoint anyone.
Here we must understand that in large companies there are an infinite number of tasks. The most important thing is to undertake only those tasks that can be solved.
There are many skills for the possession of which is not tested at the interview. They are rarely available at school. Often this situation is only due to the nature of the learning environment, and not due to the fact that someone does not want to show students the real tasks that they may face in reality.
There is one skill, on the possession of which it is difficult to organize a test during an interview. Situations in which it is needed are hard to reproduce while studying. We are talking about the ability to see the errors that can make the end user of the software system. We usually call this “thinking through program usage scenarios.”
In fact, this “thinking through scenarios” is just a rather soft name for what is called “protection against a fool.”
For example, since most of the work of a programmer is to maintain the code, he often has to change code that is closely related to something else. Even a simple change of something requires the search for all those places where it is used. For example, the object, method, API of a certain system can change. If you make an unreasonable change in the system, it can “break” the work of completely unexpected parts of the program. Moreover, we are talking about changes of any scale - even about something like a type change in the database.
This skill also includes the ability to find and analyze borderline situations that may arise while working with the system. This also includes the ability to comprehend a high-level solution scheme at the design stage.
This also applies to the development of larger parts of systems, such as modules or microservices. Starting the decision of similar tasks it is necessary to think of how exactly entities which are going to be created will be used. You need to think about the scenarios of their misuse, about the various uses for them, and that what you create may be used in ways that are completely unobvious at first glance.
The process of writing code is only part of the work to solve a problem. It is easy to create a program that works well on your computer. But the code that someone else works with can easily behave in a completely different way 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? Does it seem too primitive and limited to a programmer who will have to support him in a few years? These are very difficult questions.
In this material, we presented to your attention a review of 7 skills that are characteristic of highly efficient programmers. We hope you have found among them those that you want to develop in yourself.
Dear readers! What advice would you give to someone who aspires to professionalism in programming?
The author of the article, the translation of which we are publishing today, says that the team in which he works was inspired by TechLead's story about the 7 habits of high-performance programmers. The team members decided to express their own thoughts on this issue. Here, in the form of advice, the analysis of 7 skills of effective programmers is given.
1. Learn to read someone else's code.
All but you write a terrible 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 another's code. In the end, this is his job. It doesn’t matter how confusing the similar code looks, or how badly it is written. “Alien code”, by the way, may be what was written by the programmer himself, say, a year ago.
This skill positively affects the programmer in two ways. First, the ability to read someone else's code makes it possible to understand how a poor-quality code works. Looking through the work of others, you can find out which techniques are working 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 must be designed so well that it is clear and without documentation. In fact, good programmers have no need to document the code. This is a waste of time, the time that it would be better to spend on programming and holding meetings.
The ability to understand poor-quality code, among other things, helps in making changes to such a code. Sometimes this means editing code in which someone doesn’t understand very well. For example, once we got a script that involved technologies such as PowerShell, Python, and Perl. We didn't understand Perl very well. However, we managed to understand the project deeply enough, managed to understand the essence of what is happening and make the necessary changes to the code. This was 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 over-complex systems are designed, such that when looking at someone else's hands are simply falling.
2. Develop the sense of unsuccessful projects.
There are many skills that take time to master. One of them, which, we are sure, is worth mastering, is to develop an understanding of which projects you should not engage in, and which projects are most likely to result in a “race for survival”.
In large companies, there are always many projects on which programmers work. But not all of these projects will be completed. Not all of them will benefit. Among them may be those that do not have a commercial sense (at least - for the programmer). Some projects, in general - promising, may suffer from managerial shortcomings. This does not mean that you should abandon certain ideas immediately after you understand that you do not agree with those who offer them. However, if the author of the idea cannot clearly explain how the company can benefit from the project after its completion, then perhaps such a project is not worth starting.
In addition, some projects may be overly focused on technology, rather than on solving some problem. This sometimes, even at the very beginning of work, makes it clear that the completion of such a project will not be of particular use.
In order to learn at a glance to recognize hopeless 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 projects you receive. Over time, you will develop an internal sense, guided by which you can quickly identify projects that are doomed to failure.
3. Avoid meetings
Whoever you work, you can not do without meetings. This applies to absolutely everyone. The fact is that you need to find a common language with project managers, users, clients. 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 that goes to meetings.” The purpose of this is to spend time only on those meetings that are really needed, on those that contribute to the development of projects.
The most common time management method that goes into meetings is that a two-hour block is allocated daily, which turns into a continuous meeting. Many appoint recurring meetings for the time they consider the most appropriate. These meetings are used to discuss business issues.
Another way to manage time is to come to work earlier than others in order to have time to cope with your business. We, for example, prefer to do just that. And by the way, if you come to the office early, it will be much quieter to work there than usual. Most of the people coming early are like each other. 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, work together. But after all 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 all that is connected with the task he solves. If he is constantly interrupted, he may have difficulties with a quick return to what he was distracted by.
4. Master GitHub
When you look at some highly skilled programmers, you get the feeling that they started using GitHub on the first day of their life. 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 incomprehensible commands 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 foregoing holds 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 a few hours. This time will be spent on disentangling 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 the resolution of merge conflicts. There is nothing good about it.
If you need a "cheat sheet" on GitHub - make it.
Learn how to work productively with GitHub. In this case, it does not matter how you achieve it.
5. Write simple code that is easy to maintain.
Some novice programmers have the following trait: they are trying, in one project, to implement everything they know. The point here is that they strive to use in each fragment of the code they create their knowledge about object-oriented programming, about data structures, about design patterns, and about new technologies. This unnecessarily complicates the code due to the fact that with such an approach the design problems solved by the programmer can easily be affected, for example, by the design patterns that he has already implemented in practice.
There is a balance between too complex project structures and simple code. Design patterns and object-oriented programming are aimed at simplifying code in large-scale projects. However, the more we resort to abstraction and encapsulation, the more black boxes we have in our solutions - the harder it is to debug the code of such solutions.
6. Learn to say no and prioritize
This recommendation, in fact, can be given to anyone - even a financial analyst, even a programmer. But it can be noted that there is a feeling that everyone wants something special from technical specialists. For example, if you are a data analyst, you may be offered tasks that are much wider than what you are supposed to do. Some teams need some kind of data sampling, others need summary data, and the third need new pipelines.
It should be noted that the ability to prioritize and the ability to say "no", in fact, can be two separate skills. However, these skills are very closely related. Where the need arises for one of them, the second is usually needed. Prioritization is when time is spent only on something that has a major impact on the company. And the ability to say “no” is a refusal to do work that someone else must do.
Learning what we are talking about may not be easy, as people often strive to solve every problem they are given. This is especially true for those who have just graduated and got their first job. Earlier, in school, they were given tasks with which they coped well. Now, at work, they expect the same and strive to not disappoint anyone.
Here we must understand that in large companies there are an infinite number of tasks. The most important thing is to undertake only those tasks that can be solved.
There are many skills for the possession of which is not tested at the interview. They are rarely available at school. Often this situation is only due to the nature of the learning environment, and not due to the fact that 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, on the possession of which it is difficult to organize a test during an interview. Situations in which it is needed are hard to reproduce while studying. We are talking about the ability to see the errors that can make the end user of the software system. We usually call this “thinking through program usage scenarios.”
In fact, this “thinking through scenarios” is just a rather soft name for what is called “protection against a fool.”
For example, since most of the work of a programmer is to maintain the code, he often has to change code that is closely related to something else. Even a simple change of something requires the search for all those places where it is used. For example, the object, method, API of a certain system can change. If you make an unreasonable change in the system, it can “break” the work of completely unexpected parts of the program. Moreover, we are talking about changes of any scale - even about something like a type change in the database.
This skill also includes the ability to find and analyze borderline situations that may arise while working with the system. This also includes the ability to comprehend a high-level solution scheme at the design stage.
This also applies to the development of larger parts of systems, such as modules or microservices. Starting the decision of similar tasks it is necessary to think of how exactly entities which are going to be created will be used. You need to think about the scenarios of their misuse, about the various uses for them, and that what you create may be used in ways that are completely unobvious at first glance.
The process of writing code is only part of the work to solve a problem. It is easy to create a program that works well on your computer. But the code that someone else works with can easily behave in a completely different way 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? Does it seem too primitive and limited to a programmer who will have to support him in a few years? These are very difficult questions.
Results
In this material, we presented to your attention a review of 7 skills that are characteristic of highly efficient programmers. We hope you have found among them those that you want to develop in yourself.
Dear readers! What advice would you give to someone who aspires to professionalism in programming?
Source: https://habr.com/ru/post/457382/
All Articles