published on : Friday, April 26, 2024
Over the years, I’ve noticed that my software development happens in a bursty manner. It’s very rare that I sit down and write good, clean code that is of the same nature everyday. Sometimes, I do lots of little bug fixes and clean up. Other days, I write a “skeleton” of sorts - splitting responsibilities, refactoring existing code, etc.
I sometimes just look at the overall codebase and try to find how to become more productive while working within the codebase. I’ve listed a couple of the other “typical” software development day-to-day scenarios below:
I write very little or no code when a day has too many meetings, or when my time is split into chunks so I have no large blocks (2hrs+) of time on that day to sit down and code.
If the tools I’m using are getting in my way: Api is flaky, test pipeline is flaky, rollbacks are hard. Processes are not smooth for development (things like having a slow pipeline, build times etc), I literally won’t be able to concentrate on product development, so I try to fix the issues that are getting in my way of coding.
A few times, when I find it hard to concentrate on coding, I tend to write tests for existing code, and avoid writing new code.
What this means is that there are weeks where very little progress (with respect to product development) is made because a lot of time is spent maintaining existing things, and cleaning this up, so that the whole thing doesn’t collapse under it’s own weight.
And then, there are other times where once the cleanup and the foundational work is done, progress happens blazing fast - features get delivered in days, bug fixes happen overnight and all sorts of great things happen.
Since this happens all the time, it’s harder to estimate how quickly a given product requirement can be completed - You will get wildly different estimates based on the codebase you’re working on. It’s yet another thing that contributes to the difficulty of estimating development effort.