Many Small Steps Make Pivoting Easier

I’ve been concurrently working on two significant feature releases as well as bug fixes across three repositories. Most of what I’ve done has been refactoring code to make introducing the features easy. This work is behind feature flags or converting hard-coded assumptions into more dynamic structures, that mimic the hard-coded assumptions.

These strategies have made it easy to jump between features and bug fixes, depending on priorities, needs for additional information, and verification; the usual distributed team’s challenges.

Some of the refactoring has been taking one “noop” step, having it reviewed as functionally equivalent, then taking another step that then introduces the feature (behind a flag) but by default doesn’t change the current state. From there I take a few more steps. Each one building a tiny unit of code to review; ones that are easy to digest what is going on.

Along the way, I’ve found prior logic bugs, cases in which I could improve error logging (e.g. there’s a notable and significant configuration drift from expectations).

To help track, I create tickets which a commit works towards and eventually another commit closes. I establish blockers (e.g. don’t execute a test plan for the feature until I’ve revisited the entirety) and share my work so others know where things are at.

It may seem slow, but given that I’m on a small team in which my questions and code changes are amidst a myriad of other conversations and realities, this approach feels appropriate and sustainable.

This month I’ve thusfar had 39 Pull Requests (PRs 📖) reviewed and merged, with almost no rework on a submitted PR . The same has been true for December, in which I had 34 PRs (it was a short-month for me). November, 51 PRs . And October 84 PRs .

These PRs reflect looking to the code, finding the crease in which I can introduce a small yet meaningful change, then documenting the case for the change. Also getting feedback and clarity from team members, who themselves are often working on other tasks.

As a result, I’ve almost entirely eliminated a pernicious set of hard-coded assumptions, making the it easy to next add another flavor of the feature. Further, I’ve improve my teams understanding of the underlying system, by engaging in the review process and including more inline and high-level documentation.