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.
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.
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.
Subscribe to get free ebook chapters and an emailed coding class now, plus videos and articles a few times a month.
Why this specific newsletter? You want to be an expert. Expertise comes from learning the fundamentals, deeply. And that comes from the best kind of practice.
I write with that in mind. I won't waste your time.
(Yes, I also sell things. They're good, but I'm fine if you don't buy them.)