Last month I read Coders at Work, a collection of Q&A interviews conducted by Peter Seibel with 15 of the top computer scientists of all time. There were some common responses that tied each of these programmers together. I like to think it’s their inadvertent advice for aspiring programmers.
Read other people’s code. This sounds like an inane task. Who wants to waste hours of time reading code with so much good literature out there and so little time to read it? Their arguments were simple: seeing someone else’s thought process is beneficial, you might learn something new, and you may learn how good—or bad—code is organized. Douglas Crockford has an interesting method for reading code. He organizes the code before reading. This allows him to focus on the content and not the organization. Others print out code to annotate it.
Learn to write well. Nearly every programmer agreed with this point: programming is more like writing than math or engineering. It’s true, there is an exorbitant amount of math, nay logic, in computer science, but writing a program others can understand is more like writing a novel than a collection of equations.
Learn one language well, then learn other languages. Learning a language well means understanding the methodologies, not just the syntax. Also, learning a language from different types of programming—procedural, object-oriented, declarative, etc.—can be beneficial as each type approaches different problems in different ways. This can influence the way you view your main language.
IDEs and debuggers are overrated. This does not mean IDEs and debuggers are bad. This simply means they are not the best tools to use when starting out. By all means, use them if you are a seasoned programmer. I am apt to agree that IDEs are bad, though. They potentially create hundreds of lines of code without your knowledge, give you far too many hints, and generally dumb down the craft of writing a well-formed program. Debuggers, on the other hand, can be extremely useful if you know how to use them. The unfortunate step is learning how to use them. Stick with a simple text editor—vim and Emacs are wonderful—and use print statements for debugging.
Practice, practice, practice. You can’t learn a craft unless you practice it often. You can’t improve unless you practice it daily. Based on some other reading, pace yourself. If you plan on practicing 5 hours a week, practice 1 hour each day. Cramming is not the same as practicing.
A deep understanding of complex math is not necessary to be a good programmer, but it may be necessary to be a great programmer. Donald Knuth describes himself as a mathematician and a computer scientist. He’s also a phenomenal programmer. Now, there are plenty of mathematicians who are lousy programmers, so the argument falls apart, but understanding discrete mathematics—or any high-level mathematics—can only improve your understanding of computer science and programming.
Read the classics. This is the same advice I’d give to anyone in any field. Read the classics if they exist. There’s a reason they’re called classics. My first thought would be, “What are the classics?” Mr. Seibel asked every programmer, except Mr. Knuth, if they’d read The Art of Computer Programming, by Donald Knuth. Also, Edsger Dijkstra’s A Discipline of Programming was frequently referenced. These two books (the first is a series) seem like a good place to start. Each programmer also listed books they’d recommend for anyone from novice to expert.
Learn C, not C++. Neither is great, but C is better than C++ simply because it’s smaller. Some programmers defamed C++ while others were ambivalent. Regardless, learning C seems like a good place to start if you’re familiar with programming. Otherwise, I’d suggest Python or Ruby as they protect you from making silly mistakes that C and C++ won’t.
Start with pencil and paper. A bad design in a new or great language is still a bad design. Think through the problem as much as you can. Start by writing it. Then take it to the machine. If you hit a snag, rinse and repeat.
Brainstorm with the hive mind; program in a vacuum. Brainstorming with a few people can turn you on to multiple solutions. No two people think exactly alike. Ambivalence was rampant on eXtreme and paired Programming. Basically they all agreed that XP(eXtreme Programming) and paired programming work well, but they usually benefit only the weaker individual.
Multicore processing is the future of programming. Start wrapping your head around it.
I’m still mulling over their advice. Some of it seems quite controversial, though most of it is quite good. One thing I’m trying to keep in mind is most of these programmers started programming at the dawn of the age. There were small systems, small languages, and small groups of like-minded people. They could keep it all—the architecture, the memory states, the language, etc.—in their heads because it was such a small set to remember. Now, the languages are larger, the machines are faster, the memory is gigantic. They were born at the right time to be demigods.