Skip to content

Code and need to practice….

May 14, 2008

So you need to practice — not just to improve your skills, but also to keep yourself from becoming obsolete. Studying by itself doesn’t cut it, either; you have to use a technology in order to gain any real familiarity with it. That’s why this essay is really about study and practice. Great programmers do both.

The majority of programmers have literally no idea how to practice, since nobody teaches it. So they simply don’t do it. The first step towards becoming good at practicing is knowing a thing or two about practice itself. Practicing for anything is generally best done via drills: short, high-intensity exercises designed to yield the highest return on the time you invest. In this essay I’ll give you a dozen or so drills that you can practice, in any order, at any time, as often as you like. None of them should take more than an hour.

However, before I get into some standard drills that good programmers do regularly, I’m taking you on a quick detour, so we can look at how practicing works in professions that have been around for centuries. Why? Because those folks are pretty darn good at it by now, and they may have some lessons for us.

=================================================

recipe for programming success:

  • Get interested in programming, and do some because it is fun. Make sure that it keeps being enough fun so that you will be willing to put in ten years.
  • Talk to other programmers; read other programs. This is more important than any book or training course.
  • Program. The best kind of learning is learning by doing. To put it more technically, “the maximal level of performance for individuals in a given domain is not attained automatically as a function of extended experience, but the level of performance can be increased even by highly experienced individuals as a result of deliberate efforts to improve.” (p. 366) and “the most effective learning requires a well-defined task with an appropriate difficulty level for the particular individual, informative feedback, and opportunities for repetition and corrections of errors.” (p. 20-21) The book Cognition in Practice: Mind, Mathematics, and Culture in Everyday Life is an interesting reference for this viewpoint.
  • Work on projects with other programmers. Be the best programmer on some projects; be the worst on some others. When you’re the best, you get to test your abilities to lead a project, and to inspire others with your vision. When you’re the worst, you learn what the masters do, and you learn what they don’t like to do (because they make you do it for them).
  • Work on projects after other programmers. Be involved in understanding a program written by someone else. See what it takes to understand and fix it when the original programmers are not around. Think about how to design your programs to make it easier for those who will maintain it after you.
  • Learn at least a half dozen programming languages. Include one language that supports class abstractions (like Java or C++), one that supports functional abstraction (like Lisp or ML), one that supports syntactic abstraction (like Lisp), one that supports declarative specifications (like Prolog or C++ templates), one that supports coroutines (like Icon or Scheme), and one that supports parallelism (like Sisal).
  • Remember that there is a “computer” in “computer science”. Know how long it takes your computer to execute an instruction, fetch a word from memory (with and without a cache miss), read consecutive words from disk, and seek to a new location on disk. (Answers here.)
  • Get involved in a language standardization effort. It could be the ANSI C++ committee, or it could be deciding if your local coding style will have 2 or 4 space indentation levels. Either way, you learn about what other people like in a language, how deeply they feel so, and perhaps even a little about why they feel so.
  • Have the good sense to get off the language standardization effort as quickly as possible.

=================================

The saying “practice makes perfect” is inaccurate, as any music teacher will happily tell you. Perfect practice makes perfect. I’d been practicing sloppily, and had become very good at being sloppy. For one thing, I was tensed up, trying to force my fingers to make the right moves. So I only knew how to play tensed up, which exhausts you quickly. I was actually doing all sorts of things wrong, more than I’d ever have guessed, but the details aren’t important. What’s important is that I was thinking about it all wrong.

Yes, you can get by without knowing any theory. But your playing is just parroting if you don’t understand how the piece was constructed. Knowing music theory can improve your playing in a hundred subtle ways, with the net effect being a much more professional performance.

But programming is a clearly a complex blend of art, science, logic, engineering, design, and craftsmanship, and we can borrow ideas from all those endeavors.

Practice Drill #1: Write your resume. List all your relevant skills, then note the ones that will still be needed in 100 years. Give yourself a 1-10 rating in each skill.
Practice Drill #2: Make a list of programmers who you admire. Try to include some you work with, since you’ll be borrowing them for some drills. Make one or two notes about things they seem to do well — things you wish you were better at.
Practice Drill #3: Go to Wikipedia‘s entry for computer science, scroll down to the “Prominent pioneers in computer science” section, pick a person from the list, and read about them. Follow any links from there that you think look interesting.
Practice Drill #4: Read through someone else’s code for 20 minutes. For this drill, alternate between reading great code and reading bad code; they’re both instructive. If you’re not sure of the difference, ask a programmer you respect to show you examples of each. Show the code you read to someone else, and see what they think of it.
Practice Drill #5: Make a list of your 10 favorite programming tools: the ones you feel you use the most, the ones you almost couldn’t live without. Spend an hour reading the docs for one of the tools in your list, chosen at random. In that hour, try learn some new feature of the tool that you weren’t aware of, or figure out some new way to use the tool.
Practice Drill #11: Find a buddy for trading practice questions. Ask each other programming questions, alternating weeks. Spend 10 or 15 minutes working on the problem, and 10 or 15 minutes discussing it (finished or not.)
Practice Drill #12: When you hear any interview coding question that you haven’t solved yourself, go back to your desk and mail the question to yourself as a reminder. Solve it sometime that week, using your favorite programming language.
Advertisements
No comments yet

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: