4 more lessons from a senior engineer that you need to learn

Many articles aim to define what a senior engineer is and how to become one. That is not this article. The motive of this article is simply a reflection for couple lessons I have relearnt over and over again in my software engineering career as I have matured and become more senior. This article will not be the secret recipe for becoming senior because other resources online cover that topic but instead focuses on one lesson that has personally stood out to me that many engineers still need to learn. 1. Engineering is almost never binary That is, the 'correct' way of engineering something may be the 'wrong' way of designing the same thing given different circumstances. To not set yourself up for embarassment, before you judge the 'correctness' of a design especially when you are early in your career you should question, even though I think this could be 'better' (in my opinion) from x design principle I learnt at university or insert-some-other-trending-technology, ask yourself this question: 'why would some senior engineer design it this way?' Before you start saying 'x is wrong and y is how we can fix it.' reconsider why it would be engineered this way. Even better, read any design docs or ask the original developers if you can. In my career so far I have found that more often than not I am incorrect in my initial naive reaction of 'x is bad, and if we simply apply y it will fix it'. I am an advocate to give the original engineers the benefit of the doubt. Although be wary of the other side too, although I am advocating to give existing solutions the benefit of the doubt, they could still be objectively 'bad' but be open to more context. One example to be wary of is previous engineers personal agendas or learning interests for specific technologies at the time. If x engineer just wanted to learn about WASM so they wrote the startups entire frontend with it. This wasn't necessarilly a good decision for the business but again just understanding even this agenda can still help influence and improve future decisions. A particular context factor to remember is: 2. Consider the 'maturity' of the product The maturity of the product; was/does it currently make money? was/does it have users? was/is it profitable? was/does it have 100 000 Daily-active-users (DAU) or 100 DAU. These factors all significantly influence the engineering decisions in the product. These external factors could be anything surrounding the product and should be an important reminder to engineers of why they do need to care about having an understanding of the business and product. 3. Learn the product and business As software engineers, the bottom line is that we are meant to be deliverying value to the business. This is important to remember and connect the dots to revenue. But more than just connecting to revenue, learning the current business context is most important for making correct engineering decisions for the business right now and for the future. It is also imprortant to remember that these context factors change over time. This means, an engineering solution that was quick and dirty 2 years ago when the project's goal was to get it's first 100 users and may be proving to be an extreme heartache for engineering now that the product has 100 000 DAU is a perfectly normal and justifiable experience. This is a common phenomena that all engineering teams around the world will experience. The poor engineering decisions of our past becomes what we call technical debt. Understanding at a high level the previous stages and growth of the business and product allows engineers to understand and appreciate the context of where products have come from but more importantly the why behind the engineering decisions and the why behind technical debt. You don't need to know everything but learning the fundamentals and a brief history of the product from a business stand point will do you wonders. 4. Technical debt is normal Startups may not have automated testing or an automated deployment pipeline or any proper design system or whatever the next 'best practice' is to introduce. As previously mentioned, it's never black and white, some things are good in some cases but it depends on the circumstance. Just because you learn some new perfect design pattern, doesn't mean it will be the perfect solution for all situations. Naive engineers have a tendency to learn something and think this will now work for everything, but in engineering it's always compromise of weighing up pros and cons. A warning to check your ego This will depend on company to company and team to team, but at some point in your career you will join a certain project and be blown away by the tech debt. Seemingly senior engineers working on huge successful corporations or unicorn startups will have mountains of tech debt and spaghetti code. You may even naively think to yourself despite your lack of experience: "woah, I

Apr 6, 2025 - 11:58

4 more lessons from a senior engineer that you need to learn

Many articles aim to define what a senior engineer is and how to become one. That is not this article. The motive of this article is simply a reflection for couple lessons I have relearnt over and over again in my software engineering career as I have matured and become more senior. This article will not be the secret recipe for becoming senior because other resources online cover that topic but instead focuses on one lesson that has personally stood out to me that many engineers still need to learn.

1. Engineering is almost never binary

That is, the 'correct' way of engineering something may be the 'wrong' way of designing the same thing given different circumstances. To not set yourself up for embarassment, before you judge the 'correctness' of a design especially when you are early in your career you should question, even though I think this could be 'better' (in my opinion) from x design principle I learnt at university or insert-some-other-trending-technology, ask yourself this question: 'why would some senior engineer design it this way?'

