Part 1 of the Life to Software series.
Dictated using Wispr, edited by a human.

Taking small steps can make a huge impact. In this post, we’ll discuss how taking five to ten minutes a day can hone your discipline and enable you to make better software.

Life

Let’s start with a real-life scenario.

After dropping my kid off at school, I pulled into the driveway, where weeds tend to form in the cracks over time. After months of neglect, the weeds take root, and all of a sudden, what is normally a small and enjoyable job to maintain becomes something painful.

I enjoy maintaining things, but similar to the broken windows theory, neglect creates unnecessary negativity. Then one day I parked up, saw the weeds and thought, “Why don’t I just clear them now?” and after some consideration, I came up with a plan.

By splitting the driveway into seven sections, I can spend 5 minutes per day maintaining the driveway. I don’t even need to do it regularly, as every other month would suffice.

I have to tell you, this process is an absolute dream. Five minutes is nothing. I normally park up, go into the house, and stare at my phone. And now, I spend five minutes maintaining something I’m proud of. Another positive is that the neighbours enjoy seeing me do it as well 😉

Software

How does this relate to software?

When building software, we’re often confronted with trade-offs, and sometimes we reflect on these to align their outcome with a larger goal. Sometimes, we don’t reflect and move on to the next task, building up a list of unfinished thoughts.

This isn’t always a bad thing. We have to crack on and get work done, right? But often I’ve noticed that leaving things neglected can build up like the weeds in my driveway.

In my career, I’ve remained effective, for the most part, by taking small steps. With the discipline to maintain consistency, you can achieve a great deal in small intervals.

Next time you’re feeling negative about some work that doesn’t get done, ask yourself:

If you have 5-10 (or even 15) minutes of focus a day, what would you do to progress the task that you believe never gets actioned?

Even before tools like Claude Code or Cursor, I used to progress code migrations, fix flaky tests, improve documentation and iterate on process improvements all within this short window.

It’s all about discipline, consistency, and the ability to break down larger tasks.

Break it down 🤘🏻

Here’s a recommended approach.

1. Find an initiative/task that you’re passionate about (it helps if you care). Ideally, this can be aligned with a measurable outcome.
2. Block out a short amount of time each day, I recommend to add this “focus” time in your calendar. I find straight after lunch works best.
3. If required, do a little planning. Create sub tasks during the first time block. Don’t over plan.
4. When you’re ready, do the work and keep going until the larger task is complete.
5. Communicate your efforts in whatever fashion suits your team. I find that having a weekly (or bi-weekly) get together for demos is best. If you don’t want a meeting…do this asynchronously (video recording, email, instant message etc).

Culture matters.

Taking small steps can help build a positive culture.

Building pride in your team takes time and requires leaders to set a good example. I’m not talking about management or a senior engineer within your team. I’ve seen “juniors” show exceptional leadership ability in a topic that they’re passionate about.

Taking small steps to manage those weeds in your software will empower your people. Improving ownership and autonomy, which is a key trait for successful teams.

And it’s really not difficult to find the time. Yet I see many instances where people have a passion for a topic, and don’t take any steps because they don’t realise their capability.

I find that working in this way improves my ability to deliver continuously. If you only have a short while to progress a task, you need to consider many aspects for delivery, such as:

• Can my small change be deployed safely? Can you even monitor that part of the system?
• Was my change too large for review? (if it is, it probably needs to be broken down more, which in itself is a great skill to practice)
• Did I prepare adequately? In an unfamiliar system, this can be simply gathering information about where the implementation lives that you need to change. Or even identifying documentation improvements and then actioning them before approaching your task.

Conclusion

This process does work. Just this week, I’ve used this process:

1. I documented the logs in a noisy test runner which was causing debugging frustrations in our CI/CD pipeline.
2. Once documented and a success criteria was defined.
3. I then created the subtasks in our project management tool (the team get notifications in Slack about certain updates so it’s good for them to see).
4. I then went on and completed the task. Everyone can debug so much faster now, and it’s improved our ability to deliver good software within the team (even if it’s just a little).
5. After completion I shared an update noting the original goal and many people expressed their appreciation for the level of care that I demonstrated 🥳

Obviously, this process won’t work for all tasks, such as large rewrites or redesigns that need more dedicated time, but I think you’ll be surprised at how much you can achieve in this short window if you are disciplined enough.

If you do use this process and you succeed or fail with it, let me know, and for now, take care 👋