December 23, 2013 at 22:09Passion for programming. Chapter 15. Practice, practice, practice
About Translation
This is a translation of the 15th chapter of The Passionate Programmer: Creating a Remarkable Career in Software Development . Its author - Chad Fowler - is a talented Ruby developer, a well-known speaker at conferences on Ruby and IT in general. Former saxophonist, now CTO 6Wunderkinder.
Crowdsourcing translation of the book is carried out on github , join.
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 imaginable. Not that college musicians were so bad. On the contrary. But they practiced.
When you practice should not sound good. If you succeed during practical exercises, this means you are not mobilizing all your forces. For this, practice is needed. The same is true in sports. Athletes exhaust themselves in training to surpass themselves in competitions. They make mistakes, but behind closed doors, not at work.
In IT, they are often looking for developers who make the most of their capabilities. Unfortunately, usually this developer is not qualified enough to carry out the work 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 practice. What a fighter, what a boxer, if they tumble down from fatigue during a fight, they will not be able to develop this way in sports.
As an industry, we need time to practice. In our West, local programmers often produce more high-quality code than foreign companies. If we try to compete in quality, we must stop using working time for practice. We must invest time in our project.
A few years ago, I started experimenting with programming tasks after my music classes. The first rule was that the software I was developing was not what I myself would like to use. I didn’t 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 graceful moments. But I strained gyrus and created my own sections of code. Just like when playing the saxophone, if in practice there was nothing but a good sound, I knew that I was not trying hard enough. Also, when writing code, if this only turned out to be beautiful code, I might have been somewhere in the center of my thinking abilities instead of the edge, where is the place for good practice.
So how do you know where to practice? Where are your limits? As for the practice of software development, this is a topic for a separate book. For starters, I would again borrow my experience as a jazz musician. I would divide 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 a 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 fingers move easily for example), speed and accuracy - all this is important in practice. What is the equivalent of software developers comparing these key points for music? What is there in the dusty corners of your programming language that you rarely pay attention to? For example, does your programming language support regular expressions? Regular expressions are a very powerful and sadly underused tool in many development environments. Very often, developers do not use them, when there is such an opportunity, due to an insufficient level of knowledge for the effective use of regular expressions. As a result,
The same applies to your programming language API or function libraries. If under your fingers (as the musicians say) there are not many tools of the development environment, it is unlikely that you will begin to use them when they are really needed. Try real drilling, for example, how multi-threaded programming works in your development environment. Or what about streaming libraries, network software 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 study a small part with which they can write less efficiently the same code that they could write, owning the full range of tools available to them.
Reading from a sheet:
As for musicians, the ability to read and play music almost perfectly distinguishes a professional from the first try. I once played the saxophone for Blockbuster (a video rental company). I played both the lead and the second game 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 this is studio time.
As for software developers, what does reading from a worksheet regarding code mean for them? Or specification or design requirements? A great place to find new code to practice with is the open source community. Do you have any favorite open source software examples? How about trying to add something? Go see the to-do list for your open source software and give yourself a limited amount of time to add new properties (or at least determine what needs to be added).
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 much of the code? Where is your starting point?
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 are working with various software. Try using different types of software in different styles and with different programming languages. Observe for yourself what you do easier and what causes difficulties. What patterns help you work with code? What trace of breadcrumbs, figuratively speaking, helps you move up and down the call stack of a complex section or functionality?
Improvisation:
Improvisation means taking some kind of structure or obstacle and creating something new, on the fly, on top of that 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 some of the most creative improvisations in programming happen. When you do crazy things like recovering lost data, manually replacing wireless packets from a binary file. Nobody prepared you for this, especially at such a moment. This skill of sharp and fast programming is like magic power if applied on time.
A great way to improve your improvisation skills when writing code is to cope with your own set limits. Choose a simple program and try to write it with these limitations. My favorite exercise is to write a program that displays the text of the old song “99 bottles of beer on the wall” // Note. perev .: links to youtube - there is no beer , but there is ;) . How would you be able to 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 timer tasks?
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 need to set aside time to practice. This is your responsibility.
Act!
1. Top coder - topcoder.com is a site for programming competitions. 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. He created a series of what is called Code Kata, small provocative exercises that programmers solve in their chosen programming language. Each kata is a special technique or thought process that makes you move your brain. At the time of writing the book, Dave created 21 such katas and posted them freely available on the website ( http://codecata.pragprog.com/ // Note translation link for some reason leads to 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 cat experience. When you're done, write your own kata and share it with the rest.
This is a translation of the 15th chapter of The Passionate Programmer: Creating a Remarkable Career in Software Development . Its author - Chad Fowler - is a talented Ruby developer, a well-known speaker at conferences on Ruby and IT in general. Former saxophonist, now CTO 6Wunderkinder.
Content
Contents:
Opening Remarks
Acknowledgments
Introduction
Chapter 1. Lead or Die
Chapter 2. Supply and Demand
Chapter 3. Coding is not all
Chapter 4. Be the worst
Chapter 5. Invest in your intellect
Chapter 6. Do not listen to your parents
How I refused $ 300,000 - the story at the end of the 6th chapter.
Chapter 7. Be a generalist. (Drafts).
Chapter 8. Be a specialist.
Chapter 9. Don't put all your eggs in someone else's basket.
Chapter 10. Love it or drop it.
Chapter 11. Learn to fish.
Chapter 12. Learn how the business actually works
Chapter 13. Find a mentor
Chapter 15. Practice, practice, practice
Chapter 31. Do not panic
Opening Remarks
Acknowledgments
Introduction
Chapter 1. Lead or Die
Chapter 2. Supply and Demand
Chapter 3. Coding is not all
Chapter 4. Be the worst
Chapter 5. Invest in your intellect
Chapter 6. Do not listen to your parents
How I refused $ 300,000 - the story at the end of the 6th chapter.
Chapter 7. Be a generalist. (Drafts).
Chapter 8. Be a specialist.
Chapter 9. Don't put all your eggs in someone else's basket.
Chapter 10. Love it or drop it.
Chapter 11. Learn to fish.
Chapter 12. Learn how the business actually works
Chapter 13. Find a mentor
Chapter 15. Practice, practice, practice
Chapter 31. Do not panic
Crowdsourcing translation of the book is carried out 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 imaginable. Not that college musicians were so bad. On the contrary. But they practiced.
When you practice should not sound good. If you succeed during practical exercises, this means you are not mobilizing all your forces. For this, practice is needed. The same is true in sports. Athletes exhaust themselves in training to surpass themselves in competitions. They make mistakes, but behind closed doors, not at work.
In IT, they are often looking for developers who make the most of their capabilities. Unfortunately, usually this developer is not qualified enough to carry out the work 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 practice. What a fighter, what a boxer, if they tumble down from fatigue during a fight, they will not be able to develop this way in sports.
As an industry, we need time to practice. In our West, local programmers often produce more high-quality code than foreign companies. If we try to compete in quality, we must stop using working time for practice. We must invest time in our project.
A few years ago, I started experimenting with programming tasks after my music classes. The first rule was that the software I was developing was not what I myself would like to use. I didn’t 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 graceful moments. But I strained gyrus and created my own sections of code. Just like when playing the saxophone, if in practice there was nothing but a good sound, I knew that I was not trying hard enough. Also, when writing code, if this only turned out to be beautiful code, I might have been somewhere in the center of my thinking abilities instead of the edge, where is the place for good practice.
So how do you know where to practice? Where are your limits? As for the practice of software development, this is a topic for a separate book. For starters, I would again borrow my experience as a jazz musician. I would divide 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 a 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 fingers move easily for example), speed and accuracy - all this is important in practice. What is the equivalent of software developers comparing these key points for music? What is there in the dusty corners of your programming language that you rarely pay attention to? For example, does your programming language support regular expressions? Regular expressions are a very powerful and sadly underused tool in many development environments. Very often, developers do not use them, when there is such an opportunity, due to an insufficient level of knowledge for the effective use of regular expressions. As a result,
The same applies to your programming language API or function libraries. If under your fingers (as the musicians say) there are not many tools of the development environment, it is unlikely that you will begin to use them when they are really needed. Try real drilling, for example, how multi-threaded programming works in your development environment. Or what about streaming libraries, network software 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 study a small part with which they can write less efficiently the same code that they could write, owning the full range of tools available to them.
Reading from a sheet:
As for musicians, the ability to read and play music almost perfectly distinguishes a professional from the first try. I once played the saxophone for Blockbuster (a video rental company). I played both the lead and the second game 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 this is studio time.
As for software developers, what does reading from a worksheet regarding code mean for them? Or specification or design requirements? A great place to find new code to practice with is the open source community. Do you have any favorite open source software examples? How about trying to add something? Go see the to-do list for your open source software and give yourself a limited amount of time to add new properties (or at least determine what needs to be added).
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 much of the code? Where is your starting point?
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 are working with various software. Try using different types of software in different styles and with different programming languages. Observe for yourself what you do easier and what causes difficulties. What patterns help you work with code? What trace of breadcrumbs, figuratively speaking, helps you move up and down the call stack of a complex section or functionality?
Improvisation:
Improvisation means taking some kind of structure or obstacle and creating something new, on the fly, on top of that 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 some of the most creative improvisations in programming happen. When you do crazy things like recovering lost data, manually replacing wireless packets from a binary file. Nobody prepared you for this, especially at such a moment. This skill of sharp and fast programming is like magic power if applied on time.
A great way to improve your improvisation skills when writing code is to cope with your own set limits. Choose a simple program and try to write it with these limitations. My favorite exercise is to write a program that displays the text of the old song “99 bottles of beer on the wall” // Note. perev .: links to youtube - there is no beer , but there is ;) . How would you be able to 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 timer tasks?
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 need to set aside time to practice. This is your responsibility.
Act!
1. Top coder - topcoder.com is a site for programming competitions. 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. He created a series of what is called Code Kata, small provocative exercises that programmers solve in their chosen programming language. Each kata is a special technique or thought process that makes you move your brain. At the time of writing the book, Dave created 21 such katas and posted them freely available on the website ( http://codecata.pragprog.com/ // Note translation link for some reason leads to 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 cat experience. When you're done, write your own kata and share it with the rest.