Side projects for Engineers - Is it better to focus on 1 or many?

15 hours ago

3 min read

You've got three project ideas and time for about half of one.

One could become a useful app. Another would teach you a new skill. The third is simply too interesting to ignore.

Should you choose one and commit, or keep several moving at once?

I don't think the answer is the same for every stage of a project. Exploring possibilities and delivering something are different jobs. Trouble starts when you expect to do both indefinitely without making a choice.

Decide what the project is for

Are you trying to learn, finish a useful tool, build a portfolio or explore a possible business?

A learning project can be worthwhile even if the result never becomes a product. A tool for your own use can succeed with a small audience. A business idea needs evidence that someone else has the problem and values the solution.

Write the goal down.

It gives you a way to compare projects beyond which one happened to excite you most this morning.

It also helps you stop changing the definition of success whenever the work gets difficult.

Give one project the next meaningful finish line

If finishing matters, choose a main project for the current period.

Then define a result small enough to reach. A working prototype, a tested feature, a playable level or a useful first article can all be meaningful outcomes.

“Build a complete platform” is more likely to become a permanent item in your notes.

Choose the smallest version that demonstrates the main idea, and write down what is outside this version. That gives you somewhere to put the features that would otherwise keep delaying completion.

Keep other ideas without making them active

An idea doesn't need to be forgotten just because you aren't working on it.

Keep an idea list with the problem, the possible approach and why it interests you. Add a sketch if that helps you remember it later.

Then go back to the main project.

This removes some of the pressure to start every idea immediately. You have captured it; you can make the choice when you have capacity to act.

An idea list is useful storage. It isn't a promise that every entry will become a project.

Allow a small experiment when it serves a purpose

There can be a good reason to have a secondary project.

Perhaps the main task is waiting on a component. Perhaps you need a short creative break, or a small experiment can teach you something relevant.

Give that experiment a boundary: one question, a limited amount of time and a decision afterwards.

For example, try a different design tool on one graphic and compare the result. Don't quietly turn a one-evening test into a complete redesign of the project.

I explored that kind of change in how to get past your creativity block.

Distinguish a blocker from an uncomfortable task

Sometimes you switch projects because progress really depends on something unavailable.

Sometimes you switch because the current job is testing, cleanup, documentation or showing someone an imperfect version.

Those jobs can feel less exciting than starting a new idea, but they are often part of getting a project over the line.

Name the next action before you decide the project is blocked.

“Need to improve it” is vague. “Need to fix the restart behaviour and test it three times” gives you work you can schedule.

Plan around the time you actually have

A side project has to fit around the rest of your life.

Estimate the sessions you can reasonably protect, rather than assuming every free evening will become productive development time.

Leave yourself a restart note so the next session begins with a clear task. Keep dependencies and setup simple where you can.

If you regularly have less time than planned, reduce the scope or change the target date. Carrying an unrealistic plan forward doesn't create more capacity.

The maker versus manager schedule article looks at arranging different kinds of work.

Review, finish or deliberately stop

At a sensible milestone, check what you have learned and decide what happens next.

Continue, narrow the scope, release the result or archive the project. Any of those can be reasonable when the reason is clear.

What you want to avoid is keeping everything nominally active, with no project getting enough attention to reach a useful outcome.

My practical answer is to choose one main deliverable and keep exploration small enough that it doesn't consume the delivery time.

You can have many interests. Give the next thing you want to finish a fair share of your attention.