I joined Microsoft straight from my college, Indian Institute of Technology Guwahati, making it my first experience in the industry. Over time, I have grown tremendously and have had so many new experiences. This blog attempts to structure my thoughts around it.
So, here are the five key things I’ve learned.
“The common facts of today are the products of yesterday’s research.” — Duncan MacDonald
When I say research, I mean two things:
Doing research to find the root cause of the problem.
I realised something pretty early on: it’s very easy to get into the habit of not getting into the details of a problem or understanding the actual reason for the problem. And if you don’t know the exact reason for that problem to exist, it’s almost always going to bite you when you have almost solved the problem. Almost is a very important word here.
Doing research to find the most efficient solution to a problem at hand.
It’s important to understand that we don’t just want to solve a problem; it’s equally important to also solve it in the most efficient manner. That is what separates great work from average work. To excel, it takes some time to learn this mindset and not just complete work. This is what gives you the most growth.
Anyone knows that background research or homework is very important in a scenario, but yet it’s also very easy to not do it completely, especially when you are now solving multiple problems instead of a single problem.
When you have multiple things on your mind, it’s very easy to compromise and not reach the depths of all of it or lose track of things. Hence, it’s extremely important to keep this thought in the back of your mind.
Thorough background research helps us not only look at problems efficiently and find optimum solutions to them — but also to not lose sight of the bigger picture.
The most important thing to remember is that we are not getting paid to solve problems quickly but to solve them accurately and completely.
That requires research, research, and more research.
Murphy’s law states:
“Anything that can go wrong will go wrong.”
After two years, I know this law well, and this is nothing but the truth!
Time and again I have observed in all my projects, that this is always the case and those that don’t know this, are bound to find it out the hard way.
Hence, it’s very important to first divide a big solution into very small individual chunks. Then, take time to ensure that you have gone over all exceptions/errors that can happen in those smaller individual chunks.
At the same time, also understand how these chunks would behave together and what exceptions/errors can happen due to their interactions.
The key is to develop farsightedness.
But what do you do while you are developing your farsightedness? You create a lot of checks and balances to catch these notorious issues beforehand.
A lot of these future issues can be caught initially with what is called unit, integration, and performance tests. One of the key technical lessons that I got only when I started working in the industry, was the importance of writing code with proper test coverage. Not only does this help me but it also helps the entire team, which would take my work and extend it in the future.
To catch issues missed by our tests, there also exists infrastructure called the
Pre-Production Environment where the idea is to simulate how things work in the real world aka Production Environment. Ensuring that your piece of code runs in this Pre-Production Environment for some time is very important.
Even after all these checks and balances, things can still go wrong.
The most important thing to do then is to learn from these issues and not beat yourself up for that — because it’s even more crucial to not let those mistakes happen again.
Working in the industry brought an important realisation to me: we have too many problems to solve, but the time is limited.
This makes appropriate prioritisation and accurate estimation key components to a successful team — and as an individual. Since we don’t solve any problem individually, I have come to realise that any problem can be solved eventually, but it’s important to gauge the time required for it and how important it is.
To answer the question of how important it is, we assign priorities to a task, which can be a simple number denoting the importance of it. We also assign a number to denote the days that we estimate would be required to tackle the issue. These two data points are very important because of the following reasons:
And that’s how we try to answer the important question, which is
What problem to solve first?
An incident is an unplanned interruption to your customers who are using your service.
“Incident management is a process for logging, recording and resolving the incidents as quickly as possible to restore the business process or service back to normal.”
When I was in college, I always imagined that my work would involve writing code to solve a problem at hand a.k.a creating something. But I have realised in the past two years that a very important part of my job is also to contribute by mitigating an incident in our product.
To manage these incidents, we take turns in our team and take responsibility for the entire product. Hence, when this incident does happen, it can be something unrelated to what I previously created.
Now, what did these incidents teach me?
Incidents like these in the past have made me realise it is very important to be aware of what others are working on.
This not only develops a habit in me to look at those solutions and find issues at the very beginning of their creation — but also take inspiration from those and reuse key components in my own solutions.
These incidents cause major interruptions to our customers/stakeholders, and often it becomes a high priority to resolve this quickly.
These also teach you so much about the importance of the nitty-gritty of things, so you can understand things in depth. The priority of these incidents promotes quick thinking and teaches you to quickly propose clean, robust solutions to unblock your customers.
Often, while resolving such incidents, one also comes face to face with bigger problems which in turn helps us also understand the following:
Where our product lacks?
What problems we should solve in the future?
“Whatever anybody says or does, assume positive intent. You will be amazed at how your whole approach to a person or problem becomes very different. When you assume negative intent, you’re angry. If you take away that anger and assume positive intent, you will be amazed.”
— Indra Nooyi
Team collaboration is a very powerful thing that amplifies individual work.
It is only in a professional setup that I understood the role played by a group of individuals with their unique strengths and experiences when approaching and finally solving a problem.
A new pair of eyes also always helps when trying to find out a solution to any problem. Hence, smooth collaboration is very important in tackling challenges.
Collaboration in Microsoft is not just working with people in your office but also working with people in different continents and timezones too.
Now, how can one optimise this, especially when you are collaborating with someone you have never met? You neither know the person nor would you have any idea of the challenges faced by that person.
To top it all, we all faced a once-in-a-lifetime scenario where everyone had to work from their homes due to the COVID-19 pandemic. Our team sizes grew enormously in this period and many of our colleagues joined the organisation virtually.
The biggest thing I learned in all of these situations was that the best way to approach things is to always assume the best intentions of others and always remain cognisant of the problems around them.
Showing patience and confidence in these times always helps build up a good team spirit and a positive culture. Over time, this also shows up on paper too.
I feel at the core of it, software engineering is about problem-solving, where it’s relatively easy to grasp and understand technicalities, but it’s rather more difficult to understand the right attitude, outlook, and approach towards a problem.
My key focus with this blog was to reiterate a lot of things we always have known yet we tend to ignore time and again. Keeping such points at the back of your mind is what separates a professional from an undergrad and the past two years for me were spent making this shift.