Value of Small Steps
Hey!
Welcome back to another week of musings. I hope you had a restorative time!
I tried catching the northern lights during the weekend, but the fog didn't let me take pictures of them! At least we were out watching the Golden Gate Bridge illuminated.
Was this forwarded to you? You can subscribe here!
As I was recently working on a service, I reflected on the journey to get there. It wasn't a single leap but a series of small steps over time. This realization struck me when I saw other teams starting to use the service, a testament to the value of breaking down large tasks into smaller ones.
“Success is the sum of small efforts, repeated day in and day out.“ --Robert Collier
Divide and conquer
When starting with programming, we are taught the value of dividing and conquering problems to make them more manageable.
This applies to the small feature requests we receive daily and too big projects that would take months, quarters, or even years! More minor problems are more accessible to solve and help ensure we know what problem we're solving.
Sanity Checking
One other value of splitting a large problem into smaller problems is that we can double-check every step of the way. It's less risky to deliver and verify a smaller problem.
Sometimes when you have a "hunch", or you're trying to do a project for the future/long-term, it's better not to disappear and come back a few months later with the solution, but rather test each of the smaller problems with your expected customers.
Incremental teaching
One benefit I've had with the project described in the beginning is that I've been incrementally teaching the teams about the features individually. I tried to avoid getting a large context into everyone's mind!
I've had this set of "MVPs"s for each delivery, so the first release was usable in isolation. Afterward, you either want to use a new feature alone or with the prior one released. This has allowed people to either build the knowledge or, if they have it, increment it naturally with another feature they need.
Involving others
One thing that helps when breaking down into smaller problems (and documenting them) is that you can also involve others!
I've had a few times when people wanted to contribute to the project after using the current version. I always find what people come up with when they encounter your creation interesting. Sometimes, you release stuff into the world without knowing what the world will do with it.
If you documented the milestones, it would be easier to share and for them to extend the project or see where you want to take it. They can further add their milestones or ideas! It is a good way to get more people involved in a project.
Context Switching
Given the nature of my role, I need to switch contexts constantly during the day and week.
Having the smaller problems documented makes it easier to have my "maker's time" to take a small project and add a new feature, fix a bug, etc. One thing to call out is that it's not only code that contributes to a project's success; you also need to teach others how to use it, document it, or even record a screencast.
Having a small problem you can pick up quickly and solve a few hours later helps when going in and out of that mental headspace.
Your turn!
Let me know how you handle working in small steps. Do you have any interesting examples? Let me know by replying to this email!
Happy coding!
Things I discovered in the past week
- Hacking our way to better team meetings, a post by Dr Werners Vogels (CTO of Amazon) about improving meeting notes and note-taking.
- Sociotechnical Maestros with Gene Kim a podcast episode between John Cutler and Gene Kim. A great conversation around sociotechnical systems, "devops", among others!
website | twitter | github | linkedin | mastodon | among others