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.

What Makes a Single Idea?

A “single idea” sounds pretty good, but how do you tell? A bit like the single responsibility principle, you’ll learn over time based on what works.

Here’s a start: you should be able to write, very simply, what you hope to learn in a sentence or three. And you should write that down before you start the exercise.

There are a many, many ways you can pick your idea. In every case, try your best to keep it small. Here are a few methods:

A Tool You Want to Learn: In this case, your idea is something like “learn the Elm language” or “use EXIFTool to do interesting things with photo data” or “figure out how to use Postgres JSONB for a document database.”

A Task You Want to Learn: Similar to the above, but with a task. It could be “draw graph points on a rotating globe” or “make a music file play at double speed”; by focusing on the task instead of the tool, you remind yourself that your normal tool may not be the easiest or best way to do it.

An Ability You Wish You Had: do you know somebody that does something cool? Or have a programming superpower you envy? Pick a step toward that and do it. That might be “rewrite an old shell script using Ruby and functional programming” to start learning functional programming or “build a Puppet manifest for one piece of my server” or “print out an ASCII-art animation on the console to show an algorithm.” Pick something to make you better in a way you care about.

A Decision that Scares You: do you have a problem at work or on a hobby project where you’re not sure what to do next? Build a miniature prototype to help learn about it. That could be “test out MongoDB for a simple document database query” or “try building an API with mandatory paging everywhere to see if I can stand using it.”

In every case, try to keep it small. You want something where you can learn the most – and that means a small, focused idea that you can start quickly and throw away afterward.

What Kind of Time Limit?

You’ll also hear this idea called “timeboxing.”

Basically, decide in advance how long to work on an exercise and then be done with it. If you go over time, stop.

How do you know how long? Basically, take how much of your time you think it will take and then figure out how much time you have to devote to programming. Think it’ll take six hours, and you have three hours a week to program? That would be two weeks if you were right… And you won’t be. At first, double your estimate - you’ll figure it out more specifically over time. So instead of two weeks for that example, say four weeks.

Write down the time limit before you start too - just like the idea.

What happens if you didn’t finish but you were so close…? Then you probably learned a fair bit before you finished. Well done! Now stop.

What happens if you were wrong about how much time you had for it? Then you’ve learned something important about how much time you have… And/or you didn’t actually find the idea as exciting as you thought. Either way, stop and pick a new goal.

What if you’re done way early, or you just don’t like it? Normally, you’d stop. I suppose you could add a “stretch” feature as long as it fit in the original timebox, but… Usually you’re better off declaring victory and moving on. Is it still victory if you decide you didn’t like it and lose interest? Absolutely. You’ve learned something important, and you’ve done it even faster than you scheduled!

But Why?

I’m saying this like these are rigid rules. According to the iron programming maxim of “It Depends,” there should be some reason - some consequence for not doing this, or some benefit to doing it this way. What’s the reasoning?

When you’re practicing to get better and not for a job, you don’t have somebody else breathing down your neck about the scope or what you’re allowed to do. It’s easy to go off the rails - to keep working on some tiny trivial detail, or to never get started on an awesome big project because it seems to hard to even start.

You fix those problems with a timebox, chosen in advance, and a small purpose, chosen in advance. You try to earn a small victory, and you work toward learning rather than usage. If you hit a project you’re massively excited about you’re going to take off like a rocket anyway, right? The trick is to move forward until you find your awesome project. With a constant stream of small, valuable practice you make it easier to get there, and you make yourself better.

Until, by the time you reach it, that big intimidating project is something you can tackle easily. You’ve been getting better, doing bigger and better projects and getting used to the rhythm of it. And when you meet the right project, you can just dig right in, no problem.

Practice is magic.