A passion for programming. Chapter 15. Practice, practice, practice

About transfer

This is the translation of Chapter 15 of The Passionate Programmer: Creating a Remarkable Career in Software Development . Its author, Chad Fowler, is a talented Ruby developer, a renowned speaker at conferences dedicated to Ruby and IT in general. Former saxophonist, and now - CTO 6Wunderkinder.


Crowdsourcing translation of the book is conducted on github , join.

Chapter 15. Practice, practice, practice

When I was a student at a music college, I spent long nights in its walls. Through the thin walls of the rooms, I was immersed in the most terrible musical sounds that can be imagined. Not that college musicians were so bad. On the contrary. But they practiced.
')
When you practice should not sound good. If you do everything during practical classes, it means you do not mobilize all your strength. For this and practice is needed. The same thing in sports. Athletes exhaust themselves in training to surpass themselves in competition. They make mistakes, but behind closed doors, not at work.

IT is often sought by developers who make the most of their capabilities. Unfortunately, usually this developer is not qualified enough to do the job for which he is hired. Our industry has a tendency to practice while working. Can you imagine a professional musician who would go on stage and repeat what I heard in the classes of my musical college? He would not be understood. Musicians are paid for concerts , not for practice. What a fighter, what a boxer, if they fall down from exhaustion during a duel - they will not be able to develop in sports.

As an industry, we need time to practice. In the West, local programmers often produce higher-quality code than foreign companies. If we are trying to compete in quality, we must stop using work time for practice. We have to invest time in our project.

A few years ago, I started experimenting with programming tasks after my music lessons. Rule one was that the software that I developed was not what I myself would like to use. I did not want to finish the job. So I wrote useless software.

I did not try, but I was disappointed to find that many of my ideas did not work. Although I tried to do the job as well as possible, the design and code were not as beautiful as I thought they should be.

Looking back, I see that the strange feeling experienced then suggests that the experience gained was a good sign. My code was not completely devoid of elegant moments. But I strained the convolutions and created my code sections. Just like when playing the saxophone, if during practice there was nothing but a good sound, I knew that I was not trying hard enough. Also, when writing code, if it only turned out beautiful code, I was probably somewhere in the center of my thinking abilities instead of the edge, where the place for good practice is the most.

So, how do you know where to practice? Where are your limits? As for the practice in software development, this is a topic for a separate book. For a start, I would again borrow my experience as a jazz musician. I would break the practice into the following categories (simplified for non-musicians among us):

- physics / coordination
- reading from a sheet
- improvisation

This can serve as a framework for one-sided thought of practice as software development.

Physics / Coordination:

Musicians should practice the technical aspects of their musical instruments: sound extraction, physical coordination (making your fingers move easily for example), speed and accuracy - all this is important in practice. What is the equivalent of software developers comparing to these basic terms for music? What is there in the dusty corners of your programming language that you rarely pay attention to? For example, does your chosen programming language support regular expressions? Regular expressions are a very powerful and notoriously used tool in many development environments. Very often, developers do not use them, then when there is such an opportunity, due to an insufficient level of knowledge to use regular expressions effectively. As a result, a lot of unnecessary code is created by structural analysis of strings (needless string-parsing code), which must be followed in the future.

The same applies to your programming language API or function libraries. If under your fingers (as musicians say) there are no many tools of the development environment, it is unlikely that you will start using them when they are really needed. Try to make a real bore, for example, while multi-threaded programming works in your chosen development environment. Or how about streaming libraries, network programming APIs, or even a set of utilities available for working with lists or collections? Most modern programming languages ​​offer rich and powerful libraries in all these areas, but software developers prefer to learn a small part, with which they can write less effectively the same code that they could write, owning the full set of tools available to them.

Reading from a sheet:

As for musicians, the ability to read and play music almost perfectly from the first time distinguishes a professional. I once played the saxophone for a Blockbuster (video rental company). I played both the lead and the second game at the same time at a fast pace. I saw the notes for the first time, literally as soon as the tape began to rotate. We played alternately leading and second game. Any mistakes, and the whole group had to start all over again - and the price of it was studio time.

As for software developers, what could read from the sheet relative to the code mean to them? Or specification or design requirements? A great place to look for new code to practice with is the open source community. Do you have any favorite examples of open source software? How about trying to add something? Go see the to-do list for your open source software and set aside a limited amount of time to add new properties (or at least determine what you should add).

After selecting, download the source code of the software and start the study. How to know where to look? What tricks do you use to find your way in a large part of the code? Where is your point of reference?

This is an exercise in which you can practice often and for short periods of time. You do not have to actually develop anything. Just use this as a starting point. The real goal is to understand what you are looking for as quickly as possible. Be sure that you work with different software. Try to use different types of software in different styles and with different programming languages. Note for yourself what you manage easier and what causes difficulties. What patterns help you work with code? Which footprint of breadcrumbs, figuratively speaking, helps you move up and down the complex call or functionality stack?

Improvisation:

Improvisation means to take some kind of structure or obstacle and create something new, on the fly, on top of this structure. As a programmer, I found that I most often improvise during stressful situations. Oh no! The wireless network application server lies and we lose orders! That's when one of the most creative impromptu in programming happens. When you do such crazy things as recovering lost data, manually replacing wireless network packets from a binary file. Nobody prepared you for this, especially at such a moment. This skill is sharp and fast programming as a magic power, if applied on time.

A great way to improve improvisation skills when writing code is to cope with self-imposed restrictions. Choose a simple program and try to write it with these restrictions. My favorite exercise is to write a program that displays the text of the old song “99 bottles of beer on the wall” // Comm. Transl .: Links on youtube - there is no beer , but there is ;) . How could you write this program without assigning variables? Or how small can you write a program that displays the correct text? Add a restriction - how fast can you write such a program? How about solving small, complex tasks with a timer?

This is just one of the limited perspectives on how to practice. You can find examples in any field, from art to monastic religious practices. It is important to find your needs for practice and to be sure that you do not train during work. You must set aside time to practice. It is your responsibility.

Act!

1. Top coder - topcoder.com is a programming competition site. You can create an account and compete for prizes. Even if you are not interested in competing with others, TopCoder offers a practice room with a large collection of problems that you can perfectly use as practical exercises. Go register and try!

2. Code Kata - Dave Thomas, one of the Pragmatic Programmers (our favorite publisher), took the idea of ​​writing code and did something ... well, a pragmatic one of that. He created a series of what is called Code Kata, small provocative exercises that programmers decide in their chosen programming language. Each kata is a special technique or thought process, forcing brains to move. While writing the book, Dave created 21 such katas and laid them out in the public domain on the site ( http://codecata.pragprog.com/ // Note of the transl. Link for some reason leads to a tumbler ). On the site you will find links to the mailing list, as well as solutions of other users during the discussion of how the problem was solved. Your task: to work out all 21 exercises. Keep a diary (or blog?) Of your experience with katami. When you're done, write your own kata and share it with the others.