One hour a dayWorking this way is a skill. It takes practice. But I believe anyone can get there.
I maintain a small open source library. I’ve mentioned it before.
These days I primarily work on it in the evenings, after the kids are in bed, while my wife and I are watching TV. (A lot of Doctor Who lately!)
I’m in the process of finalizing some not insignificant API changes before the next major release. So there’s been a fair amount of code churn, and some of it is rather disruptive.
Even so, most evenings I’m able to merge at least one meaningful change. Sometimes more than one. And we aren’t watching that much TV. Usually just an hour. Occasionally two hours in a single evening, if the kids nod off early.
And it’s easy. It feels natural to me.
What’s my point?
If I can merge one or more meaningful, valuable changes to a library in less time than it takes the Doctor to find a new companion, why does it take hours, days, or even weeks sometimes, for so many developers to merge their changes into their projects?
I’m not here to point fingers or place blame. I just want to point out that virtually any feature, even large API changes in an open source library, can be done in small, meaningful, and self-contained steps. Working this way is a skill. It takes practice. But I believe anyone can get there.
If you’d like some help getting there, reach out! Let’s chat.
Reader response: The downward spiral of manual acceptance testing
Lack of unit testing drives the need for manual testing. Since testing is bunched up, development is as well.