On my most productive weeks as an individual contributor, I was making between 15 and 30 changes. Most of them were small iterative changes towards whatever the product backlog would define. However, I would always squeeze in 1, 2 or more small improvements that made the project healthier, made my team or myself happier working with it, or solved a problem for someone else. Not long ago, my colleague asked how I manage to find time for that. My reply was that I simply used fifteen minute breaks and looked for something with a low context switching threshold, and usually had some minor ideas on what to fix. But that is not the full story and upon a deeper reflection, I distilled it. This post is the actual framework for continuous improvement of code that I use.

Make A Note

Next to my keyboard I always have a notebook and on the sidelines of the page I continuously make one or two word notes of the minor annoyances I encounter, in very few words. Sometimes as little as one or two, examples that I remember - “dependency management”, “exception formatting”, “excessive alerts”. Minor does not represent the scope of the problem, just means that I encountered it and overcame it at the time. It is something that would fall as an answer under “where do you spend the time that you think you should not be?” or “what things you find hard, that you think should be easy?” during a retro. Listening to the team can also show areas of these minor annoyances.

Key thing is that writing those two words down is never a commitment to fix it. The purpose of making that vague note is twofold:

1. Remember. Writing the issue down helps me not to proverbially boil my performance, by getting used to something annoying and time wasting.
2. Prioritize. I can add marks to this written note, if something happened more than once, was mentioned by more than one person, or has a broader company-wide impact.

Since there is no pressure to fix the problem it means that if I write something vague, and cannot remember what it was about - it was not important. At the same time, if the original issue does resurface - some or all of the vagueness will reconnect due to the contextual memory.

Make It Visible

If the problem persists - write it down to the backlog, bring it up during tech debt discussions and retrospectives - make it visible, and hear the feedback. Three things may happen that are quite serendipitous.

1. Someone will say it’s not an issue and will propose an alternative. Problem solved.
2. Someone will say it is an issue and give more details. It will reaffirm your prioritization is aligned with the team’s understanding, as well as provide additional information.
3. Someone will propose an idea on how to solve it. It might be better than whatever you have thought.

On one occasion, a project I was working on relied on AWS Lambdas and occasionally we would get initialization failures in production, while continuos integration tests would pass. The test environment was importing all the dependencies slightly differently than the real AWS Lambda environment. The problem happened not very often, once every few months, but when it would happen it was a full, not partial, outage. I have documented the problem into a tech debt task, but all the solutions seemed disproportionately large in scope and did not justify the time. Until one day someone said, “Hey, have you heard of python-lambda package?” Fifteen minutes later we had a simple test case that covered this regression and it did not repeat.

Start Small

If it is not clear how to fix the problem or it would take a long time to debug it, and it is not a product priority, it may be hard to get an endorsement to work on it. However, it may be better to, instead, ask the question: “what would make this easier to do, with little effort now?” Some examples of simplifications I used:

1. Additional logging. If it is an evasive bug, instead of spending 5h debugging it, it may be easier to add logging, and work on something else for 5h, then come back and investigate the data.
2. Additional research. If a problem is more process or third-party service driven, I would spend a 15min break looking for and reading a blog post or documentation about it.
3. Additional visualization. If the relationships between systems (especially new ones) cause a brain freeze - a good diagram always helped me.

If the solution did not surface, usually the next step was still clearer. In either case, I would also document my findings, increasing the chances of serendipitous insight.

Make It Part Of The Flow

Doing this regularly can help break the monotony of a boring task. Personally, after I submit something for code review, if I want a break - I reward myself with fifteen minutes of looking at the notebook, backlog, or open branches, for small improvements I can make a step towards. Since there is no pressure to solve anything right there and then, even if nothing happens, I switch back to work mode. Integrating these short breaks into the daily workflow accumulates a few work-in-progress improvement branches, eventually leading to one or more small improvements over per week.