The perfect programmer. Part 1
Article-abstract on the book of Robert Martin "The Perfect Programmer" . After reading the book, I changed my attitude to programmatic life. The book covers the process of writing code, the code itself, the relation to tasks, TDD, and many other utilities. Read the need to developers and project managers. Partially applicable to designers.
Non-professionals do not take responsibility for their work. They delegate this responsibility higher in the hierarchy: you are the boss, and you answer. If a layman crap one's pants, the employer has to clean up the excrement. A professional cleans up after himself. What else do professionals do and do not make amateurs?
Slaves cannot say no, but wage earners can. If you are a professional, it is your responsibility. When the manager sets an unrealistic term, your duty is to say no. If you are offered a quick, but architecturally weak solution, your duty is to say no. When you are offered to work at night, your duty is to say no.
The worst thing you can say is to say that "you will try." There is nothing worse. Answering this way, you are not doing your job, and your job is to say: “No, this is not possible.” You can try to avoid unpleasant negotiations, but these are just cowardice:
- You need to do a search for tours by Friday.
- This is impossible; it takes two weeks to develop and debug a search.
- We need to show the client on Friday. Let's try.
- OK I will try.
You avoided a conflict situation today, but provoked an explosion on Friday. This can lead to a quarrel with the client and, eventually, to the loss of the customer. Stand on your own: impossible - then impossible.
The phrase “I will try,” “I will try,“ I will try ”should be completely excluded from your vocabulary and you should not accept such answers from anyone else. If you are told such phrases, specify and insist on a direct answer. “I will try” means that you will make extra efforts to complete the task. And what kind of effort? Have you worked before not in full force? Or are you ready to work around the clock now? Or do you put it on the shoulders of the team? If you do not have energy reserves, a new plan and are not going to change your behavior, then you are simply lying. No need to try.
One of my good, but inexperienced friend met with a client on the site and invited me to negotiate. A man came and began to talk about what a good project he had, but he had already been burned several times by non-professionals; so we need to do preliminary layouts. I know about the dangers of preliminary layouts, but my friend did not know, and as soon as I was about to open my mouth, he had already answered that “yes, well, we will do it”. This was the first and only step towards the loss of a client. By the deadline, he did not make a layout, did not receive a new order and the client was disappointed.
The promise can be divided into three parts:
Saying “yes” means that you need to say that you will do something without any modifiers. What are these modifiers? “Need” (I need to lose weight), “should” (we need to find new clients), “try” (I will try to persuade the investor), “it would be nice” (it would be nice to go to the cinema), “I hope” (I hope we will meet next week), "let's" (let's do authentication by Thursday), "if there is time."
Track your speech and the speech of others. Notice how often these words occur around us and how often you try to absolve yourself of responsibility.
A serious promise suggests that you perform a specific action. Even if you can’t do everything you’re asking for, you can do some specific part of the offer.
- Please make a report to Birt. This should be done by Monday.
- By Monday I can not. But by this time I will prepare web services.
In general, a serious promise looks like this: "I will do this by that time." If you did not cope with the promised, as soon as possible inform the one to whom you promised.
Code readiness is its state when several tasks are solved at once:
Programmers are paid a lot, because it is a difficult job. You need to concentrate on work and, if this fails, you will get bad code. If you are tired, do not write the code, but rather sleep a little . If your wife left you, do not write the code. If your cat has just given birth to seven sons, do not write the code.
Night programming is unacceptable . Your nightly code will be like a boomerang coming back to you again and again for corrections and improvements. Why so fond of night programming? First of all, it allows you to look like a hero: “while working all night I wrote a ton of govnokod”. Secondly, no one distracts at night. But after all, during the day you can organize everything so that nothing distracts. A couple of times a week, I transfer the phone and messengers into airplane mode so that you can safely think about the task without distractions.
The flow zone is evil. So programmers call superproductive time, when they manage to write-write-write code and don’t want to be distracted for anything, but continue and continue. In this state, the programmer considers himself a superman, and his code is good.
The problem is that the code quickly written in the Zone more often causes errors. You may lose part of the overall picture and the code will be poorly coordinated with the rest of the parts or the business. If you feel you are entering the Zone, make conscious efforts to get out of it. Helps pomodoro, pair programming and wife.
The sure sign of the Zone is when you are rude to answer phone calls and are not happy even to good people.
The creative crisis can be overcome. It usually comes from fatigue or monotony. Introduce something new into your life and relax more. Read books from different areas: classical literature, science, science fiction, Daria Dontsova. Creativity begets creativity.
Reduce debugging time. This time seems to be an inevitable developer, but the less you sit behind the debugger, the more you do something really useful. It helps TDD / TLD and contract programming.
Stop it. Programming is a marathon, not a sprint. You do not need to stay, just because you could not finish your task yet. The feeling that "this shit is about to work" may not leave you for hours. Allow your head to rest and use the saying “Morning is wiser than evening”. The decision may come to you later on the way home, in the shower or at breakfast. Let it happen.
, , , , , . : , () . : 1 . , 4 - . , , , , , .
. , . : . , . : , . . , .
, . . , . . , .
. , : .
— , .
, — . . , . , . , 14:00 16:00.
— . , . , . , , : « » . . , , , . , - .
. , TDD, , , , , , , .
.
→
1. Professionalism
Non-professionals do not take responsibility for their work. They delegate this responsibility higher in the hierarchy: you are the boss, and you answer. If a layman crap one's pants, the employer has to clean up the excrement. A professional cleans up after himself. What else do professionals do and do not make amateurs?
- Use the "do no harm" rule . Your code should work and you should not break anything. Of course, not everyone can do it, but as you grow, the number of errors in your code will tend to zero.
') - Quality control should not find anything . I repeatedly observed a situation when an incorrectly executed task was sent to testing. Moreover, the fact that it was not implemented was clear to the developer. This attitude is no good. When you give a task to testers, you must be completely confident in your code. A bad code is any code you are not sure about. If the quality control service has found an error in your code, you should be surprised, apologize, understand why this happened and prevent this from happening in the future.
- Use automated testing. It is impossible to be confident in the quality of your code without testing it. Test the code along and across, from right to left and from top to bottom. Each piece of code should be tested for all possible situations. If you do it manually, you will not have time to develop, so you need to automate testing: let the machine sweat. The code should be 100% covered with tests. More on this later in the TDD section.
- Write a flexible code . The code structure should provide flexibility. Changes to the code should not lead to exorbitant costs. Professionals know design patterns and build software architecture on them. Checking is simple: try making changes to your code. If it causes pain just below the belt, it means that everything is bad with flexibility. Revise the code structure to make the next change easier. This is called ruthless refactoring: always leave the module cleaner than before your arrival.
- Learn by yourself . The employer does not have to send you anywhere to study. If you work 40 hours a week, plan to work 60 hours. Of these, 40 hours you spend on the employer, and the remaining 20 - on self-education.
- Know your area . You should know what the Nassi-Schneiderman diagram is, the quick sort algorithm, what the term "orphan data" means and what the Parnas tables are for. To be a professional, you need to know the fundamentals of the profession. Moreover, most of these foundations were formulated several decades ago. Design patterns, SOLID, development methodology, analysis and design, TDD, OOP, structured programming, continuous integration, pair programming, artifacts.
- Do not stop learning . Our industry is constantly developing and updating. If you do not follow what is happening, you can be in the Stone Age in a year. An example for designers: you may not know that there is a plug-in for Photoshop that breaks your layout into assets and fills it into the cloud, but the customer will prefer to work with the designer who, as a result of the work, will give him a link to the collection of assets for the layout designer. I'm talking about sympli .
- Are training . To keep fit, you need to constantly strain your brains. Do exercises in different programming languages. Let it be simple tasks that take no more than 10 minutes. But time for them needs to be allocated every day.
- Work together . A great way to learn something new is to work together. Professional developers try to design, train, work, plan together. They learn a lot from each other and do their work more efficiently. It helps a lot when you just sit next to a friend and watch how he uses the development environment. ABOUT! It turns out that there is a layout of Birman and Ctrl-Alt-Z in Photoshop.
- Teach others . The best way to learn yourself is to teach others. That is why I write articles and sometimes give classes and courses. The main benefit of teaching is the teacher. Professionals take responsibility for training new employees and do not leave them alone with a huge medical information system, the code of which even scary to watch (this is about us).
- Know the subject area . There is a vicious practice of working only on specification. This is the height of unprofessionalism, when we entrust all mental activity to analysts, and use our own brain exclusively to describe algorithms. The professional knows the beneficial effect. He understands why each function is needed, what it will give to users and how it will affect the client’s business. He can correct the specification and send analysts for additional research.
- Understand the interests of the employer and the customer . If your employer has problems, these are your problems. If your employer owes DIT Moscow 30 million and has not paid for a month already, this means that you will be left without a premium by the New Year holidays. Offer solutions to customer problems and know their business. Think up for your customer a new project, idea, improvement, business process, product, advise the employee, supplier, buyer. Do not be greedy.
- Modest . A professional is not the infallible king of the hill. I saw examples when even the most qualified developers were wrong. The professional does not laugh at the mistakes of others, does not scoff at colleagues, accepts well-deserved and undeserved ridicule at himself. He understands that his timing estimates may be incorrect, and the chosen technology will be unsuitable.
2. Say No
Slaves cannot say no, but wage earners can. If you are a professional, it is your responsibility. When the manager sets an unrealistic term, your duty is to say no. If you are offered a quick, but architecturally weak solution, your duty is to say no. When you are offered to work at night, your duty is to say no.
The worst thing you can say is to say that "you will try." There is nothing worse. Answering this way, you are not doing your job, and your job is to say: “No, this is not possible.” You can try to avoid unpleasant negotiations, but these are just cowardice:
- You need to do a search for tours by Friday.
- This is impossible; it takes two weeks to develop and debug a search.
- We need to show the client on Friday. Let's try.
- OK I will try.
You avoided a conflict situation today, but provoked an explosion on Friday. This can lead to a quarrel with the client and, eventually, to the loss of the customer. Stand on your own: impossible - then impossible.
The phrase “I will try,” “I will try,“ I will try ”should be completely excluded from your vocabulary and you should not accept such answers from anyone else. If you are told such phrases, specify and insist on a direct answer. “I will try” means that you will make extra efforts to complete the task. And what kind of effort? Have you worked before not in full force? Or are you ready to work around the clock now? Or do you put it on the shoulders of the team? If you do not have energy reserves, a new plan and are not going to change your behavior, then you are simply lying. No need to try.
3. How to say yes. Promise language
One of my good, but inexperienced friend met with a client on the site and invited me to negotiate. A man came and began to talk about what a good project he had, but he had already been burned several times by non-professionals; so we need to do preliminary layouts. I know about the dangers of preliminary layouts, but my friend did not know, and as soon as I was about to open my mouth, he had already answered that “yes, well, we will do it”. This was the first and only step towards the loss of a client. By the deadline, he did not make a layout, did not receive a new order and the client was disappointed.
The promise can be divided into three parts:
- You say you will do something
- Responsible to your words
- Follow the promise
Saying “yes” means that you need to say that you will do something without any modifiers. What are these modifiers? “Need” (I need to lose weight), “should” (we need to find new clients), “try” (I will try to persuade the investor), “it would be nice” (it would be nice to go to the cinema), “I hope” (I hope we will meet next week), "let's" (let's do authentication by Thursday), "if there is time."
Track your speech and the speech of others. Notice how often these words occur around us and how often you try to absolve yourself of responsibility.
A serious promise suggests that you perform a specific action. Even if you can’t do everything you’re asking for, you can do some specific part of the offer.
- Please make a report to Birt. This should be done by Monday.
- By Monday I can not. But by this time I will prepare web services.
In general, a serious promise looks like this: "I will do this by that time." If you did not cope with the promised, as soon as possible inform the one to whom you promised.
4. Writing code
Code readiness is its state when several tasks are solved at once:
- The code works. It reflects the solution of the task and you were convinced of this. Solved every aspect of the problem.
- Fits into existing architecture. The system should not lose in flexibility, stability, transparency. The code must comply with the design principles.
- Normally read by other developers.
Programmers are paid a lot, because it is a difficult job. You need to concentrate on work and, if this fails, you will get bad code. If you are tired, do not write the code, but rather sleep a little . If your wife left you, do not write the code. If your cat has just given birth to seven sons, do not write the code.
Night programming is unacceptable . Your nightly code will be like a boomerang coming back to you again and again for corrections and improvements. Why so fond of night programming? First of all, it allows you to look like a hero: “while working all night I wrote a ton of govnokod”. Secondly, no one distracts at night. But after all, during the day you can organize everything so that nothing distracts. A couple of times a week, I transfer the phone and messengers into airplane mode so that you can safely think about the task without distractions.
The flow zone is evil. So programmers call superproductive time, when they manage to write-write-write code and don’t want to be distracted for anything, but continue and continue. In this state, the programmer considers himself a superman, and his code is good.
The problem is that the code quickly written in the Zone more often causes errors. You may lose part of the overall picture and the code will be poorly coordinated with the rest of the parts or the business. If you feel you are entering the Zone, make conscious efforts to get out of it. Helps pomodoro, pair programming and wife.
The sure sign of the Zone is when you are rude to answer phone calls and are not happy even to good people.
The creative crisis can be overcome. It usually comes from fatigue or monotony. Introduce something new into your life and relax more. Read books from different areas: classical literature, science, science fiction, Daria Dontsova. Creativity begets creativity.
Reduce debugging time. This time seems to be an inevitable developer, but the less you sit behind the debugger, the more you do something really useful. It helps TDD / TLD and contract programming.
Stop it. Programming is a marathon, not a sprint. You do not need to stay, just because you could not finish your task yet. The feeling that "this shit is about to work" may not leave you for hours. Allow your head to rest and use the saying “Morning is wiser than evening”. The decision may come to you later on the way home, in the shower or at breakfast. Let it happen.
5. Schedule lag
, , , , , . : , () . : 1 . , 4 - . , , , , , .
: , .. , . : . , . : , . . , .
, . . , . . , .
. , : .
— , .
6.
, — . . , . , . , 14:00 16:00.
— . , . , . , , : « » . . , , , . , - .
. , TDD, , , , , , , .
.
→
UPD: .Source: https://habr.com/ru/post/317312/
All Articles