Coding exercises seem like a great idea if you want to learn coding. If you want to learn a practical skill then you should practice, right?
And yet coders don’t do a lot of them. Some, but not a lot. And the longer you’ve been a coder, the fewer of them you seem to do. Ask your favourite long-term veteran coder. A few of them will act guilty that they don’t, but almost none of them actually do coding exercises.
Why don’t we?
I could rail about how silly that is. But I won’t. If nearly everybody doesn’t do something, it’s usually because it’s not as good an idea as it seems. They used to tell us to all use flowcharts for designing program logic. We didn’t. We were 100% right on that one.
We’re basically right about coding exercises, too. But there’s a better alternative that a few people do, especially long-time coders. That’s what you should actually be doing. It’s more fun, too.
But before we get to what you maybe should be doing, let’s talk about why you’re right about most coding exercises.
I have an exercise you can do to tell if your Big Rewrite software project will work out. It’s a simple one, but a good one. But first, a story.
Back in 2013 I worked for a company called OnLive. They brought me on as part of a project called “Valhalla” to rewrite a big chunk of their existing system...
You know the Golden Child Engineer, the favourite of the Director of Engineering? He’s that guy (and it’s basically always a guy) who’s the company Teacher’s Pet? The software developer who gets promotion after promotion?
You’re not that guy. With one fun exception, I haven’t been either. And I’ve...
A reader wrote me an email recently. That’s always a good feeling! He had a question about Mastering Software Technique and general code learning that I’ll bet a lot of you share: it’s easy to go off the rails doing useful things rather than what I recommend. But why? Is it a problem? How can it be...
Like most developers who have been developing awhile, I have my favoured ways to keep myself productive. Most are standard: careful use of caffeine, a frequently-curated TODO list, an obvious place to check my priorities, occasional retrospectives and so on.
I also have a few less-common ones that...
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.
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.