How to exercise the coding routines of top programmers

I drive to work every day, but I'm nowhere near as good as a professional driver; similarly, programming every day may not be enough to make you a professional programmer. So, what does it take to turn an ordinary person into a professional driver or professional programmer? What do you need to exercise?

The answer lies in a Scientific American article called "The Expert Mind" Li:

Ericsson proposed that the important thing is not the experience itself, but "hard work", that is, to constantly challenge things beyond one's own ability. Some avid enthusiasts spend a lot of time playing chess, golf or instruments, but they may stay at the amateur level all the time, while a well-trained student can surpass them in a relatively short time, The reason is here. It's worth noting that a lot of time spent playing chess (even in various competitions) seems to be more effective than dedicated training in improving the level. The main value of training is to identify weaknesses and improve them in a targeted manner.

"Study hard" means constantly dealing with problems that are just at the limit of your ability , that is, things that have a high probability of failure for you. You probably won't grow without experiencing some failures. You have to constantly challenge yourself and push your limits.

Challenges like that are sometimes encountered at work, but not necessarily. Separating exercise from professional work is often referred to in the programming world as "Code Kata."

The concept of Code Kata was proposed by David Thomas, one of the authors of "The Coder's Practice: From Little Worker to Expert". This concept mainly refers to the repetitive practice of a particular technique or skill to master it. --Translator's Note The

so-called routine is a series of moves. The concept is borrowed from martial arts.

If you want to see some examples of coding routines (that is, ways to work hard to learn and hone your programming skills), Steve Yegge's article has some good advice. He calls them "hands-on drills":

1. Write your own resume. Make a list of all your relevant skills, and then mark the ones you will still use in 100 years. Score each skill out of 10.

2. List the programmers you admire. Try to include those who work with you as you will gain some skills from them on the job. Record 1 or 2 bright spots in them that you wish you could improve upon.

3. Look up the "Computer Science" section on Wikipedia, find the category "Pioneers in Computing", pick a person from this list, read his story, and open any links that interest you while reading.

4. Spend 20 minutes reading through someone else's code. Reading good code and reading bad code are both beneficial, read both, and switch between them. If you can't feel the difference, ask a programmer you respect to show you what makes good code and what makes bad code. Show others the code you've read and ask them what they think.

5. Make a list of your 10 favorite programming tools—the ones that you feel you use the most and must have. Pick one of these tools at random and spend an hour reading its documentation. During the hour, try to learn a new feature of the tool that you didn't realize, or discover a new way to use it.

6. Think about it, what are you best at other than programming? Think about it again, how did you become so proficient and professional? How does this inspire your programming work? (How Apply these lessons to programming?)

7. Take out a stack of resumes and spend an hour in the same room with a group of interviewers. Make sure each resume has been seen by at least 3 interviewers and given a 1-3 rating. Discuss resumes that are judged very differently by different interviewers.

8. Participate in a phone interview. Write down your feedback after the fact, throw out your point, and then chat with the person hosting the phone interview to see if you've come to an agreed conclusion.

9. Have a technical interview with someone who is an expert in a field you don't know well. Let him assume the audience knows nothing in the field, so ask him to start with the basics. Try to understand what he is saying and ask questions if necessary.

10. Have the opportunity to participate in technical interviews with others. During this period, you just listen carefully and study hard. While the candidate is grappling with technical problems, try to solve them in your own mind.

11. Find someone with whom you can exchange practical problems, and exchange programming problems with each other every other week. Spend 10-15 minutes trying to solve these problems, and another 10-15 minutes discussing (whether it can be solved or not).

12. When you hear any interview question that you can't solve for a while, get back to your seat and email the question to yourself as a reminder for later. Find some time during that week to tackle it in your favorite programming language.

What I like about Steve's list is that it seems comprehensive. When some programmers think of "exercise", they always think that it is some coding problem. But in my opinion, programming is more about people than code. So, by solving all the obscure coding interview questions in the world, there are limits to this approach in terms of improving your personal abilities.

Regarding "learning hard", I also like many of the suggestions in Peter Norvig's "Teach Yourself Programming in TenYears" article:

1. Talk to other programmers. Read other people's code. This is more important than any book or training course.

2. Write programs by hand! The best way to learn is to learn by doing.

3. Take a programming course in an undergraduate or graduate program.

4. Find some projects to do, and need to form a team with other programmers to cooperate. As the project progresses, learn to distinguish the best programmers from the worst.

5. Work with other programmers on the project, learn how to maintain code that you didn't write, and learn how to write code that can be maintained by others.

6. Learn multiple different programming languages, especially those with different worldviews and programming models than the languages ​​you are now familiar with.

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 cache), how long it takes to transfer data over Ethernet (or the Internet), read from disk How long does it take to fetch contiguous data or jump to another location on disk, etc.

You can also get inspiration from Dave Thomas's 21 Practical Coding Routines (CodeKata.com), or you may prefer to join a local "Coding Dojo" in your home (CodingDojo.org).

For "study hard" I can't offer a long list of suggestions like Steve, Peter, or Dave. I'm nowhere near as patient as they are. In fact, in my opinion, "programming routine" only requires two moves:

1. Write a blog. I started the CodingHorror.com blog in early 2004 as a form of my own hard work. It started out humble, and it became one of the most important things I've ever done in my career. So, you should blog too. In the end, the people who "know the world" are often those who can write and communicate effectively. Their loudest voice is that they are setting the rules of the game and leading the trend of the world.

2. Actively participate in well-known open source projects . All the rhetoric sounds great, but are you a big talker or a doer? It's very important to not just talk, because people will measure you by your actions, not your words. Try to put something really useful in the public eye, and then you can say, "I worked on that project."

When you can write great code and explain it to the world with great words Those code, by then, I'll think you've mastered the best coding routine!

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=326352139&siteId=291194637