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: