Hey there 👋 I'm building CodeTrail, which helps engineering teams document and share knowledge close to the codebase with no friction. If you're still using Notion, Confluence or Google Docs to document your engineering work, give it a try and let me know what you think!
Most software companies don’t ever get to see a steady state, where the core product has been built, the rate of innovation decreases, and maintenance and minor improvements become the primary workload. In this world, priorities shift from figuring out the product, to ensuring customers are happy and keeping the lights on.
Recently, I came across a tweet that alluded to big tech companies constantly rewriting their systems (think mobile and web applications), as a means of job creation or lack of meaningful work. Good jokes always have an element of truth though, so let’s think about that for a bit.
Usually, a system evolves over time to handle more use cases and bigger workloads, and serve a more global audience in the case of social networks. Over the same period of time, teams are created, reshaped, terminated, and shuffled. The organization on day one is completely different from the organization on day 365 which again is completely different from the organization in years 2, 5, 10, and so on.
Over that time, engineering management has to continue building the product, helping the company to enter new markets, keep bigger customers satisfied by providing reliable services, and fixing issues along the way.
What we don’t think of, however, is that companies must remain attractive to new hires. Chances are, that your initial team has mostly departed after 3 to 5 years. Some people may still work at the company, in managing roles or positions created just for them, but the majority of engineers will be new. This cycle repeats continuously, so 50% of the company may have joined in the past 12 months, every year (which is the case when the company is growing steadily, in a downturn hiring slows or freezes altogether).
In the end, the stack should fit the objectives brought in to serve customers (performance, reliability) but also to retain and attract people (technology used in other companies, tools that help you advance in your career, etc.). If we think about our chosen tools from this angle, continuously improving and rebuilding services using tools and languages that are the best fit then starts to make sense.
On the flip side, there will be people in your organization who oppose change, and sometimes, without objective reasons. It’s good to discuss this on non-emotional grounds, making sure everyone understands why keeping or changing tools in an organization is necessary to remain attractive or increase team performance.
Building Anzu, I chose a similar stack, using Node.js and TypeScript to move fast, and building parts of the backend using Go for reliability reasons. For the frontend, we chose to use React and TypeScript because of the sheer size of the ecosystem and my experience using React. My co-founder Tim had mostly used Angular up to that point, so using a different stack required a higher effort on his end, but the advantages React would offer us down the road (as well as allowing both of us to work together easily) convinced us to make this decision and I have a huge deal of respect for Tim to make this compromise for the sake of velocity.
Of course, changing the stack should not be an end in itself, but rather a planned activity that is strategically executed. That way, it’s closer to reducing technical debt (or building technical wealth, whichever way you prefer to call it).
So to conclude, if your interns are choosing a new framework just because they have nothing else to do, set them up with better tasks, but stop and think about why they choose their tools. Maybe you’ll learn something new along the way, which could help you with hiring and retention.