Recently, I read a lot of Steve Yegge's articles. One of them, called "Practicing Programming" (practice programming), was written in 2005, and after reading it, I was astonished:
Contrary to what you believe, simply burying yourself in work every day is not real practice—attending meetings doesn't exercise your interpersonal skills; replying to emails doesn't improve your typing skills. You must regularly set aside time for focused practice in order to do things better.This is an important distinction—I drive to work every day, but my driving level is far below that of a professional driver; similarly, programming every day may not be enough to make you a professional programmer. So what can turn an ordinary person into a professional driver or a professional programmer? What do you need to practice?
I know many outstanding programmers—this is one of the best extra "benefits" of working at Amazon. If you observe them carefully, you will find that they are always practicing. They are already excellent, but they still practice. Their ways of practicing are varied, and I will only introduce a few of them in this article.
From what I understand, the reason these outstanding programmers are so successful is that they have been practicing all along. A perfect body can only be obtained through regular exercise, and you must keep exercising to maintain it, or else it will get out of shape. The same is true for programming and software engineering.
The answer is in an article in Scientific American called "The Expert Mind" (expert thinking):
Ericsson proposed that what matters is not experience itself, but "deliberate practice," that is, constantly challenging things beyond your current abilities. Some enthusiastic amateurs spend a lot of time playing chess, golf, or musical instruments, but they may stay at an amateur level, and that is why a well-trained student can surpass them in a relatively short period of time. Notably, in terms of improving your level, a large amount of time spent playing chess (even in various competitions) still seems less effective than dedicated training. The main value of training is to discover weaknesses and improve them in a targeted way."Deliberate practice" means often dealing with problems that are just at the limit of your abilities, that is, things where you have a high probability of failure. If you don't experience some failure, you may not grow. You must constantly challenge yourself and go beyond your limits.
Such challenges sometimes occur at work, but not necessarily. Separating practice from professional work is often called "Code Kata" in the programming field.
The concept of Code Kata was proposed by David Thomas, one of the authors of The Pragmatic Programmer: From Journeyman to Master. This concept mainly refers to repeated practice on a specific technique or skill in order to master it. — Translator's note.
A so-called kata is a series of movements. This concept is borrowed from martial arts.
If you want to see some examples of code katas (that is, ways to study hard and hone programming skills), Steve Yegge's article does offer some good suggestions. He calls them "practice drills":
1. Write your own resume. List all your relevant skills, then mark the ones that will still be useful 100 years later. Give each skill a score out of 10.
2. List the programmers you admire. Try to include the ones you work with, because you will gain some skills from them at work. Write down 1–2 shining points of each of them, that is, the aspects you want to improve in yourself.
3. Look at the "Computer Science" section on Wikipedia, find the category "Computer Science Pioneers," pick a person from the list, read their story, and open any links that interest you while reading.
4. Spend 20 minutes reading through someone else's code. Reading excellent code and reading bad code are both beneficial; read both, alternating. If you can't tell the difference between them, ask a programmer you respect to show you what excellent code and bad code look like. Show others the code you have read and ask for their opinions.
5. List your 10 favorite programming tools—the ones you feel you use the most and cannot do without. Pick one at random and spend an hour reading its documentation. During that hour, try to learn a feature of that tool you didn't know existed, or discover a new way to use it.
6. Think about what you are best at besides programming. Then think about what kind of practice made you so skilled and professional. What inspiration does this bring to your programming work? (How can you apply these experiences to programming?)
7. Take a stack of resumes and spend an hour in a room with a group of interviewers. Make sure each resume is read by at least 3 interviewers and given a score from 1 to 3. Discuss the resumes that got very different ratings from different interviewers.
8. Participate in a phone interview. Afterward, write down your feedback, share your opinions, and then talk with the person who conducted the phone interview to see whether you agree on a conclusion.
9. Conduct a technical interview, and the interviewee should be an expert in a field you don't know much about. Ask him to assume the audience knows nothing about this field, so have him start from the basics. Try to understand what he says, and ask questions when necessary.
10. Take the opportunity to sit in on someone else's technical interview. During the process, just listen carefully and learn. While the candidate is working hard to solve technical problems, you should also try to solve those problems in your own mind.
11. Find a person with whom you can exchange practical problems, and share programming problems with each other every other week. Spend 10–15 minutes trying to solve them, then 10–15 minutes discussing them (whether or not they are solved).
12. When you hear any interview question that you can't solve right away, quickly return to your seat and email the question to yourself as a reminder for later. Find some time in that week to solve it with your favorite programming language.
The reason I like Steve's list is that it looks comprehensive. Some programmers think of "practice" as simply difficult coding puzzles. But in my opinion,programming is more about people than code.Therefore, by solving all the world's obscure programming interview questions, this approach is limited in improving your personal abilities.
Regarding "deliberate practice," I also like Peter Norvig's"Teach Yourself Programming in Ten Years" (spend ten years learning programming on your own)many suggestions put forward in the article:
1. Communicate with other programmers. Read other people's code. This is more important than any book or training course.
2. Write programs yourself! The best way to learn is to learn by doing.
3. Take programming courses in undergraduate or graduate programs.
4. Find some projects to do, and form a team with other programmers. During the project, learn to tell who the best programmers and the worst programmers are.
5. Work with other programmers on projects, learn how to maintain code you didn't write, and learn how to write code that is easy for others to maintain.
6. Learn many different programming languages, especially those that have a different worldview and programming model from the languages you are familiar with now.
7. Understand the impact of hardware on software. Know how long it takes your computer to execute an instruction, how long it takes to fetch a word from memory (with or without a cache), how long it takes to transfer data on Ethernet (or the Internet), how long it takes to read sequential data from a disk or jump to another location on a disk, and so on.
You can also get inspiration from Dave Thomas's 21 practical code katas (CodeKata.com), or you might prefer to join a local "programming dojo" (CodingDojo.org).
For "deliberate practice," I can't provide a long list of suggestions like Steve, Peter, or Dave. I am far less patient than they are. In fact, in my opinion, "coding kata" needs only two moves:
1. Write a blog. I founded the CodingHorror.com blog in early 2004 as a form of my own deliberate practice. It was very obscure at first, but later became the most important thing I've done in my career. So, you should write a blog too. Those who finally "become known to the world" are often those who can write and communicate effectively. Their voices are the loudest; they are the ones who make the rules and lead the world's trends.
2. Actively participate in famous open source projects. All the high-sounding talk sounds good, but are you a big talker or a doer? Don't just talk without doing. This is very important, because people will measure you by your actions, not your words. Work hard to leave something real and useful in public, and then you can say, "I contributed to that project."
When you can write brilliant code and explain that code to the world with brilliant words, then I will think you have mastered the baddest coding kata!
Source: http://www.topthink.com/topic/11711.html