Before you start saying 'x is wrong and y is how we can fix it.' reconsider why it would be engineered this way.
Even better, read any design docs or ask the original developers if you can. In my career so far I have found that more often than not I am incorrect in my initial naive reaction of 'x is bad, and if we simply apply y it will fix it'. I am an advocate to give the original engineers the benefit of the doubt.

Although be wary of the other side too, although I am advocating to give existing solutions the benefit of the doubt, they could still be objectively 'bad' but be open to more context. One example to be wary of is previous engineers personal agendas or learning interests for specific technologies at the time. If x engineer just wanted to learn about WASM so they wrote the startups entire frontend with it. This wasn't necessarilly a good decision for the business but again just understanding even this agenda can still help influence and improve future decisions.

A particular context factor to remember is:

2. Consider the 'maturity' of the product

The maturity of the product; was/does it currently make money? was/does it have users? was/is it profitable? was/does it have 100 000 Daily-active-users (DAU) or 100 DAU. These factors all significantly influence the engineering decisions in the product. These external factors could be anything surrounding the product and should be an important reminder to engineers of why they do need to care about having an understanding of the business and product.

3. Learn the product and business

As software engineers, the bottom line is that we are meant to be deliverying value to the business. This is important to remember and connect the dots to revenue. But more than just connecting to revenue, learning the current business context is most important for making correct engineering decisions for the business right now and for the future. It is also imprortant to remember that these context factors change over time.

This means, an engineering solution that was quick and dirty 2 years ago when the project's goal was to get it's first 100 users and may be proving to be an extreme heartache for engineering now that the product has 100 000 DAU is a perfectly normal and justifiable experience. This is a common phenomena that all engineering teams around the world will experience. The poor engineering decisions of our past becomes what we call technical debt.

Understanding at a high level the previous stages and growth of the business and product allows engineers to understand and appreciate the context of where products have come from but more importantly the why behind the engineering decisions and the why behind technical debt. You don't need to know everything but learning the fundamentals and a brief history of the product from a business stand point will do you wonders.

4. Technical debt is normal

Startups may not have automated testing or an automated deployment pipeline or any proper design system or whatever the next 'best practice' is to introduce. As previously mentioned, it's never black and white, some things are good in some cases but it depends on the circumstance. Just because you learn some new perfect design pattern, doesn't mean it will be the perfect solution for all situations. Naive engineers have a tendency to learn something and think this will now work for everything, but in engineering it's always compromise of weighing up pros and cons.

A warning to check your ego

This will depend on company to company and team to team, but at some point in your career you will join a certain project and be blown away by the tech debt. Seemingly senior engineers working on huge successful corporations or unicorn startups will have mountains of tech debt and spaghetti code. You may even naively think to yourself despite your lack of experience: "woah, I could do better than this?!", "How did they get away with this?" etc. etc. the thoughts continue. But I write this as a warning.

It's generally naive to criticise the tech debt as soon as you see it. It may be justifiable to the business and you can't blame the engineer for poor engineering. Context changes, just because the design is obviously innapropriate now doesn't mean it was not the seemingly best solution when it was first introduced.

On the flip side of understanding the current state of a project. You have to also be mindful of the new decisions you introduce. Just because you learnt about microservices architecture and how scalable it is at university, do we need to implement this for our new early stage startup that has no users yet? Definitely not. This is over optimising and over engineering. So we start with a monolith. 5 years later another straigh-out-of-uni graduate joins, sees all the issues they are having scaling the monolith and thinks out loud: 'the engineers that designed this were so naive. They should've built it with microservices from the start' but this would be added complexity and overheads for the startup stage and could've killed the company before it made any money. The company at the early stage just needed simplicity so they could focus on tangible features for the customers.

I recently attended the 'Programmable' conference in Sydney, Australia where a distinguished tech leader (and current CTO) did a fantastic talk on addressing technical debt ('Legacy code'). His talk again reminded me of how engineering decisions are never black and white and that technical debt is normal. One particular quote stood out to me:

If you don't have bad legacy, you have over engineered
Jeremy Burton

This line elegantly captures majority of this article.

TLDR; in summary

Tech debt is healthy and normal. Too much will lead to an unsustainable product but too little is a sign of over engineering and could kill the company. 'Good' engineering decisions are never binary. The maturity and context of the product has significant influence on what 'good' engineering looks like at that time. The product context changes over time so the engineering also has to evolve. This should be considered when looking at existing projects or working on new features to get the most appropriate outcome for the business.

Thanks for reading!

Hey, I am Sean Overton, a passionate software engineer and technical writer who strives on deliverying real user value in products.

Please share with any colleagues that are interested in becoming more well-rounded engineers.