Recently I was working on a fun idea, that was going to take me longer than one week to complete. Towards the second week I found myself dreading going back to work on my “fun” project. I wasn’t sure why… Was I no longer excited about the idea? Was I just too tired? Was I getting sick? Was it something else?
I decided to force myself to work on it anyway and when I opened up my text editor I knew the problem right away. My code was garbage. It was a hack on top of hack, to get thing done quickly. While it felt fine when I wrote it, it was NOT fun coming back to it at all. It seems like my subconscious mind was just trying to protect my wellbeing.
I decided to factor out my code first, before moving forward. I did not do anything fancy, like 100% unit test coverage or a continues integration pipeline. I did, however, broke my code up into different modules, making it easy to read and understand. Before I knew it, the “fun” project was fun again.
Looking back it seems obvious, but it was not so obvious to me at the moment. I’ve seen the same writing-things-fast approach used at a much large scale in my previous jobs. It’s easy to justify writing (bad) code “faster” just to get things “done”, by calling it an MVP and promising to fix things later. That speed, however, comes with a big price, and kills developer productivity, even at MVP level.
I wish more Engineering and Product Mangers would keep that in mind, when prioritizing new features over tech debt.
Please Share:
You’re describing maintainability issues more than motivational issues. You can have perfectly beautiful source code that is easy to maintain, but ultimately drains you emotionally to work on it. An example would be a person who hates math trying to program a calculator, but thinks if the source code is kept neat and clean he can ignore his dislike of the project. The key to successfully creating a project that you can return to later is fundamentally understanding what “drives” you as a person. That itself is a huge challenge. Sit down with a paper and pen and start writing keywords about things you’re into. Keep writing down words that describe you as a person, you’re technical interests, you’re creative interests, what kind of people you like to spend time with, what kind of environments make you happy. The more of a project you work on that encapsulates those key things about yourself. The more you’ll find that the source code magically stays neat and clean, is well organized and thought provoking. The more rewarding it will be to work on. We don’t have this luxury at our day jobs so we often bring the misery of day jobs to our personal projects, and then ask why we’re unhappy working on them. It’s crazy I know, but the best programming projects are the ones that focus on what we’re passionate about.
+1. You might have just pointed out the golden measure of how much time one should take from feature development and invest it into eliminating technical debt. The minimal amount of time which is necessary to keep it fun!