He certainly didn’t forget the nuances of the problem – we had recently talked about it, and Ransom as one of the smartest devs I had known. “Is it fair to say, that’s how the system is built?”
I imagined walking through the specifics of this pretty complex bug, some of the limitations of the architecture, the specific workaround, and talking about the specifics. When audience asked the question, I closed my eyes and put myself in Ransom’s shoes. It was clear that he understood the core of how the system worked, but he overgeneralized it a bit and didn’t account for the edge cases that Ransom and I had discovered. The audience member described his interpretation of how he thought out system worked and asked Ransom if his interpretation was correct. The question was in relation to the system that Ransom and I were discussing a few weeks earlier. After about 6-7 minutes, Ransom answered a question in a way that would permanently change the way I thought about teaching. It was really cool to see my mentor representing my office on a stage in front of hundreds of people.Īfter Ransom finished his presentation, he gave the audience time to ask questions. He broke down the organization of different structures in the application, walked through examples of how our engine could sync things across peer-to-peer networks (plus SharePoint and other endpoints too) and talked about how everything was set up. I watched Ransom articulate exactly how our system worked. He flew out to Redmond, and his presentation was video streamed for developers outside of Redmond.
He was scheduled to talk about how our system was architected. A few weeks later Ransom was set to give a presentation to the entire Microsoft development team. Ransom and I decided that it made sense to solve the bugs in this edge case in a way different from the way from how the core of the system was designed. Unfortunately, this edge case didn’t fit inside the paradigm like everything else.
#KEN MAZAIKA CODE#
Our code had a sophisticated, thought-out organization. I explained the bug to Ransom and walked him through why it was happening. I knocked on Ransom’s door to tell him about it. There was a problem with the way our files were synced peer-to-peer. There was one bug that I remember in particular. I was developing a better eye for noticing problems too. By the end of my internship, I was shipping features and bug fixes very quickly. Over time, I became more and more effective. It was painful. But the process taught me more about programming and problem solving than any other experience I had gone through previously. Ransom probably could have done it in only a few hours. After a painstaking month of work, dozens of hours of talking things through with Ransom and other developers, and a number of code reviews that made me start over from scratch, I finally shipped a feature. The first responsibility that I had was to spruce up the automated test suite in a very narrow and specific aspect of the product.
I was assigned a few basic tasks that would help me get familiar with the codebase, workflow, and product. I’ll rewind a little bit to give some context. I learned the most important lesson from him when he lied on stage at a huge Microsoft conference.
#KEN MAZAIKA HOW TO#
He taught me so many things about how to help other people learn quickly.īut here’s the crazy part. I wrote about the most important one on Inc.com a little while back. Throughout my internship, I learned more than one powerful lesson while working with him. But he always took the time to make sure he put me on the right track and in a position to complete my assigned work. To be honest, I was intimidated by Ransom. I’d always see other senior developers knocking on his door to ask for advice. Ransom seemed to know everything about the codebase. He took me under his wing and accelerated my learning. I had a lot of people to thank, but the most important one was my mentor, Ransom. It was scary.īut by the end of my 6-month internship, I had turned myself into a contributing member of a high-performing team. I couldn’t have doubted myself any more than I did. Despite that, I was expected to help the dev team build a better product. I had to work in a codebase that spanned millions of lines of code and use a programming language that I was completely unfamiliar with. We were responsible for the internals of a distributed peer-to-peer network, and it was one of the most complex applications I’ve ever worked on. I was working on the Microsoft Office team.
#KEN MAZAIKA SOFTWARE#
Early in my software engineering career, I had an internship at Microsoft.