Hi, I’m Ken Mazaika and I’m the CTO & Co-founder of The Firehose Project.
When I was twenty years old, I landed an internship working as a software developer at Microsoft. At the time, I was pretty confident that I was not ready for this position. But I couldn’t pass up the opportunity to work as a developer at such an iconic company. So I jumped in. Little did I know that I would learn the most vital lesson of my career after telling a senior developer that he was wrong.
It’s a lesson that nearly every entry-level worker needs to eventually learn in their journey to becoming an impactful employee. And when you learn it, your perception of yourself as a professional will change forever.
Prior to my internship at Microsoft, I had a bit of professional experience writing software. Just not a ton. I had worked for one legitimate company. In my role, I helped write software that factory workers used to install firmware, configure devices, and run automated tests to ensure things worked properly. The development team was small, employing just 3 people. And I worked in a codebase that contained somewhere between 10,000-50,000 lines of code. This was all the professional experience I had prior to my role at Microsoft.
Prior to my starting date at Microsoft, I exchanged a few emails with the lead of the team, who gave me a bit of work I could use to prepare for my first day. I worked on a couple of projects in C++, the programming language the company primarily used, and I tried to get a feel for the basics of this language. C++ is a low-level programming language that requires you to deal with complex concepts, like memory allocation, deallocation, pointer arithmetic, etc. You don’t need to worry about these concepts in most other programming languages.
A group picture from my time at Microsoft back in 2008. Highlighted is Ray Ozzie (the former CTO of Microsoft), and me (a far less important employee).
It was day one.
I spent my first few hours building some toy projects. in a programming language that I was relatively unfamiliar with. Shortly after, I was introduced to Ransom, the senior developer who would be supervising me during my time at the company. Ransom helped get me access to the project’s source code, which had about 10 million lines of code and around 70 or 80 developers working on the same application at the same time.
I was used to working on much simpler projects. On these projects, if I changed the code, it would take 3-4 seconds to test it out. But at Microsoft, any small changes to the code would take 8-10 minutes for testing. Additionally, a full rebuild of the entire project would take 4-5 hours, and people would generally only start this right before heading home for the day.
Very quickly, this XKCD job transitioned from being ridiculous to 100% accurate.
I was so far outside my comfort zone, and I started to question if I’d ever be able to genuinely bring value to the company during my 6-month internship. Additionally, I was a college senior, which meant that I lived with the constant fear of not landing a job after graduation. I was absolutely certain that there wasn’t a chance that the other devs would actually want me to stick around.
After what seemed like forever, I was able to compile, run and launch an actual application and set up my dev environment. Ransom gave me a quick rundown of the source-code. He focused mainly on the code that I would be working on next.
I was responsible for working on was Microsoft’s “Groove” product.
It was a peer-to-peer sharing system for businesses. At the time, we were adding a tight integration to SharePoint, providing both peer-to-peer syncing on top of SharePoint and a rich client that would make it easier for people to sync their work.
My group was called the “Storage and Synchronization” team. One member of my team built the database and file storage system of the project. Another member architected the integration with the SharePoint API. Overall, we were responsible for the peer-to-peer syncing technology. Peer-to-peer syncing can get fairly complex pretty easily. An example of this could be something like:
- Person 1 adds a file and disconnects.
- Person 2 syncs the first file, disconnects and makes changes offline.
- Person 1 makes additional changes to the file.
- Person 3 adds a new file.
When each of the three people connects to the central, SharePoint site, the synchronization engine needs to sort out the state of the system. My team was responsible for building this functionality.
Ransom (my mentor) was an expert at each of these three aspects of the product (and much more too). It was his job to take turn me from an inexperienced developer into a competent, impactful member of the team…all within a 6-month window.
I still remember the first task that Ransom assigned to me.
We had some internal automated tests for the synchronization engine. He said something like:
“I want you to improve the internal tests we have for the synchronization engine. Here are some edge cases that should be tested, but aren’t. Also, ultimately it would be good to be able to perform this specific type of test, which is currently impossible.”
Performing this one task, which would’ve taken Ransom probably less than a day, took me my entire first month at Microsoft. Here’s how the process worked:
- I worked for three or so days, thinking I was cleaning up the code and making it easier to write more tests, getting it closer to the format that matched most of the books I had read on C++.
- Ransom asked to look at the code I had written.
- I showed him the code, feeling like I wasn’t ready for him to review it.
- He went through it, line-by-line, explaining why each decision I had made was wrong.
Ransom told me about the things I was doing wrong, and we decided that I should start over. He obviously knew better than me, so I followed his direction.
So I reverted the change. Ransom told me that a number of people had made changes so after reverting the changes I should update my code, so I did.
I went back to the drawing board.
I decided that I was not going to make the same mistake. I worked for a few more days, this time going in a different direction. Then, I showed my new code to Ransom. He pointed out a couple of good things I had in my code, which made me feel accomplished.
But then, he again told me about a ton of things that I did wrong. And again, we decided that it made sense for me to start over. I knew that I needed to follow his direction because he knew best.
So again, I reverted the past few days work. In the process, I also pulled down all the changes my coworkers had added in the past few days. At this point, I felt like I might not be good at writing code. The only thing that I felt like I was good at was reverting all of my work.
Around that time, I was introduced to a different developer, named Dana. Dana was very senior and incredibly intelligent, too.
I wanted to impress Ransom, so I didn’t want to get too much help from him. But I learned that working by myself was causing me to have to completely revert all my work. I started to bring pretty obvious questions to Dana. I felt like these were stupid questions, but I wanted to start getting things right and knew that I needed to learn to do so. So I asked them anyway.
Each day I would bring one or two of these seemingly stupid questions to Dana.
She would explain for an hour or more about how things worked. Things were always way more complicated than I would have ever imagined, but I started to become more comfortable. By getting answers to questions that I previously thought were stupid, I was beginning to build my understanding of what I was doing.
After a few days, I was ready to check in again with Ransom. He went through my code line-by-line and again found a ton of problems. But my code was workable! I was far from perfect, but I felt like I was headed down an OK track.
Eventually, I shipped a small improvement to the project’s automated test system. Having said that, there were still issues.
- The code was totally unimportant.
- It required me to spend more time talking to senior people than it would’ve taken for them to have just done it themselves.
I was excited to officially have my code in the main codebase, but I still felt like I wasn’t adding much value to the company.
I knew that I was still just following the direction of my superiors since they knew best.
Over the next couple months, I started working on things outside the test system and working on the real code of the project. My manager assigned me a couple of very easy fixes, and each one took far longer than I would like.
I slowly started to be able to accomplish more and more, but still didn’t feel like I was bringing a lot of value to the company. I felt like anybody could do what I was doing, but that they just didn’t have the time.
And when anyone more experienced than me would tell me to do something, I would simply follow their direction. After all, they knew best.
But then, one silly thing changed everything.
I still remember the memory leak window popping up.
We used a tool that informed us if we introduced a memory leak, which is a specific (and pretty bad) problem in code that’s fairly easy to introduce when working in C++.
At the time, I was confused about why the tool triggered the notification window.
I hadn’t run into too many memory leaks in the past, mainly because I simply followed the patterns that my team had set forth. But the window popped up on some code that I was working on. I asked for a few suggestions about how to debug the problem, received some high-level advice, then set out to fix the problem.
After a few days, I found the root of the problem, which stemmed from the fact that a different developer wrote a method that had a Pointer, instead of a Smart Pointer, in a method signature. This meant that the memory deallocation wouldn’t work the same as it worked in other places in our code. In this case, the code caused the smart pointer to no longer operate how it should. Ultimately, the memory would never get deallocated. This is a bad problem.
I remember being confused by the specific line of code. I went into the code’s history and I discovered that it was written by a developer who worked on a different team than mine. Shortly after, I found out that this developer was actually very senior, and he happened to work in an office that was very close by. I was so nervous, and I still remember knocking on his door and asking:
“Hey, can I ask you a quick question about some code you wrote. I’m really curious why you wrote the code a certain way.”
I showed him how I could use his code, but also how I had to use a fairly confusing work-around for it to function properly. Based on my past struggles, I expected a fairly detailed answer about why the other approach wouldn’t work. But his response really blew me away:
“Oh yeah. You’re right, it should be the other way. I can switch this out if you want, but it might be easier for you to just do it, since you’re working with it anyway.”
Holy cow. In this brief moment, everything changed for me. No longer did I feel like the inexperienced intern who needed to blindly follow the direction of my superiors because they knew the best way to do things.
In fact, in this moment, I realized that I could do something better than my superiors. And this is precisely how I could bring value to the company in a way that nobody else could.
I could uncover a problem in the code, figure out a solution, and make an improvement to the product that had been missed by senior developers, code reviewers and other people who used the code. This was an incredibly powerful feeling. And I wanted to experience again.
It took me about 3 months to arrive at this moment. But once it happened once, it began to happen more and more often. A week later, it happened again. And the next week, it happened too. Before long, it felt like I had these types of moments almost every single day.
As someone just breaking into a new field, it’s normal to feel intimidated by the people with more experience than you.
So you follow directions, word-for-word, without stopping to ask what you might think are stupid questions. When you’re caught in this cycle, it can feel like you’re operating your job using Google Maps. You blindly follow step-by-step directions without thinking critically about where you’re going and why. If you’re doing this, you probably feel like an interchangeable cog in the machine, and you’re unclear about how to add value to your company.
But if you start asking the right questions and get your feet wet in some cool work, everything starts to change. You start to realize that the people ahead of you aren’t perfect. In fact, there are a lot of things that they oversee that could be done a lot better. By combining what you’ve learned with your own unique perspective, you can do aspects of your job far better than your superiors ever could. This is when you really add value.
Never doubt that you can do something better than your superiors. Getting to this point is the only way that you can truly add value to your company.
When I left Microsoft, I had changed thousands of lines of code in the core product. I made changes in the backend, file system, synchronization and SharePoint integration code, and more. If you told me at the beginning of the experience that I would be able to do things like that, I would have laughed in your face.
But I did it.
And it all started with telling a senior developer at Microsoft that he was wrong.
If you enjoyed this post, I’d appreciate it if you shared it using the Facebook and Twitter buttons below.