My internship at Microsoft as a Software Design Engineer ended about a month ago, and now that I’ve had a chance to let my thoughts and impressions settle, I’d like to share some of them with you. In many ways, working at Microsoft was exactly what I’d expected, but in many other ways it was completely different.

Probably the most unexpected thing I experienced was the high degree of autonomy I had during my internship. At the start of the internship, my team gave me a high level description of what I’d be developing, and introduced the the tools, frameworks and technologies I’d need to use. Then they had me propose a feature set and general design for the project, and let me loose to work on it. I’m not sure how similar this experience is to what other interns typically experience, but I really enjoyed it.

Another thing about Microsoft that surprised me was how vertical their management structure was. In hindsight it makes perfect sense. Microsoft is such a big company that they need to have lots of layers of management, or nobody will be able to keep track of their direct reports. Not to mention that with thousands of software developers employed, you have to provide a variety of career paths or you won’t keep your employees for an extended period of time. This has a side effect of insulating developers from upper management and other developers, to a degree. In many ways, this is a great thing to have, because it helps to minimize sources of potential distraction. The unfortunate consequence of this is that it’s very hard to get a feeling for the corporate culture in other areas of the company, areas where your chosen career path might eventually lead.

I expected Microsoft to be a monoculture, and it was, if not to the degree I had anticipated. I think this is probably one of Microsoft’s biggest weaknesses. In my experience, making difficult or innovative design choices gets easier if you’re familiar with different solution approaches in the problem domain, particularly ones that haven’t caught on widely yet and ones that have failed in the past. Personally, I think it’s far more important for employers to consider a potential employee’s exposure to a variety of development methodologies, user interface styles and programming paradigms than it is to require proficiency in the latest language of the month. It’s hard enough to be innovative if you’re already familiar with the bleeding edge of technology.

Finally, I was surprised by how much design effort was focused on avoiding the future need to break backwards compatibility. Personally, I’m of the opinion that breaking backwards compatibility isn’t something you should try to avoid; rather, you should try to avoid introducing any bugs into your code at all stages of the software development lifecycle. I can understand why software developers worry about it so much, because breaking backwards compatibility can annoy your users and maybe even open you up to litigation. The way I look at it, trying to avoid breaking backwards compatibility discourages and slows innovation and improvement. It’s like taking a sprinter, and making him wear a lead vest. Sure, he’s less likely to be shot, but if people are shooting at him it’s probably better to address that underlying problem directly.

I still think Microsoft has a long way to go in improving their software, but they’re surprisingly aware of their problem areas and are continuing to make progress. As far as I’m concerned, that’s fine; they certainly aren’t alone in having room for improvement. The field of software development is still in its infancy, so it’s not at all surprising that there’s lots of room left for improvement.