Programming skill

Kent Beck - software developer, creator of such software development methodologies as extreme programming (XP) and development through testing (TDD); currently works on Facebook. Your attention is invited to translate outline ideas on how to make your work more efficient. The division of programmers into masters and apprentices, used throughout the article, was taken by Kent Beck from the book "Pragmatic Programmer" by Andrew Hunt and David Thomas.

Over the years, watching the best of the master programmers, I noted some common patterns in their work processes. At the same time, for years training trained apprentice programmers, I noticed that they have no such habits. I saw with my own eyes how much a difference can make others familiar with the patterns used by masters in their work.

Below are the ways in which effective programmers every day squeeze the most out of their precious 3e9 seconds on our planet.

The main motive for the outline is unleashing the potential of your brain. An apprentice learns to solve large problems by solving several small problems at once. The master, however, learns to solve even bigger problems than the apprentice, by solving fewer tasks at once. An important part of the wisdom here is that the breakdown of tasks should be done in such a way that integrating independent solutions would be less of a problem than simply solving all the problems together.

Time

• Breakdown of tasks ( slicing ). Take a large project, cut it into “thin” pieces and rearrange them so that they suit you according to your circumstances. I am always able to divide the project into even smaller tasks, and I can always find a new permutation of these tasks that will meet other needs.
• One thing at a time. We are so focused on efficiency that we try to reduce the number of feedback cycles in an attempt to reduce overhead (overhead). This leads later to the appearance of difficult debugging cases, the estimated cost of which will be greater than the overhead from the cycle, which we avoided earlier.
• Make it work; make it spell correctly; make it work fast ( make it run, make it right, make it fast ) (Here you should give examples of “One thing at a time”, “Breakdown of a task” and “Ease of change”)
• Ease of change. When you encounter a complex change, first make it simple (caution: it can be difficult - refactoring and paying off technical debt is not ruled out), then make a simple change (use task breakdown, change one case at a time, concentration and isolation). Most often, this implies a breakdown of the task into simpler ones.
• Concentration. If you need to change several elements, first remake your code so that you need to make a change in only one element.
• Insulation. If you need to change only a part of an element, then extract this part so that the entire sub-element is changed.
• Measurement of the basic level ( baseline measurement - an accurate measurement of the functioning of the process before any change is made). Start projects by measuring the current state of the world. This goes against our engineer instincts, which immediately determine something to “fix” - but only after you conduct a basic study of the project, you will understand whether you are really correcting something.

Training

• Know what you want to do. Before running the code, formulate an explicit prediction of what will happen.
• Specific hypotheses. If a program behaves badly, express the idea precisely and clearly about what you think is wrong with it, before making a change. If you have one or more hypotheses, differential diagnosis will help you .
• Remove foreign parts. When reporting a bug, find the shortest path from the necessary steps to reproduce it. When isolating a bug, find the minimum test case. When using the new API, start with the simplest example. “All this bullshit doesn't matter” is an expensive assumption that can turn against you when in the end something goes wrong. Example: if you see a bug in a mobile application, try playing it with curl.
• Try a different scale. Move freely between the levels of "scaling" of the project. Perhaps you are dealing with a design problem, not a test. Perhaps the problem is with people, not technology [ cheating, because this statement is always true ].

Beyond Logic

• Symmetry . Things that are almost identical in appearance can be divided into parts that are identical and parts that are precisely (and clearly) different.
• Aesthetics. Beauty is a magnificent slope that can be so difficult to climb. It is not surprising that neglecting it is no less relief (for example, embedding a bunch of functions in one gigantic piece of code, which is no longer possible to understand).
• Rhythm. Waiting for the right moment helps conserve energy and avoid clutter. When the time comes to act, action should be intensive.
• Compromises. All decisions are subject to compromise. It is more important to know what the decision is justified than to make a choice simply because it is required right now (in the latter case, instead of understanding the big picture, you will have to constantly remember what specific choices you made in the past in order to build on them in the present).

Risk

• List of entertainment. When “left” ideas come to you “tangentially”, just write them down and quickly get back to work. Review this list of ideas a little later - after the current case, you reach a place where you can stay.
• Feed ideas. Ideas are like small birds - they are also easy to scare away; and if you scare them regularly, then they will stop flying to you. When you have an idea, feed it a little. Make sure that the idea is untenable (that is, disable it) as quickly as you can - but justify your refusal to tackle it with the help of data, and not because of a lack of self-esteem.
• 80/15/5. Spend 80% of your time working with low risk / sufficient return. Spend 15% of your time working with high risk / high return. Spend 5% of your time on things that haunt you, despite potential returns. Train the next generation to do 80% of your work. By the time someone is ready to take this burden on themselves, one of your 15% experiments (or, less often, one of 5% experiments) will repay the result and become your new 80%. Then repeat all over again.

Conclusion

The drafts were arranged by the author in the order that goes from reducing risks with time management and training to taking on conscious risks by using the potential of your entire brain and the ability to quickly sort out the sequence of ideas.