Programming skills

Kent Beck is a software developer, creator of software development methodologies such as Extreme Programming (XP) and Test Development (TDD); currently working on Facebook. We offer you a translation of the outline of ideas on how to make your work more efficient. The division of programmers into masters and apprentices, used throughout the article, is taken by Kent Beck from the book The Programmer-Pragmatist Andrew Hunt and David Thomas.

For years, watching the best of the master programmers, I noted some general patterns in their work processes. At the same time, having trained trained apprentices programmers for years, I noticed that they didn’t have these habits. I saw with my own eyes how much of a difference the others can get acquainted with the patterns used by the masters in their work.
')
Below are the ways in which effective programmers squeeze the most out of their precious 3e9 seconds every day on our planet.

The main motive of the outline is to unleash the potential of your brain. An apprentice learns to solve large problems by solving several small problems at once. The master learns to solve even bigger tasks than an apprentice, by solving fewer tasks at once. An important part of the wisdom here is that the breakdown of tasks must be carried out in such a way that the integration of independent solutions would be less of a problem than the simple solution of all problems together.

Time

• Slicing tasks. Take a big project, cut it into "thin" pieces and rearrange them among themselves 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 the “overhead” (overhead). This leads later to the emergence of difficult debugging cases, the estimated cost of which will be more than the overhead of the cycle, which we avoided earlier.
• Have it work; have it written correctly; make it work fast ( make it run, make it right, make it fast ) (Here you should give examples of “One case at a time”, “Task breakdown” and “Simplicity of changes”)
• The ease of change. When you encounter a complex change, first make it simple (caution: it can be difficult - refactoring and paying technical debt are possible), 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 more simple ones.
• Concentration. If you need to change several elements, first redo your code so that you only need to make the change in one element.
• Insulation. If you need to change only a part of an element, then remove this part to change the entire sub-element.
• Baseline measurement ( baseline measurement - an accurate measurement of the functioning of the process before any change is made). Start your projects by measuring the current state of the world. This goes against our engineer instincts, which predetermine something to “fix” right away - but only after you do a basic research of the project, you will understand if you are really correcting something.

Training

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

Beyond Logic

• Symmetry Things that look almost the same can be divided into parts that are identical, and parts that are precisely (and clearly) distinct.
• Aesthetics. Beauty is a majestic slope on which it is so hard to climb. Not surprisingly, neglecting it gives no less relief (for example, embedding a heap of functions into one giant piece of code, which is no longer possible to figure out).
• Rhythm. Waiting for the right moment helps save energy and avoid clutter at work. When the time comes to act - you should act intensively.
• Compromises. All solutions are subject to compromise. It is more important to know what decision making is based on, than to make a choice simply because it is required right now (in the latter case, instead of understanding the overall picture, you will have to remember all the time what particular choices you made in the past to build on them in the present).

Risk

• List of entertainment. When “left” ideas come to you “on a tangent”, just write them down and quickly get back to work. Review this list of ideas a little later - after you have reached a place to stay in the current case.
• Lure ideas. Ideas are like small birds - they are also easy to scare away; and if you scare them regularly, they will stop coming to you. When you have an idea, feed it a little. Make sure that the idea is untenable (that is, invalidate it) as quickly as you can - but justify your refusal to take it up with the help of data, and not because of a lack of self-assessment.
• 80/15/5. Spend 80% of your time on low-risk / sufficient returns. Spend 15% of your time on high-risk / high-return jobs. Spend 5% of your time on things that bother you, regardless of the potential returns. Teach the next generation to do 80% of your work. By the time someone is ready to take on this burden, one of your 15% of experiments (or, more rarely, one of 5% of experiments) will pay back the result and become your new 80%. Then repeat all over again.

Conclusion

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