How to Accumulate Domain Knowledge Like a Senior Engineer
Understanding domain knowledge is critical to the project's success.
For the very first time in my team, I was the one who had the most opinions about the new feature that was created by the other members of the other team.
"It is crazy how much knowledge and opinion I have," I thought.
After being told to be more opinionated as feedback for the longest time, I was finally susceptible to voicing my opinion during a product requirement meeting.
After that meeting, I was complimented and tagged for being the SME (Subject matter expert) of that product feature.
"This is what happened when I was staying in the company too long," - I half-jokingly replied.
"That is because you have accumulated domain knowledge," one of the managers said.
"Thus, the more domain knowledge you have, the more impactful you are as a team member because they often see you as the leader of that feature."
Domain knowledge is the other half of becoming a strong engineering leader because understanding the domain knowledge well makes a project successful.
What is Domain Knowledge
When you start at a company, you must be shown where the meeting rooms, toilets, lunchroom, and desk are. Over time, you become familiar with your surroundings, enabling you to operate autonomously and confidently.
That's what it feels like when you have domain knowledge.
Knowledge about the Business
You know how the payment transactions work if you are working on payments. You also know how each error code works in payment systems and the commonality of integrating with various payment processors. You will know that payment authorization doesn't mean the money is captured, and the capture phase is usually asynchronous.
If you are in growth, you know about some of the important metrics you should care about growing your consumer. If you are dealing with referrals, you know how the general referral works and how deep linking works.
If you are in the notification, you know that you need to warm up the server before bulk sending your notification, or else that email server will treat the new incoming address as spam.
Knowledge about the Code
When the product asks, "Why didn't we implement 0-based authorization?"
You can explain to the product why we didn't implement 0 based on the history of the code and the long-term vision of that service.
When you understand the history of the code, you will be able to answer many questions regarding why such code was created. During a site incident, you can clearly illustrate what happened and how to troubleshoot the issue because you have all the context.
Why Is Domain Knowledge Is Important?
Knowing the domain knowledge means knowing the business needs and how technology works to satisfy customer needs.
Domain knowledge helps you create a great intuition on doing things correctly because you see many angles.
One example is error handling. You don't need to handle all the errors; your application is robust if you are not working on a critical feature.
In fact, doing so will be over-engineer. On the other hand, when working on a service that requires deep domain expertise, such as payments, domain knowledge can help you robustly design your system. Understand what scenario requires you to retry on failure vs. at what failure scenario you shouldn't because it will cause a double charge.
Engineers usually implement basic error handling without domain knowledge that addresses common scenarios but fails to cover less obvious yet frequent transaction issues. They usually will design a one-size-fits-all transaction flow that doesn't consider the variability of processing times, currency conversion steps, and all the needs for a dynamic route.
Domain knowledge not only encompasses the general business domain of your service, but it also includes what your specific business requires. For instance, knowing about the general payment domain is useful. However, knowing the payment domain specific to your company's business, such as subscription or travel, will make you impactful.
3 Tips to Gain Domain Knowledge
Asks Why
Every task will have a business need. Even a technical debt.
When you are assigned tasks, ask why more than 3 times to fully understand the underlying business reasons for creating such tasks.
For example, you are tasked to expose the updated timestamp from a database. Before you even change the API, plumbing the updated timestamp from the database out of the service, ask why.
"Why must I expose the updated timestamp from a database?"
Because the client requires to know the updated timestamp.
"Why is the client required to know the updated timestamp?"
Because the updated timestamp helps them understand the last time such an item is updated.
"Why do they want to see the last time it is updated?"
So that they can make the decision whether or not they need to know if the price is the most updated.
We can correlate exposing the updated timestamp to the business use case. Your domain knowledge is enlarged, and you understand why such a field is important.
This also helped us understand the root cause of the problem, and we often used this during postmortem. However, that will be another article :)
"DFS" your Architecture
The best thing to understand domain knowledge is to read through the codebase of your immediate knowledge. Then, once you understand your codebase, start looking at the outgoing or incoming calls and explore their codebase. This helps you understand what is happening in each part of your service.
This will help you:
Create faster and better answers to product questions
Faster and more precise estimation of product feature
For example, when working on a payment service, I examined the main payment service that required modifications.
I identified the part of the code that needed to be altered and analyzed the function. After that, I traced back to the calling function and examined the outgoing call to understand its contract. I examined each field to comprehend its meaning. Finally, I discovered that the outgoing call led to another service."
Now, I have a minimum understanding of the payment service's codebase to answer some questions, such as, "What happens when the payment provider Stripe is chosen over Adyen."
I can stop here if I want to because I had no problems understanding any adjacent service.
However, knowing adjacent services will help me understand the bigger picture of the service and the associated team that owns those services.
This helps me make better decisions in extending new features or troubleshooting problems.
I can now understand why the service must send a 0 authorization in some scenarios and how the adjacent team handles those 0 authorization scenarios.
Enroll Yourself With On-Call
On-call is one of those tasks that engineers hate doing. However, at the same time, it is also one of those tasks that propels growth. Lots of growth.
The first time I was assigned an on-call schedule, someone put me into a dark forest and told me to find my way back. Getting pulled into problems such as double-charging or customer service issues has forced me to look into the system in the bigger picture. It also helped me talk to my stakeholders and become a good customer service agent.
On-call is daunting. Looking back, being on-call is one of the best tasks assigned to me, and it helped me speed up my career growth. It taught me about ownership and reliability. When you are the one who can answer questions to stakeholders and explain the problems that they are encountering, you are building trust, which translates to leadership.
On-call is an environment that compels an engineer to learn domain knowledge. You need to know the meaning of certain identifiers in your system, such as payment.
"Is payment equivalent to the idempotency key?"
"What does payment consist of?"
"How do you find the right payment ID for a failed user?"
Being on-call helps you expand domain knowledge because you are forced to get your hands dirty with experience. You are forced to pay attention to the surrounding context of your system, and you will need to be mindful of every single value you are doing and be able to identify the bottleneck or problems in your system that you can improve on.
Engage in Knowledge Session With a Tenured Engineer
Schedule a casual 1 on 1 with them.
Tenured Senior Engineers are usually the most opinionated, and it is because they are usually the ones who know about the domain and have seen the code evolve over time.
You can understand more about domain knowledge by pair programming or pair troubleshooting specific problems. They will explain all the nuances and knowledge of a specific code or system you didn't find elsewhere in the documentation.
When conversing with them, ask them many questions (why, what, how), especially when they hold strong opinions.
Conclusion
Throughout this article, we've explored the power of domain knowledge in shaping us into capable engineers and impactful leaders within our teams. From understanding the intricate details of our business operations to mastering the code that powers our products, domain knowledge elevates our ability to innovate and solve problems effectively. It's about asking the right questions, diving deep into our architectures, and embracing the on-call challenges that come our way.
Now, I want to hear from you. Share your journey of acquiring domain knowledge in the comments. How has it shaped your approach to engineering and leadership?
If you like this article, you might also like these:
Really helpful
When I was a junior then I thought Seniors know all the code in the world. But soon I realized they are good but the area they really really excelled was a great Domain knowledge. Great post!