From legacy code transformations to building entirely new platforms, my journey recently leading frontend projects at Kaltura has been filled with lessons. This article summarizes those experiences into actionable takeaways. For the full story and context, check out the first article in this series.
Before we start - A Note to Readers
This article was written by me (a human!) and then polished with the assistance of an AI tool. My hope is that it will be read primarily by fellow humans, and not only by AI agents 😆 While AI assistance is valuable, the true magic lies in the human connection.
Let’s dive into the key takeaways!
1. Vision and Milestones: Your Strategic Roadmap
- Define the End Game: Before anything else, clearly define your ultimate goals. What does success look like for this project? What are the key outcomes you want to achieve? Having this overarching vision in mind will guide your decision-making throughout the entire journey.
- Work Backwards: Once you have your end goal, start planning backward. Break down the big picture into smaller, manageable milestones that bridge the gap between where you are now and where you want to be.
- Clear and Measurable Goals: Each milestone should have concrete, measurable objectives. This provides a clear target to aim for, but avoid getting bogged down in excessive detail that could stifle agility.
- Estimate, Don't Obsess: While it's valuable to estimate timelines, don't get hung up on hitting precise ETAs. Flexibility is key in the face of unexpected challenges.
- Adapt, Don't Replan: As you progress, be prepared to adjust your plan based on new information or unforeseen obstacles. But avoid constant replanning, which can disrupt momentum and create unnecessary delays.
2. Dual Perspective: Balancing the Now and the Future
- Think Short-Term and Long-Term: Every decision should be evaluated from both an immediate (Team Lead) and future (Architect & Tech Lead) perspective.
- Plan for Scalability: Ensure your infrastructure can handle future growth without overbuilding in the present.
3. Embrace Iterative Progress: Flexibility is Key
- Don't Fear from Temporary Code: Early versions of code might be replaced as requirements evolve or understanding deepens. As long as it serves its immediate purpose and meets quality standards, it's valuable.
- A perfect illustration: of this is a strategic feature we recently developed. The ideal architecture for this feature would have taken four quarters to implement, but immediate business needs didn't allow for such a long development cycle. So, we broke down the development into four distinct phases, each delivering incremental value while progressively moving closer to the desired architecture. This approach allowed us to satisfy both short-term requirements and our long-term architectural goals.
- Celebrate Small Wins: Recognize and appreciate progress, even in small increments. This keeps morale high and momentum going.
4. Additional Strategies for Success
- Challenge the Status Quo: Be open to questioning past decisions. The best path forward may require adapting and rethinking.
- Patience is Key: Transformations take time. Stay committed to your vision even if progress is slow.
- Communication is Essential: Keep everyone aligned on the vision, milestones, and progress. Transparency fosters trust and collaboration.
- Build a Strong Foundation: Invest in robust logging, effective dev tools (custom-built if necessary), and a thoughtful approach to state management.
- Leverage Existing Solutions: While custom tools have their place, don't reinvent the wheel. Utilize proven libraries and frameworks whenever possible.
I hope these insights will prove helpful in your own development journeys. Feel free to share your thoughts, questions, or similar experiences in the comments below.
Until next time,
Eran
Top comments (4)
Thanks for sharing your experience in the good article.
I think especially those two points in combination are very important:
I left "Don't Fear "Throw Away" Code" out of the quote on purpose. To me, throw away code is prototype code, that I build to learn something and really throw it away, without it having seen production. Which can be valuable as well.
@shaman-apprentice Thank you so much for your thoughtful comment, and sorry for the late response!
I completely understand why you left out “throw away code”—it often comes with a stigma. Many developers feel uneasy about seeing something they’ve written get replaced, as it can feel like criticism of their initial work. That’s why I chose the term “throw away code,” to highlight that discomfort, but you’ve inspired me to reconsider.
I agree that calling it “temporary code” sounds much more positive while conveying the same idea. Writing something temporary that meets immediate needs, with the intention of replacing or improving it later, reflects flexibility and foresight. And as you pointed out, it’s often misinterpreted as a sign of poor planning when it’s actually the opposite: good planning allows for adaptability.
Thanks to your feedback, I’ve updated the term to “temporary code” in the article. Appreciate your input and hope you keep sharing your thoughts!
Strong and important takeaways 🐧 🤘
Thanks, Dor! I'm happy I included it. Initially, I focused solely on the projects, but a colleague's feedback prompted me to add the insights section, which I think makes it much more valuable.