It was a dreary February day in 2010 when I started at Microsoft. I sat bored, reading my Kindle in New Employee Orientation (NEO). Now, a little over one year later, I seem to be endlessly busy. I am okay with this as it is preferable to the wretchedly boring first two to three months of work. Those early months largely consisted of reading and pondering, trying to get my footing with the breakneck pace which everyone around me was working. Today, I like to think I hold my own on my team. However, there are a few things I have learned:
- Questions are free. Ask lots of them, people will forgive you if they’re dumb. There’s an impossibly large amount of technology floating around Microsoft and no one can be expected to know it all.
- Whiteboards are awesome. Bored? Draw a picture! Stumped? Write it out, draw pictures, diagram! Can’t keep track of what you need to do? Write it down! I was never big on whiteboards until I got here and seeing as it is hard to huddle around a piece of paper, whiteboards solve the problem.
- Identify the strongest developers and consult them, always. I have always considered myself to be a strong developer given my experience. That said, nothing matches people who have worked with software for 20+ years. They may be set in their ways, but often they have vast quantities of knowledge to share. I spend half my time working out problems with the guys that have been around the block for a while.
- The best SDETs (Software Development Engineer in Test) are the ones who know when to compromise but also know when to not back down. As an SDET, you are the last line of defense for ensuring that the product code is of the quality expected to ship. Correctness is vastly important in software engineering, however even if everyone agrees that the correct solution is X, sometimes the timeline dictates you settle for a lesser solution Y which only solves a subset of the issues. Knowing when to compromise and accept that lesser solution is an important skill to develop, otherwise you’ll never be happy and be continually at odds with your Developers and PMs.
- Speak your mind. If you want people to take you seriously, speak your mind. People are smart at Microsoft, but they are not mind readers. Recognition from your peers comes from making compelling arguments for causes you are passionate about. Even if you are wrong, if you make a well reasoned case for your argument people will respect that.
- Make mistakes. Lots of them. Then learn from them. You will make mistakes, have no doubt about that. What will set you apart from your peers is how quickly and effectively you learn from them.
- Smart objects/pointers are your friends. I spend about 90% of my time writing C++ code. During the year I have had to develop my C++ skills, the single most important concept I have applied on a daily basis is wrapping everything in smart pointers. Most of our debug breaks and nasty bugs come from memory leaks, ref-count errors and unreleased resources (Handles, Critical Sections, etc.). In addition to this, RAII is key when you must allocate and de-allocate resources yourself (e.g. Critical Sections).
- Recognize solutions, not problems. Newer hires tend to identify problems and raise them. This is great but it still does not solve the problem. Experienced engineers tend to identify solutions and act on them. Part of the transition from going from a junior engineer to a senior engineer is learning to identify solutions instead of problems.
- Work on your “soft” skills. Your technical skills will not set you apart at Microsoft. There are far too many smart people at Microsoft in order for you to differentiate yourself as some sort of “Rock Star Programming”. What will set you apart and what makes engineers successful at Microsoft are “soft” skills, also known as people skills. You gain seniority by your ability to convince others that you are correct and to rally them behind your cause. There is no doubt that technical skills play a huge role in advancement, but the differentiator will be your soft skills. Between two engineers with similar technical skill levels, the engineer who will be more effective job is the engineer with the strongest soft skills.
Overall, this is just the short list of things I have learned. The most important skill I learned was the last point, “soft” skills. I am still not great at dealing with people and that is partly due to being an introvert. My first instinct when dealing with conflict and people is to hide. I prefer to solve technical problems, not people problems so my first tendency is to solve any particular problem by going after the technical points and avoiding the people. The biggest problem with this approach is that I tend to identify ways in which I can push through the solution I desire technically and avoid the people. In other words, I tended toward the “it is better to ask for forgiveness than permission” approach.
In the end, the points I outlined above apply in nearly all settings as an engineer (software or not). These are by no means Microsoft isolated, however every company has its own culture so some of the more social aspects of the points above may need massaging to fit the company you work for. My only other point of reference is my time spent at Google and my impression is that the same principles apply. The technical points though are applicable in all cases and should have no exceptions.
Ultimately I would like to write this sort of post about once a year to contemplate what I need to work on as an engineer as my career progresses with Microsoft. Despite the hemorrhaging of talent from Microsoft to Google to Amazon to Facebook and back, I see myself staying with Microsoft for a while. While Amazon has established itself in the market, I am unconvinced that Google or Facebook will continue to keep their edge. Microsoft has its quirks but I think any successful company does and Microsoft has made some significant changes internally that I feel show a change for the better.