This post lists the key insights from this article, by an engineering leader at Gusto, Sihui Huang.
When we first start our careers as software engineers, we tend to focus on improving our coding skills. This includes, but is not limited to, mastering a specific tech stack, adopting best practices, and studying architecture designs.
But there is another side that is just as important: gaining the domain knowledge and forming a long-term vision for your team, product, and company.
What it means to have domain knowledge and long-term vision
Essentially, having domain knowledge and long-term vision means understanding
- the status quo,
- the history behinds it, and
- the future you are moving towards.
1. Understanding the status quo
Understanding the status quo means having an overall understanding of the projects your team owns and maintains, technical debt your team carries, current limitations and fragile parts of the system, etc.
If you are dealing with a specific domain, it also means knowing the ins-and-outs of that domain. For example, if you are a payments engineer, you should be familiar with different payment routes and protocols. If you are building accounting software, you should know basic accounting concepts. This knowledge might have nothing to do with computer science or software engineering. But your job as a software engineer essentially is to translate this knowledge into code. The better you understand the domain, the easier it is to build elegant systems.
2. Understanding the history of the team
The history of the team and projects means why and how your team gets to this point. It includes the reasons certain responsibilities belong to your team, and the tradeoffs and reasonings behind architecture design decisions made in the past. It’s not necessary and is really impossible to know all the history and related details. But knowing the history of your team definitely helps you form a long-term vision with clarity and confidence.
3. Understanding the future
The future you are moving towards includes where you are going and when you plan to get there. This is the long-term vision of your team. It is ultimately determined by the status quo and future business needs.
For example, if the business plans to reach 50% market share in three years, but the current system doesn’t support the traffic coming from 50% of the market, then your vision might include upgrading the system to make sure it can meet the business needs by that time.
Essentially, domain knowledge and long-term vision are the contexts that surround your day-to-day work.
Why domain knowledge and long-term vision are as important as technical skills
First of all, domain knowledge and long-term vision give meaning to your everyday work. Which one of the following excites you more: “write this code to finish this three-point story” or “write this code to remove one of the limitations of the system which brings us one step closer to handling large traffic and serving more customers”?
Secondly, domain knowledge and long-term vision serve as your compass for making decisions, big and small. How many people does the team need to hire this year? Which projects need to be worked on this quarter? Which approach should we use to solve this problem? Engineering is about making tradeoffs. There’s no objective best solution. What you care about is the solution that works the best for your current context. Domain knowledge and long-term vision provide you the context to prioritize things and make decisions.
How to gain domain knowledge and form long-term vision
1. Getting your hands dirty: experience, experience, experience.
Nothing substitutes for experience. The longer you work with the code, the more areas of code you touch, the more domain knowledge you gain. That’s why the person that has been on the team the longest typically knows the most about the system.
To make the most out of your experience, you should always pay attention to the surrounding context of your current project. Don’t just focus on that piece of code you are working with. Try to understand how it’s being used and how it fits in the overall system. Don’t just try to finish your project as fast as possible. Try to understand why it’s important and its relationships with past, current, and future projects. In other words, don’t just do what you are told. Be mindful about what you are doing, why you are doing that, and the downstream impacts.
2. Use the 5 Whys Technique
The 5 Whys technique means asking: ‘why’ five times. It was originally developed by the Toyota Motor Corporation for troubleshooting root causes. But it’s also effective for understanding the context of our work.
Here is an example:
- Why do we want to refactor this code? So we can move the functionality out as a service class.
- Why do we want to move the functionality out as a service class? So we can decouple the use cases from the implementation details.
- Why do we want to decouple use cases from implementation? So we can gradually encapsulate all the implementation details behind an API.
- Why do we want to have an API? So we can move the service out to a different server if needed.
- Why do we want to move the service out to a different server? Because this service is the most CPU intense one and moving it out allows us to allocate more computing resource just to this service.
3. Pick senior engineers’ brains.
As we discussed above, normally, the longer an engineer has been on a team, the more they know about the domain and the more opinionated they are. Try to learn as much from them as you can.
- Pair program with them more.
- Ask them lots of questions (why, what, how), especially when they hold strong opinions.
- Schedule casual 1on1s or walk-and-talks with them.
4. Building a solid technical foundation.
Improving technical skills makes us good implementers. Gaining domain knowledge and developing a long-term vision make us problem solvers and problem finders.
A man came upon a construction site where three people were working. He asked the first, “What are you doing?” and the man replied: “I am laying bricks.” He asked the second, “What are you doing?” and the man replied: “I am building a wall.” As he approached the third, he heard him humming a tune as he worked, and asked, “What are you doing?” The man stood, looked up at the sky, and smiled, “I am building a cathedral!”
Start focus on the other side of technical skill: gaining domain knowledge and forming long-term vision, so you can become the architect who designs cathedrals and leads teams that build them out.