Learning from Projects

By Dylan Thinnes, Last Edited Thu 29 Aug 23:45:37 BST 2019

After starting so many projects, and finishing maybe only 1 in 10 of them, I’ve decided to come up with a small list of guidelines that will (hopefully) help determine the suitability of a project and help turn projects that aren’t suitable into projects that are suitable.

Additionally, this guide will make me think twice before jumping off on yet another grand software adventure that inevitably ends with nothing of value.

0. Limited Scope

The project should cover a topic small enough to discuss fully in one post or one talk.

If the scope is too large, you are likely to stop halfway through and find something newer or cooler to do, or you’ll simply get tired of the idea, or you’ll become too busy to allocate time to it. The end result is a lot of wasted effort.

If you really have a fun idea that is quite large, you can either try to break it into pieces, or find a friend who’ll work on it with you.

There is no opposing limit to how small you can make a project.

1. Clear Purpose

The project should tackle some clear goal or problem, set at the beginning.

Note, this problem/goal doesn’t need to be big, nor does it need to be for other people. If your problem is an obscure math equation that you want a solver for, that is fine too - what’s important is that you clearly aim for that goal and only that goal. Everything else is secondary, and any new interests should spin off into their own project.

There is another aspect to the guideline of purpose - if the end objective is to monetize the project, that ought to remain in mind from the beginning. If you would prefer to keep the project pure and personal, make that clear from the outset too.

2. Novel Yet Understandable

The project can require knowledge you do not yet have, but you must know where to find any such missing knowledge.

The most fulfilling projects tend to be novel, something you haven’t done before and something you don’t necessarily know how to do in full. They require some planning ahead, and definitely some reading.

However, it is easy to fall into the trap of taking on something entirely too large and completely alien to you. If you can’t understand the intro page for the topic at hand, it is unlikely you will be able to do something complex on that topic, and it is even less likely you will enjoy allocating time to it.

The best solution to a project that fails this guideline is to scale back your expectations initially, and think of a project which covers just that introductory material. After that’s done, if you really want to, you can continue to the original idea.

3. Care

The project should ultimately touch on something you care about.

You shouldn’t create a webapp simply because you think it’ll look good on your CV or because other people are doing it.

At the end of the day, your own personal time will be spent on projects and thinking about them. This is time that could be better spent elsewhere, on family, friends, or games.

This guideline rings especially true if you are toying with the idea of ever making money off of the project. If so, time should be budgeted for it and you should recognize any hours spent on it as work and ration them as you’d feel comfortable doing with, say, a volunteering position or extracurricular.

Final Thoughts

Note that projects aren’t the only way to move forward - explorations, whether that involves playing around with some datasets or twiddling equations and seeing what falls out, are great springboards from which you can decide what you want to learn about.

Finally, as with any guidelines, Orwell’s (modified) sixth rule applies:

Break any of these rules sooner than do anything outright barbarous.