Translation of Paul Graham's article on programmer “fads”
At the request of workers - translation of the article by Paul Graham (Paul Graham) 'Holding a Program in One's Head'.
A good programmer who works on his own project can keep it entirely in his head in the way that a mathematician holds an equation that solves. Mathematicians do not solve problems on a piece of paper, just as children learn in school. Instead, most of the operations they perform in the mind, creating a certain image in the head, just like we can mentally imagine the image of the house in which we spent our childhood. With programming, everything is exactly the same. You can create a certain image of the entire current project in your head and examine it carefully from all sides.
This is most often claimed at the initial stage, when one of the most important things is the ability to change what you are doing. Do not just solve the problem in another way, but change its very essence.
')
But to fit the whole program in my head is not so easy. If for any reason you have not accessed the code for several months, it may take up to several days to get into it again. Even when you are actively working on a program, it may take up to half an hour each morning to set up your own consciousness to work on the current task. And this is only at best. Typical office programmers cannot cope with this until the end of the working day. Speaking in another language, a typical office programmer never understands the whole task that he has to solve.
Even the best programmers sometimes do not have a complete presentation of the program in their head. If it seems to you that the latter applies to you, then the following are suggested ways to solve this problem:
1. Get as distracted as possible. Distraction can play a bad role in the work of people in many professions, but this is especially obvious for programmers, who often work with a number of details that have to be remembered, exceeding all conceivable and inconceivable limits.
The consequences of switching attention to an extraneous task depend not so much on its duration, as on the degree of distraction of attention by this task. For example, a programmer can leave the office, have a sandwich while sitting on a bench, without being distracted for a minute at this time from the program he is working on.
Unplanned situations can be especially harmful, which take much more attention than the planned ones, to which the programmer usually does not begin any serious tasks.
2. Work avidly. Because each time before starting work, it is necessary to be drawn into the current task, the obvious solution for minimizing unnecessary costs is long work without significant interruptions. Of course, it is impossible to work endlessly, and in one moment you will realize that you are completely “stupefied” from work. The speed of occurrence of such a state depends solely on the characteristics of a particular person. I heard about people who worked for 36 hours in a row, for days on end. My maximum is 18 hours, but I feel most comfortable with no more than 12 hours running.
The best option is not the one that your physical and, perhaps, psychic abilities allow. Sometimes, when you take a break from work, and then come back, unexpected solutions come to you that were worked out by your brain while your thoughts seemed to be far from the program code.
3. Write in concise languages. Powerful programming languages make your programs shorter. Programmers think about programs, at least in part, in the language in which they are written. The laconic language, the shorter the program, and the easier it is to restore its image in its memory.
You can achieve even greater effect by using an ascending programming style when you write programs consisting of abstract layers, the lower of which create a base and a program shell for the upper ones. If you do it right, you only need to keep in your memory only the topmost layer.
4. Constantly rewrite programs. By rewriting the code, you often improve the architecture of the application. Even if not, there is an advantage: to rewrite the program again, you must fully understand its essence. So you can recreate a more accurate picture of the program in your head.
5. Write code that is convenient for you to read. All programmers know how to write good code that is easy to read. But you yourself are the most important reader of your code. Especially at the beginning of the project; Creating a prototype of the future application is your dialogue with yourself. When you write for yourself, you have completely different priorities. When you write for others, your code can be spread across multiple lines for better readability. When you write code so that it can be easily restored to memory, you would rather prefer brevity.
6. Work in small groups. When you imagine a program in your imagination, you focus on handwritten code, parts written by other people, you don’t understand so well, and you cannot imagine them so vividly. Thus, the fewer programmers working on a project, the more complete you are able to present its image. If you work on it alone, you are capable of anything.
7. Do not allow the same code to be edited by several people. As I said, you can never understand someone else’s code as well as your own. It doesn't matter how carefully you read it, you just read it — you didn't write it. Thus, if a section of code is written by several people, none of them has a complete and complete presentation of it.
And of course, you can not drastically change something in it. Not because you need permission for this, but because you just can not imagine it. Reorganizing code written by several people is like reorganizing the laws of the universe. Reorganizing your own code is just another interpretation of the ambiguous image of the program in your head.
If you need several people to develop one project, divide it into parts and select one for each programmer.
8. Start small. The more thoroughly you study the program, the easier it is for you to create its mental image. You can present the individual parts of the finished program as black boxes performing their functions without going into implementation details until you are ready for this. When you start a new project, you just need to keep it in your head completely. If you start with an overly complex and voluminous task, you will probably never be able to cover it entirely. If you are faced with a similar task, start not with its formal description, but with writing a prototype that solves one of its subtasks. Whatever the benefits of planning, they are often not as significant as the benefits you get from being able to keep the whole project in your head.
It's amazing how often programmers stick to all eight points without even knowing about their existence. When someone has an idea, he has to deal with it outside working hours, as it does not have official support from the management. This leads to more productive work due to the absence of distracting factors. Driven forward with pure enthusiasm, the programmer works all night long. Because his project is purely experimental, he writes code not in languages that are a corporate standard, but in laconic scripting languages. He completely rewrites the program again, which would not have been approved by higher-level people, if it were an official development. But in this case, this is a personal project, and he wants to make it perfect. Given that no one but him will see the code, he writes it as concisely and briefly as possible so that it is easier to take on it after the break. The project employs only a small number of people, even if he writes it and not one, because code changes occur so quickly that there is no possibility to connect someone else to the project.
Finally, he starts small, because his idea was originally really small and modest.
Even more surprising is the number of official projects that somehow manage to break all eight “rules”. Indeed, if you look at software development methods in most organizations, you will see that they are deliberately doing everything wrong on purpose. In a way it is. One of the distinguishing features of organizations is the perception of people as interchangeable parts of a common mechanism. This works well for tasks that allow paralleling of tasks between participants, such as, for example, war. Throughout history, there is not a single mention of a case in which a well-organized army of trained mercenaries would be inferior to an army consisting of independent warriors, no matter how valiant they might be. But the thinking process is not very can be distributed among people. And what is programming, if not the thinking process.
The statement that organizations deny the possibility of being dependent on one brilliant employee is not quite true. Just in our current understanding, organizations by definition should not allow this to happen.
Perhaps we should define a new type of organization that would use the joint activities of individual employees without the need for them to be interchangeable. To some extent, the market can be called an organization of this kind, although a better description would be the description of the market as a degenerate case, of what comes of itself when the organization is inappropriate.
Maybe we should choose a workaround and make programmers work differently from other employees. Probably for large companies the best solution would be not to produce ideas on their own, but to buy them from others. In spite of which solution is appropriate in each particular case, you must first understand the existence of the problem. The very phrase "software development company" is a contradiction. Words seem to repel each other in opposite directions. Any good programmer will feel in someone else's dish, being in a large organization, because organizations are designed to prevent what the programmer is most eager for.
A good programmer somehow does a lot of tasks. However, in many cases for this he has to almost organize an uprising against his own company. This behavior is due to the requirements of his work. Programmers head off into programming, forgetting about their other duties, rush to write code without describing its specifications, rewriting the already working code not because they are irresponsible. They prefer to work alone and are angry at the cheering heads of their colleagues, who occasionally appear from the doorway, not because they are not friendly or closed. This seemingly completely random set of habits in their behavior has a single reason: the need to keep in your head the whole project.
Whether or not understanding this will help big companies, it can certainly help their competitors. The weakest point of such companies is that they do not allow programmers to do meaningful work. If you are a small start-up company, using this you can make them a significant competition. Just take into account the peculiarities of the task that the brain of the programmer must undertake entirely.
A good programmer who works on his own project can keep it entirely in his head in the way that a mathematician holds an equation that solves. Mathematicians do not solve problems on a piece of paper, just as children learn in school. Instead, most of the operations they perform in the mind, creating a certain image in the head, just like we can mentally imagine the image of the house in which we spent our childhood. With programming, everything is exactly the same. You can create a certain image of the entire current project in your head and examine it carefully from all sides.
This is most often claimed at the initial stage, when one of the most important things is the ability to change what you are doing. Do not just solve the problem in another way, but change its very essence.
')
But to fit the whole program in my head is not so easy. If for any reason you have not accessed the code for several months, it may take up to several days to get into it again. Even when you are actively working on a program, it may take up to half an hour each morning to set up your own consciousness to work on the current task. And this is only at best. Typical office programmers cannot cope with this until the end of the working day. Speaking in another language, a typical office programmer never understands the whole task that he has to solve.
Even the best programmers sometimes do not have a complete presentation of the program in their head. If it seems to you that the latter applies to you, then the following are suggested ways to solve this problem:
1. Get as distracted as possible. Distraction can play a bad role in the work of people in many professions, but this is especially obvious for programmers, who often work with a number of details that have to be remembered, exceeding all conceivable and inconceivable limits.
The consequences of switching attention to an extraneous task depend not so much on its duration, as on the degree of distraction of attention by this task. For example, a programmer can leave the office, have a sandwich while sitting on a bench, without being distracted for a minute at this time from the program he is working on.
Unplanned situations can be especially harmful, which take much more attention than the planned ones, to which the programmer usually does not begin any serious tasks.
2. Work avidly. Because each time before starting work, it is necessary to be drawn into the current task, the obvious solution for minimizing unnecessary costs is long work without significant interruptions. Of course, it is impossible to work endlessly, and in one moment you will realize that you are completely “stupefied” from work. The speed of occurrence of such a state depends solely on the characteristics of a particular person. I heard about people who worked for 36 hours in a row, for days on end. My maximum is 18 hours, but I feel most comfortable with no more than 12 hours running.
The best option is not the one that your physical and, perhaps, psychic abilities allow. Sometimes, when you take a break from work, and then come back, unexpected solutions come to you that were worked out by your brain while your thoughts seemed to be far from the program code.
3. Write in concise languages. Powerful programming languages make your programs shorter. Programmers think about programs, at least in part, in the language in which they are written. The laconic language, the shorter the program, and the easier it is to restore its image in its memory.
You can achieve even greater effect by using an ascending programming style when you write programs consisting of abstract layers, the lower of which create a base and a program shell for the upper ones. If you do it right, you only need to keep in your memory only the topmost layer.
4. Constantly rewrite programs. By rewriting the code, you often improve the architecture of the application. Even if not, there is an advantage: to rewrite the program again, you must fully understand its essence. So you can recreate a more accurate picture of the program in your head.
5. Write code that is convenient for you to read. All programmers know how to write good code that is easy to read. But you yourself are the most important reader of your code. Especially at the beginning of the project; Creating a prototype of the future application is your dialogue with yourself. When you write for yourself, you have completely different priorities. When you write for others, your code can be spread across multiple lines for better readability. When you write code so that it can be easily restored to memory, you would rather prefer brevity.
6. Work in small groups. When you imagine a program in your imagination, you focus on handwritten code, parts written by other people, you don’t understand so well, and you cannot imagine them so vividly. Thus, the fewer programmers working on a project, the more complete you are able to present its image. If you work on it alone, you are capable of anything.
7. Do not allow the same code to be edited by several people. As I said, you can never understand someone else’s code as well as your own. It doesn't matter how carefully you read it, you just read it — you didn't write it. Thus, if a section of code is written by several people, none of them has a complete and complete presentation of it.
And of course, you can not drastically change something in it. Not because you need permission for this, but because you just can not imagine it. Reorganizing code written by several people is like reorganizing the laws of the universe. Reorganizing your own code is just another interpretation of the ambiguous image of the program in your head.
If you need several people to develop one project, divide it into parts and select one for each programmer.
8. Start small. The more thoroughly you study the program, the easier it is for you to create its mental image. You can present the individual parts of the finished program as black boxes performing their functions without going into implementation details until you are ready for this. When you start a new project, you just need to keep it in your head completely. If you start with an overly complex and voluminous task, you will probably never be able to cover it entirely. If you are faced with a similar task, start not with its formal description, but with writing a prototype that solves one of its subtasks. Whatever the benefits of planning, they are often not as significant as the benefits you get from being able to keep the whole project in your head.
It's amazing how often programmers stick to all eight points without even knowing about their existence. When someone has an idea, he has to deal with it outside working hours, as it does not have official support from the management. This leads to more productive work due to the absence of distracting factors. Driven forward with pure enthusiasm, the programmer works all night long. Because his project is purely experimental, he writes code not in languages that are a corporate standard, but in laconic scripting languages. He completely rewrites the program again, which would not have been approved by higher-level people, if it were an official development. But in this case, this is a personal project, and he wants to make it perfect. Given that no one but him will see the code, he writes it as concisely and briefly as possible so that it is easier to take on it after the break. The project employs only a small number of people, even if he writes it and not one, because code changes occur so quickly that there is no possibility to connect someone else to the project.
Finally, he starts small, because his idea was originally really small and modest.
Even more surprising is the number of official projects that somehow manage to break all eight “rules”. Indeed, if you look at software development methods in most organizations, you will see that they are deliberately doing everything wrong on purpose. In a way it is. One of the distinguishing features of organizations is the perception of people as interchangeable parts of a common mechanism. This works well for tasks that allow paralleling of tasks between participants, such as, for example, war. Throughout history, there is not a single mention of a case in which a well-organized army of trained mercenaries would be inferior to an army consisting of independent warriors, no matter how valiant they might be. But the thinking process is not very can be distributed among people. And what is programming, if not the thinking process.
The statement that organizations deny the possibility of being dependent on one brilliant employee is not quite true. Just in our current understanding, organizations by definition should not allow this to happen.
Perhaps we should define a new type of organization that would use the joint activities of individual employees without the need for them to be interchangeable. To some extent, the market can be called an organization of this kind, although a better description would be the description of the market as a degenerate case, of what comes of itself when the organization is inappropriate.
Maybe we should choose a workaround and make programmers work differently from other employees. Probably for large companies the best solution would be not to produce ideas on their own, but to buy them from others. In spite of which solution is appropriate in each particular case, you must first understand the existence of the problem. The very phrase "software development company" is a contradiction. Words seem to repel each other in opposite directions. Any good programmer will feel in someone else's dish, being in a large organization, because organizations are designed to prevent what the programmer is most eager for.
A good programmer somehow does a lot of tasks. However, in many cases for this he has to almost organize an uprising against his own company. This behavior is due to the requirements of his work. Programmers head off into programming, forgetting about their other duties, rush to write code without describing its specifications, rewriting the already working code not because they are irresponsible. They prefer to work alone and are angry at the cheering heads of their colleagues, who occasionally appear from the doorway, not because they are not friendly or closed. This seemingly completely random set of habits in their behavior has a single reason: the need to keep in your head the whole project.
Whether or not understanding this will help big companies, it can certainly help their competitors. The weakest point of such companies is that they do not allow programmers to do meaningful work. If you are a small start-up company, using this you can make them a significant competition. Just take into account the peculiarities of the task that the brain of the programmer must undertake entirely.
Source: https://habr.com/ru/post/31235/
All Articles