#51 - Succeed by Taking One Step at a Time
How I almost lost an entire project by working in large batches, and lessons learned
Introduction
There is a famous Israeli movie that has the quote: “Start as fast as you can, and gradually pick up the pace.” I want to tell a story about how the exact opposite happened to me and what I learned.
My side project experience
I worked on an interesting side project in Python. For the first day or two, I started with small PRs and small commits—one or two files at a time—always making sure the functionality was there and the code was tested. However, at some point, I needed to revamp everything to reach a viable version, my V1.
To do that, I needed more functionality, modules, and an improved project structure, and every step I took broke something else. If I changed the structure, the tests failed. If I improved the tests, I found issues in the source code. This back-and-forth went on for two or three days, touching around 15 files that completely changed the project’s structure. Moreover, all the changes were only in my local history—in my local branch, not in the remote one. I didn’t push the code at all.
Finally, when I reached a working state, I tried pushing my code, but I had a small violation around a file that should have been added to .gitignore. Unfortunately, it was already committed to my local branch. For those who don’t swim in the technical details, this practically means I couldn’t sync what I had on my computer with what I wanted in my GitHub repository.
I wasn’t sure how to fix that, and while experimenting with changes, I ended up reverting all the work done in all the files since the last push to the remote branch. Yes—two or three days of work were practically lost.
After a few conversations with Chat GPT and pulling my hair out (not that I have much), I found a Stack Overflow post in the nick of time. It explained a somewhat cumbersome but achievable way to restore everything from my local history in VS Code. Long story short, my project is now up and running, and I managed to overcome this huge risk of losing everything I did.
Lessons learned
I believe the main lesson here is about the Big Bang approach. Even though I started small—and recalling the phrase about running as fast as you can—I tried to build the best version that worked, but it came with a huge risk. I don’t think this applies only to code or projects in general; I can think of several areas it might affect.
Working in iterations, providing small changes, and keeping short feedback loops can benefit many situations. This experience strengthened that belief for me.
Practical example
Feature release
As product managers, we discuss features and their scope a lot. We always try to balance bringing some value to the customer with making a version that’s relatively easier to build and release. However, we don’t always consider the milestones along the way, even if they don’t reach the user.
For example, imagine a feature around creating a new marketplace for applications in a B2B SaaS product. The final release might include a marketplace page with lists of apps, integrations, and some install mechanism. Maybe that’s the minimum viable version for customers. But to avoid a Big Bang, show progress, mitigate risk, and boost morale, you need milestones that have significant impact—even if they’re internal.
Maybe the first milestone is showing how a single integration installs (available only to internal employees). Then the next milestone might be showing the marketplace page with just one integration. It could take another month to add the ten integrations you ultimately need, but everyone can see incremental progress, give feedback, and stay engaged throughout.
Projects
Sometimes we have large projects at work that involve different departments and have ambitious goals. We must work backward with first principles in mind, identifying the next checkpoint and ensuring each milestone is acceptable. One example is a company restructuring its organization. One option is for leadership to go off-site, figure everything out, and announce it in one Big Bang. In certain cases, that makes sense.
However, in most cases, you want to onboard employees, gather feedback, and engage everyone. The way to do that is by short feedback loops and small iterations. Perhaps you start by sharing the goals and current pains. Then you gather feedback on that. Next, you show the plan for achieving the new structure—what meetings you’ll have, what decisions need to be made. By the time you finalize the structure, employees feel more connected and informed.
Personal skills
It’s easy to say, “I’m going to learn a new language,” or “I want to code.” When the end goal is far away, it’s hard to stay engaged and motivated. Thinking back to my project experience and almost losing my code, imagine learning a new language: the first milestone might be counting from one to twenty and sharing it with someone (like syncing to a remote branch). Then maybe you learn how to order a coffee in that language and actually do it at a coffee shop. Keeping these small milestones and feedback loops ensures you spot errors—like a wrong accent or approach—early on, not at the very end.
Closing thoughts
While all of these examples sound obvious, I personally failed to follow them in my project, and I’ll likely slip up in my professional life too. Still, this has been an important lesson for me, and I hope it helps others.
Coming back to the famous Israeli movie, I want to claim that the way to succeed is by consistently taking one step at a time.