Sustainable code: the antidote to burnout?

posted on Nov 12, 2025

I've been off work recently. I've had some pretty serious heart issues that my doctors think might be POTS. It'll take a while to get diagnosed. I'm coming out of my flare up now. But in the lead up to and peak of my flare up? I was in the midst of horrific burnout: impossible deadlines lead by a profit rabid CEO, a code base of 50k+ lines with crippling technical debt and no refactoring.

I've taken the last 2.5 weeks off. As a contractor, it's not been PTO. But god its done me good. I also discovered that maybe, I wasn't burnt out by coding. No, I was burnt out by profit driven development.

I resumed working on my FOSS side project. I can never leave coding for long! While doing so? I felt friction in all sorts of places. Outdated variable names, barely any separation of concern, poor file structure to name a few issues.

In this moment it hit me: this is MY project on MY time! It's a FOSS project, I don't give a shit about profit driven deadlines, there are none!

😍 The joy of refactoring

I got to work with refactoring. Starting off with a new abstraction layer. Electron has a renderer, which is your browser part, and a "main", which is where your "Node JS" type functions live. They have much more access to your system than what you can do in the renderer alone. Between your "main" and renderer, you have the preload. Preload is what exposes your functions in main to the renderer.

So you'd write your functions in main, give them a "channel" name. Then, you'd go over to preload, and you'd need to remember the channel name, and the functions arguments to expose it to the renderer. This lead to frequent fuck ups, annoying bugs and just... So much friction and context switching.

I basically designed a system that allowed me to create files with their functions as channels. As long as I pass on the file import to my new system, it will automatically register the channel, along with the function with the correct order of arguments (while excluding the event argument which kept throwing things off!). Preload is able to look at this system and register the functions under their respective channels automatically.

This was a HUGE deal. Suddenly, instead of fighting with the code base I could craft with it. Instead of all my energy, time and will power being poured into channel names and function arguments across 3 files... I was able to actually think about the problems at hand.

As a result, this gave me the energy and motivation to switch the React portion of my app from vanilla useState to Zustand. Another GAME CHANGER. It made my app easier to understand and work with.

It forced me to refactor several other things that needed changing, and my god... The React part of the app is SUPERIOR to work with now. Before, it was confusing to understand and work with. Now? It's difficult to believe that my app that does all of this actually just boils down to this very simple code.

By reducing the technical debt? It's made development so much easier, less energy intensive and faster. The code base works with me instead of against me.

🐢 Developing slowly

This has me thinking... How many developers out there are being robbed of improving their skills because of profit driven development?

This side project taught me better state management, cleaner code writing and much more. Not only have I become a better developer for it, but my project has grown massively. All because I wasn't chasing some profit driven deadline.

Ironically, taking the time to develop slower and focus on refactoring the code has made it easier, faster and less energy intensive to develop new features.

Whenever I work on it? I'm so happy. Everything works in harmony. The codebase keeps me coming back for more. I can't say this about any commercial product I've been contracted to work on.

I'm so fucking sold on the idea that we should be working on codebases that are so elegant they're addictive. That's my project! It nourishes my capacity, and gives me more thinking power to dedicate to the more complex problems. Developing in a why that reduces context switching, that makes things as obvious as possible...

Just imagine the possibilities. Just imagine if more companies in tech worked like this. Imagine how many devastating security bugs would be avoided. Just think... The reduction in burnout would be huge. Better yet? The end product would be of superior quality too. And yet? Because the CEOs are so rabid about their profits, they'd rather get a 2 second sugar rush than a sustainable, devoted client base who care about the quality of product.

Honestly, if there was a unicorn job out there that was interested in cultivating this environment, I'd apply yesterday. But tragically, those sorts of companies/orgs are far and few between. One in a million!

Conclusion

Quite honestly, all of this is why I'm starting to give up with finding a job. It's why I'm researching going back into healthcare via nursing (more on that in another post). I'm going to keep applying, just incase... But it sure isn't looking good right now. However, this is also why I'm investing so much more time and energy into my main FOSS project (can't name it here, I want this blog to remain separate from my IRL identity), because I have a business idea I can make from it. Maybe, just maybe... If I'm lucky and can craft a dedicated enough user base, they'll either donate on a regular enough basis, or they'll subscribe to the service I'll make as a side hustle. That would help get me through nursing school a bunch.

Over and out xo

Thinkymeat

(they/she)

I share my thinkymeat's thoughts here 🧠 .
Just a late 20s transfemme with a passion for academia, science, politics and coding.