The chapter this week from
My Job Went to India
tells us to "Practice, Practice, Practice." It's pretty obvious advice - if you practice something,
you will get better at it. Assuming that skill has value, you'll be able to market yourself easier.
What's not so obvious is that we are "paid to
perform in public - not to practice."
Unfortunately, most of us practice at our jobs (which is another reason we started the Code Dojo).
Perhaps because the advice seems so obvious is why when I reread this chapter, I realized I hadn't
done much about it. Sure, I do a lot of learning and coding on any given day, but it's been
rare where I've truly stretched the bounds of my knowledge and skill. And as Chad notes in the
chapter, that is precisely the point of practice.
Specifically, we might focus on three areas when practicing, which parallel Chad's experience
as a musician:
- Physical/coordination: Visiting "the dusty corners of your primary programming
language," such as deep exploration of regular expressions, tools, and APIs you
rarely (or never) get a chance to use at your day job. I'd put learning other
languages here, and experimenting with new constructs and paradigms, like you can
win an iPod Nano for doing.
You may not use it often, but when you need to, you'll be prepared. On the other hand,
you may find something that used to take you hours can be done in one line of code - it's
built right into the language.
- Sight reading: If you can sight-read code, how much faster would you be at finding and
diagnosing problems, or adding new features, just by having the ability to understand
the structure of an application instantly? Chad recommends going to the to-do list
of an open source application, deciding on a feature to implement or bug to fix, and
then going through the source to find out where it needs to go. Impose time constraints on
yourself, and rotate through many different projects (and languages), and you'll get
faster at "sight reading" code. You don't even need to implement it - just finding the
place to put it would be enough (but it would be even better if you did!).
- Improvisation: Chad defines improvisation as "taking some structure or constraint and
creating something new, on the fly, on top of that structure." One such example he
described was
recovering lost data by manually replaying packets over a wireless
network from a binary log file. No body meant for you to do these things, especially
not in the heat of the moment. [But] that kind of sharp and quick programming ability
can be like a magical power when wielded at the right time.
Of the three, I really like his ideas on practicing improvisation: "Pick a simple program, and
try to write it with [self-imposed] constraints." One example is printing the lyrics to
99 Bottles of Beer on the Wall "without doing any variable assignments." Or
golfing.
I'm sure you can think of others (and I plan to).
I haven't done as good a job at practicing as I'd like to, so I'm going to resolve to sit down
weekly and just have some practice time, stressing the points above. I won't be too ambitious
though - I've already over-committed myself for the rest of this year. But as my early
New Year's Resolution, I'll plan on blogging my weekly experience in
regularly scheduled practice,
like
Scott Hanselman does in his series, The Weekly Source Code.
Anyone want to lend some moral support and start practicing too? We could be like virtual
workout partners, flexing our coding muscles.
Note: I didn't do a good job of showing it in the article itself, but all the quotes there
are from Chad Fowler.
Hey! Why don't you make your life easier and subscribe to the full post
or short blurb RSS feed? I'm so confident you'll love my smelly pasta plate
wisdom that I'm offering a no-strings-attached, lifetime money back guarantee!
Leave a comment
There are no comments for this entry yet.
Leave a comment
