M. Treaster
2024-03-08
There are many paths to growing as a software engineer, and there are many paths to building high-quality software. While there are pros and cons to each path, I've personally found the most success through long-term ownership of software projects.
Any sort of learning requires a try-fail cycle. Try something, observe the outcome, then if necessary try a different approach. But in software, this cycle is typically measured in years! That refactor, will it end up having the benefits you imagined? Your plan to optimize for scalability, will it be time well-spent? It takes time to see the outcomes. The system load had an access pattern you didn't anticipate, or the optimizations made it difficult to add those new surprise business features. Looking back, were your earlier decisions still the best? Or do you wish you had made a different choice?
When you stay with a project long-term, you have the unique opportunity to see this cycle through end-to-end. Form a plan, try it, see how it turns out, and then form a new plan. You develop the ability to look around corners, to predict outcomes, and to ground your decisions in concrete experience and consequences.
On the other hand, when you flit from project to project, dabbling here and there, you don't have the opportunity to closely observe the outcome of your decisions, and you don't have the opportunity to revisit those decisions and try to improve upon them.
Additionally, remaining on a project provides deep understanding of how the system works, why it works the way it does, how new features should be best incorporated into the existing architecture, and what mistakes have been made before. Under the steady hand of long-term ownership, the system is more likely to be clean, elegant, and coherent.
But by transitioning to new projects frequently, you'll be lack that deep understanding. You'll lose a lot of time to learning the mere basics of the system rather than honing your engineering skills, and during that learning time you'll disrupt any existing thoughtful plan by forcing it in directions it was not intended, perhaps repeating mistakes of the past. The system is likely to become chaotic, cluttered, and brittle.
Long-term ownership can also lead to a broader software engineering experience, as you're more likely to be responsible for the full lifecycle of your system: Requirements-gathering, scoping, design, implementation, debugging, documentation, user training, operating/oncall, long-term maintenance... If you frequently start projects then leave once they're off the ground, or hop from one mature project to another, you'll likely miss some of these phases.
Finally, long-term ownership can lead to accountability, and confidence in being accountable. What's your process for making decisions? How do you prioritize? Are you comfortable with decisions, or do you get someone else to decide for you? How do you react when things go wrong? If you're the old-timer on the team, these responsibilities will likely fall to you. If you hop to new projects, there may be a more veteran member on the new team, and it may be more natural to defer to them.
In summary, long-term ownership of projects leads to better software, better engineering skills, and better personal skills. "But!", you say, "won't I also learn a lot by moving to a new project and seeing how things are done over there?" Quite right! There are many paths to growing as a software engineer, and many paths to building high-quality software. Certainly I've learned a lot by switching teams and encountering new approaches. But, my opportunity to own projects long-term have been the foundation on which the rest of my learning has been laid.
Do you own any software projects, of any size? What decisions have you made, and what was the outcome? Do you even know the outcome yet? What would you do differently next time, given the opportunity?