Learning to Finish Things

For many years I was a hobbyist programmer. I’d try out small projects, experiment, then move on to the next thing. This was a great way to learn a lot, but I’ve got almost nothing tangible to show from that era. Despite the best of intentions, every project reached a point where it started to drag, and I’d get bored and move on.

It was only a problem for the projects I worked on myself. Working for others, I never really found the same problems. It was a problem of motivation and focus.

More recently, it is different. Now when I start hobby projects, there’s a good chance I’ll cross that finish line, and have something I’m ready to share with the world. What changed? Well in part it is increased experience and maturity, things I cannot teach. But also, I have found some strategies and thought processes helpful, and other, very tempting ones, not so much.

In short, I’ve learned to finish, which is a real skill you can learn over time. I thought I’d share with you what has worked for me. Maybe it’ll work for you too. I make software, but I think this advice is generally true for any other spare time activities. There’s three sections – scope, motivation and distractions.


This has been repeated a million times, but it’s true: start small. No, even smaller than you are thinking.

For working on something you are not familiar with, I recommend you visualize all the steps needed, take your most pessimistic estimate, then tripling it. Most of the time of a project will be spent on things you’ve not encountered before, or don’t know how to do. So it’s impossible to have included those things in your visualized plan.

Further, there’s nothing more disheartening than finding you have overrun your personal deadlines. It turns a fun project into a march towards the finish line.

It can sometimes be tricky to find projects that fit such a small scope that you still want to work on. Sometimes it’s best to shrug and do something just to learn. It’s faster to learn something then apply that knowledge to a bigger project than it is to learn the same thing while working on the big project. You make so many mistakes while learning, a bigger project just means your mistakes are bigger and take longer to fix.

But if you are struggling to find something small, I also like flex projects. This is where you plan and dream as much as you like, but you decide up front what is the Minimum Viable Product and what is additional work to improve things from there.

Then finishing only really means getting the MVP done. Anything else can be dropped if needs be. This works well for me because I’m so driven towards the extra parts, by the time I get there and realize they are harder than I thought, I’ve already got something worthwhile!


When doing something for yourself, a project doesn’t usually fail because you run out of time, or money. It fails because you no longer have the will to go on. This often manifests as all sorts of rationalizations, but fundamentally it’s this one thing you must guard against.

While ideally you should be doing something you love, everything worth doing has some parts that you are not going to enjoy. The mistake a lot of people make is to do all the fun things first, and leave the boring parts to the end. That never works! Merely being near the end of a project doesn’t motivate you to finish it, it just taunts you with the slog remaining.

Keeping that slog small both means taking care of the scope (above) and spacing out the fun and boring parts of work. Like many, I find documentation and tests tedious, but they are so much easier if you do them simultaneously with the meat of a project. And bonus: if you do decide to cut your losses and finish early, you are ready to do so at almost any time.

The other half of the mental fight against motiviation is your frame of mind. For me, the most deadly problem is daydreaming about how great it would be to be finished. How successful and popular the project will be, what I’ll do next, why I was such a genius for coming up with the idea in the first place.

These thoughts are very warming, but they don’t spur you on to actually do any work. None of them are about the project itself. Instead, think about the next milestone, no matter how small, and imagine what it would take to get there. That way, every step of the project delivers you that feeling of acomplishment, not just the final one.


When my motivation dwindled, inevitably some new, better idea would come along. I’d think “Why work on this thing, it’s clearly not working out, and besides, this new idea is far better”. I’d then drop the old project and move on. Rinse and repeat, and you quickly find that you have the first half of a lot of different ideas, and the second half of none of them.

Ideas always sound the best immediately after you’ve first thought of them. They lose their power over time, and the temptation to switch goes away. That’s why I write down all my ideas in a notebook, to return to later. Getting them down this way means you can review them later when you’ve had a chance to think of the downsides and impracticalities. It also reduces my anxiety that if I don’t start work on this brilliant thing right now then it’ll be lost forever. It’s not lost – it’s in my notebook, and for the vast majority of notes, I’m happy to never return to them.

Another habit I’m prone to is Yak Shaving. This is a concept specific to programming: while starting your project, you find something foundational is missing, so you decide to fix that first. Only, while looking at that, you find something else that needs fixing, and so on. Sometimes this can be a good thing and in fact my most recent project came about when I found I was unsatisfied with some existing libraries. But you need to recognize that these diversions are in fact new ideas, and need to be evaluated as such. Do you absolutely need it? If not, it goes in the notebook, for review later.


The same items again in bullet points:

  • Pick projects of an appropriate size. Triple your estimates in areas you are unfamiliar with.
  • If you have skills to learn, try to separate that from the work of doing the project itself.
  • Plan your projects so you can skip nice-to-haves if push comes to shove. Do the MVP first.
  • Do the interesting and tedious parts together, don’t front load the fun.
  • Concentrate on the here and now, not the final form of your project.
  • Write down your ideas instead of immediately jumping on them. Reviewing the notes later is optional.
  • Avoid Yak Shaving, accept that sometimes you need to get stuff done in a world that is imperfect.

There are you have it. I hope it helps. Am I a machine of productivity today? No, not in the slightest. And I don’t aim to finish everything, either – there’s a lot to be said for learning projects, just noodling around, or creatively exploring. But when I do put my mind to something, I have the right attitude and I have the positive reception of past projects to back that up. That gives me an inner confidence to see it through to a conclusion.

Just remember nothing needs to be perfect, or 100% finished. If a project is mostly there, you can always just release it without that final… (TODO: find bon mot here).

One thought on “Learning to Finish Things

Comments are closed.