Maintenance and evolution of legacy systems is a popular challenge in software engineering. Every time we produce a line of code, and it reaches production, we’re already creating legacy for our future selves or somebody else to look after. If not properly maintained, most systems won’t age well, and therefore most of us will eventually at some point in our careers face a rusty old behemoth that’s important to the business and simply cannot be shut down. Circumstances are different in every company but there are some common milestones and pitfalls during the recovery or replacement of an old system. In this article we'll go through some situations and try to understand the reasons that motivate them, as well as their potential solutions.
Technology and automation are tapping into every possible industry and the demand for software engineers has never been higher. Building successful companies gets harder every time because of all the competition creating new challenges everywhere, and as more people try to get themselves a good slice of the giant IT pizza, the need for differentiation between engineers becomes crucial to get a taste of that pepperoni.
Roughly 3 years have passed since I became a lead software engineer (or tech lead) and it's been an exciting run with many achievements and pitfalls. In this article, I try to synthesise the most important lessons I've learned so far on my journey, hoping that they can be useful to other leads who are trying to develop their craft. Having headed a couple of teams until now, I still have a lot to learn, but I certainly do approach things in a different way than I did some years ago, and the results present themselves in the most unexpected ways. There’s no secret formula for leadership, It's a learning process pretty much like working with a new language or framework. I started off by reading some blogs and books, but the greatest lessons actually came from trial and error, and constructive feedback from others.