Brain rot, not code rot

Mon Mar 24 2025

Early last year I started working on an open source project, related to handling downloads (and sync) of large folders and their data. Think software downloaders, application hubs, and backup software. It’s not a novel space, but it is also one with room for new libraries (and this is something I need to then work on a related project). So I set to work and made good progress.

Then I burned out.

Welp.

Don’t worry, not serious burnout. I just got to a hard part, other things turned up to steal my focus, and before I knew it a year had passed and I’d not made any progress in that year.

Time to turn that around then, right?

Right.

I’m keen to get back into it, so I got back into it. And my word, it was hard. Despite being extensively tested, and written in a language with a confidence inspiring type system (Rust), wrapping my head around the concepts and structure was super difficult. It took me a good half day to get back into the headspace I’d been in the previous year. And this made me seriously consider what steps I could have taken in the previous phase to minimise the difficulty I would feel when coming back to it.

This is what I settled on. It is written from the perspective of a personal project, probably an open source one.

A list.

• Assume you will abandon your project, at least for a time. Don’t defer the soft stuff to the end, because you will need it in the middle.
• Document as you go. It can be tempting to write the docs once you have settled the API and implemented a PoC, but you will probably regret it. See the previous point.
• Take the time to do some basic planning. It doesn’t have to be super detailed (this is likely to make it feel like work), but having some clarity about what your goals are and what your feature set is will help you a) stay on track and b) remember what that track even was when you return after a year in the wilderness. Where you keep the plan doesn’t matter, just keep it somewhere you will be able to refer to later.
• Minimise the scope. This is the best way to try to avoid burning out and backing away from the project in the first place. It’s much easier to stay motivated to work on small improvements to an already “released” project than it is to get a very work-in-progress one over the line.

Not exhaustive, but hopefully of use to somebody.

If you’ve got anything to add, please drop me a line; my contact details are in the footer. And once I actually finish this thing I’ll be sure to mention it here.