I help folks practice to get better at writing software. So sometimes I’m asked, “how do you practice well in general?” A lot of my answer comes from The Talent Code, by Daniel Coyle. I find that the good books basically agree about what makes good practice. I’m also quoting this article for a few...
In a moment, all of you readers are going to hate Matt Bird. I get it. I hate him too.
He’s a professional screenwriter who also wrote a great book about how to write. You’d think that might excuse him a bit, but no, I’m not letting him off the hook. Some crimes are unforgiveable. You’ll see.
Here...
My kids are mercifully distracted for a few moments. The giant jumble of colored blocks on my calendar has a gap right now. No due dates are marked in red in my overgrown to-do list.
I am free to practice. I have skills I certainly want to practice.
And here I am, staring dully at the teddy bear next to my monitor, not practicing. Why? Here’s one: I am afraid of wasting this precious practice time, of throwing it away on nothing worthwhile.
What if I’m practicing wrong? What if there’s some better way to do it, and I’ll be sad that I bothered? What if I’m a sucker because I’m putting in hours that do me no good?
I can’t magic my fear away, but I can talk through it and explain it. I always feel better afterward. Care to come with me on this little journey?
Steve Martin has a great autobiography about his comedy career called “Born Standing Up.” Like many comedians, he’s a smart guy and has great advice about practice and improvement. You can get most of the same thing from this interview, if you take time to read it.
He talks a lot about his early comedy and how it just doesn’t quite work (he’s right, it doesn’t - go back and watch.) He has some really interesting new ideas, but he doesn’t yet understand the important old ideas. He wasn’t good at physical comedy yet, his timing was off, he was clever but not consistent. He knew it wasn’t working and he wanted to say, “but wait, let me explain my theory!”
I’m a software engineer. Is it just me, or are there an awful lot of us whose pet theories don’t quite work, and when we’re called on it we say the same thing?
Until you have the fundamentals right, your new ideas mostly don’t work.
It’s fun to write about different ways to practice coding. But “how to practice” only gets you so far - at some point you have to actually do the practice.
There are a lot of neat programming exercises in the world. This is an example of one I call a “coding study”, and I think it fits my definition of a good exercise.
A coding study is like an artist’s life study, but for code. You’d normally pick your own design. But this is meant as a simple introduction, so I’ll suggest a little more than usual.
The theme today: ivy on a window. I’ll refer to the picture below repeatedly in this post - have a look, then scroll back here as needed or save a copy locally.
One hard thing about exercises is that you need different habits for them than for production code: you’re not trying to write polished, production code. Instead, you’re trying to learn as fast as possible. So at the end, I’ll talk about some intentionally weird things I do in this code and why.
(You can see the five-minute video version of this post on YouTube.)
I’m an old-school programmer. I’ve been doing this for 30 years. I worked for over a decade in C and C++, often on operating systems and device drivers.
If you ask, “how do I get better at programming,” I’m supposed to tell you:
These are all terrible advice.
And they’re all variations on a different, wrong idea: that you should learn about computers and software past all the abstractions, “all the way to the bottom.”
That’s also terrible advice. Let me tell you why.
Here’s a difficulty of coding exercises: many teach you nothing after the first time you do them. So you have to find new ones if you want to learn.
It’s the same reason you don’t learn much by just learning all the “gotcha” job interview questions - there may be a secret to it (advance two counters until they meet! fourteen per floor minus one per drop!) but it’s not a very interesting secret, or a secret you’ll use much later.
Good secrets usually show up in packs, not alone.
Here’s a “pack secret” like that - just the first of a big group: “a good exercise is one you can do over and over and get something useful out of it each time.” Here’s one of its pack: “good exercises are never just about the specific situation.” And another: “good exercises work even if you switch them up a little.”
There is a technique of writing software - that is, actually writing code. It’s a distinct, separate skill from creating or analysing algorithms, or doing up-front design or agile project planning. It’s also a distinct skill from any particular library or language or paradigm (like functional, OO, etc.)
It’s not really taught much. It’s pretty hard to teach directly.
I believe strongly that you need the right kind of practice - careful, mindful practice. I’m writing a book about that, and writing related principles on my blog. I’ve found some techniques that work, and I’d love to share them with you. You can also sign up for my email list to get an email class about this. And I have a topics page about it.
Today’s principles: practice with a single idea in mind; practice with a time limit.
In most projects, the first system built is barely usable….Hence plan to throw one away; you will, anyhow. - “Fred Brooks, The Mythical Man-Month”
Sometimes it’s a superpower if you take and use good advice that most people don’t follow. But there’s nearly always a reason they don’t. So you need to figure out why other people can’t, so that you can.
Here’s one of my favourites: rewrite once and throw the first away because you will anyway.
From Fred Brooks’ The Mythical Man-Month, one of the oldest books about getting software written, to Chad Fowler’s keynote about “Legacy” in software, you can find many years’ of expounding the virtues of rewriting our software - in a careful, controlled way. Keep in mind that Chad Fowler is also the guy who wrote the series telling you to never do The Big Rewrite.
So, okay, there’s some subtlety to it. What’s the right way to do it?
I often teach developers for my job, so I collect fears. Most teachers do. Your grade school teacher probably told you that you had to pay attention to boring math and/or history so that you could get a job (and not, by implication, live in a van by the river.)
So when I hear the same fear a lot, from a lot of different people, I pay attention.
I’ll bet that you don’t think you know “The Computer Science Thing” well enough. New folks like Boot Camp grads think so. So do recent college grads. And not-so-recent college grads. And veterans who “haven’t been keeping up.”
