The most bullish B coding routines

Recently, I read a lot about Steve Yegge's article. One of them, called "practicing Programming" (practice programming), was written in 2005, and I was amazed by the reading:

Contrary to what you believe, simply being immersed in a job every day is not a real exercise--attending meetings does not exercise your interpersonal skills; Replying to a message does not improve your typing level. You have to set aside time and exercise regularly to get things done better.

I know a lot of great programmers-it's one of the best extra "perks" to work on Amazon. If you look at them carefully, you will find that they are always exercising. They are very good, but they still do not forget to exercise. There are a variety of ways in which they exercise, and I will only cover several of them in this article.

As far as I know, these outstanding programmers have been so successful because they have been exercising. The perfect figure to rely on regular exercise can be obtained, and must adhere to exercise to maintain, otherwise the body will be shape. For programming and software engineering, the rationale is the same.

It's an important distinction-I drive to work every day, but my driving level is far less than that of a professional driver; In a similar situation, 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 exercise?

The answer is in a "Scientific American" article entitled "The Expert Mind":

Ericsson proposes that the important thing is not the experience itself, but "hard learning", that is, to constantly challenge themselves beyond the ability of things. Some avid enthusiasts spend a lot of time playing chess, golfing or playing musical instruments, but they may stay on the amateur level and a trained student can overtake them in a relatively short period of time, and that's why. It is worth noting that the amount of time spent playing chess (even in various competitions) seems to be more effective at raising levels than specialized training. The main value of training is to identify weaknesses and improve them accordingly.

"Hard learning" means dealing with problems that are just at the limit of your abilities, that is, things that are likely to fail for you. If you don't experience some failure, you may not grow up. You have to constantly challenge yourself to go beyond your limits.

Such challenges can sometimes be met at work, but not necessarily. Separating exercise from professional work is often referred to as "coding routines" (code Kata) in the field of programming.

The concept of Code Kata is presented by David Thomas, who is one of the authors of the "Programmer's Path: from the handyman to the expert". This concept mainly refers to the practice of repetition for a particular technique or skill, thus mastering it. --Translator's note

The so-called routines, is a series of moves. This concept draws on wushu.

If you want to see some examples of coding routines (that is, the way to learn and hone your programming skills), Steveyegge's article suggests some good ideas. He referred to them as "practice drills":

1. Write a copy of your CV. Make a list of all the relevant skills you have, and then mark those that are used after 100 years. Give each skill a score of 10 points.

2. List the programmers you admire. Try to include those who work with you, because you will get some skills from them at work. Keep a record of 1 ~ 2 shining spots on them, which is what you want to improve.

3. Look at 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 you are interested in reading.

4. Spend 20 minutes reading through someone else's code. It's good to read good code and read bad code, both of which need to be read and switched in turn. If you can't feel the difference between them, you can turn to a programmer you respect and let him show you what good code is and what is bad code. Give others the code you've read and ask them what they think.

5. List your favorite 10 programming tools--those that you think you use the most and do not. Randomly pick one of the tools and spend one hours reading its documentation. In these one hours, try to learn something new that you didn't realize in the tool, or discover some new way to use it.

6. Think about what you are good at besides programming. Think again, how did you become so skilled and professional through the exercise? What is the inspiration for your programming? (How do you apply these experiences to programming?) ）

7. Take out a stack of resumes and spend one hours in the same room with a group of interviewers. Make sure that each resume is seen by at least 3 interviewers and that you have a score of 1 to 3. Discuss resumes that vary widely from interviewer to judge.

8. Participate in a telephone interview. Write down your feedback afterwards, throw in your opinion, and talk to the person who is hosting the phone interview to see if you have reached a unanimous conclusion.

9. Have a technical interview and the person interviewed should be an expert in a field you don't know well. Let him assume that the audience is ignorant of the field, so ask him to speak from the very basics. Try to understand what he says and ask questions when necessary.

10. Have the opportunity to participate in other people's technical interview. During the period, you just listen carefully, seriously. While the candidate is trying to solve the technical problems, you have to try to solve these problems in your own mind.

11. Find someone who can exchange practical questions with you, every other week, to communicate programming problems. Spend 10 ~ 15 minutes trying to solve these problems, and then use 10 ~ 15 minutes to discuss them (whether or not they can be resolved).

12. When you hear any interview problem that you can't solve in the moment, go back to your seat and email it to yourself to stay as a reminder later. Find some time during that week and use your favorite programming language to solve it.

I liked Steve's list because it looked comprehensive. Some programmers think of "exercise", which is always considered to be some coding problems. But in my opinion, programming is more about people than code . Therefore, this approach is limited in improving your personal abilities by solving all the world's and obscure programming interview topics.

As for "hard learning", I also like Peter Norvig's recommendations in the article "Teach yourself Programming in Tenyears" (spent 10 years on self-learning programming):

1. Communicate with other programmers. Read someone else's code. This is more important than any book or training course.

2. Write the program! The best way to learn is to learn while doing.

3. Learn programming courses in undergraduate or postgraduate courses.

4. Find some projects to do, and need to work with other programmers to form a team. Learn to identify the best programmers and the worst programmers during the course of the project.

5. Work with other programmers in your project to learn how to maintain code that is not what you write, and to learn how to write code that is conducive to the maintenance of others.

6. Learn a variety of different programming languages, especially those that have a different worldview and programming model than the language you are now familiar with.

7. Understand the impact of hardware on software. Knowing how much time it takes for your computer to execute an instruction, how much time it takes to get a word out of memory (in the case of a cache or no cache), how long it takes to transfer data over Ethernet (or the Internet), how long it takes to read contiguous data from disk or to jump to another location on disk, and so on.

You can also get inspiration from Dave Thomas ' 21 Useful coding routines (codekata.com), or you'd rather join a local "programming martial" (codingdojo.org).

For "Hard learning", 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, "programming routines" requires only two moves:

1. Write a blog . I started the Codinghorror.com blog in early 2004 as a form of my own hard work. It was very humble at first and became one of the most important things I have ever done in my career. So, you should also write a blog. Finally, "Marketa in the world" is often the people who can write and communicate effectively. They have the loudest voice, they are making the rules of the game, and leading the world trend.

2. actively participate in the famous open source project . All that talk sounds good, but are you a liar or a doer? It's very important not to talk about it, because people will use your actions to measure you, not your words. Try to leave something really useful in front of the public, and then you can say, "I've worked on that project." ”

When you can write wonderful code, and can use the wonderful words to explain the code to the world, by then, I will feel that you have mastered the most cattle coding routines!

The most bullish B coding routines