Whether it’s building a new project from scratch, implementing a big feature,
or beginning a large refactor, it can be difficult to stay motivated and
complete large technical projects. A method that works really well for me
is to continuously see real results and to order my work based on that.

We’ve all experienced that feeling of excitement starting a new project.
The first few weeks you can’t wait to get on the computer to work. Then
slowly over time you get distracted or make up excuses and work on it less.
If this is for real work, you forcibly slog your way to the finish line but
every day is painful. If this is for fun, you look back years from now and
remember what could’ve been.

I’ve learned that when I break down my large tasks in chunks that result
in seeing tangible forward progress, I tend to finish my work and retain
my excitement throughout the project. People are all motivated and driven
in different ways, so this may not work for you, but as a broad generalization
I’ve not found an engineer who doesn’t get excited by a good demo. And the
goal is to always give yourself a good demo.

I’m not claiming that anything I say in this post is novel. It definitely
shares various aspects of well-known software engineering or management
practices. I’m just sharing the way I approach the larger technical work
that I do and why I do it this way.

I’ll use my terminal emulator project
as an example throughout this post so that there is realistic, concrete
experience I can share. There’s plenty of other projects I could’ve used but
I’ll choose this one since it’s not related to my professional work and
it is recent enough to be fresh in my mind.

Initially, you have some large project and you have to figure how to start.
For me, this is the hardest part and I can spend hours
— sometimes days — waffling over the right starting point.

For my terminal emulator, there were a number of large components that
I knew would have to exist if I ever intended to finish this project:
terminal parsing, running and managing a shell process, font rendering,
grid rendering, input handling (keyboard/mouse), etc. There are hundreds
of relatively large sub-projects on the path to “done.”

If my initial goal was to see a launchable terminal that could run Neovim,
I’d be in big trouble. Even with unknown unknowns,
this goal just sounds too big. I can intuitively realize that
there are a lot of components on that path: rendering a GUI, process launching,
terminal parsing and state management. This is a bad goal, it’s too big and
I’d probably lose interest a month or two in.

Instead, I try to think what a realistic project is where I can
see results as soon as possible. Once you apply that filter, the number
of viable sub-projects shrinks dramatically. Here are some examples:

• VT Parsing –