
What I learned in 8 months at Microsoft
- Transfer

My internship at Microsoft Windows Azure began exactly two years ago, right after college, and it took place in the same team with which I had worked for the past eight months.
Recently, it occurred to me to draw a definite conclusion and talk about some of the principles that I have learned in these eight months. It may seem to the reader that they are not doing the most enjoyable job - but no, it is not. I already realized that exactly the same problems exist in all large companies , and most of what I have noticed concerns not only Microsoft - in addition, each company also has its own problems.
I can’t say that I was unhappy, and I don’t want to complain about anything ... but in college no one warned me about these things.
So let's go.
- Do not expect to find documentation in the corporation. Based on what I happened to see, all the knowledge in the company is transmitted mainly through conversations and master classes. Some of the available information is transmitted by e-mail and is generally not stored anywhere. In the rest of the world, this is now not accepted - because if someone suddenly accidentally gets hit by a bus, then no one else can easily take and continue his work (for example, sit down and immediately write further code). And here it is considered the norm. If I had a company, I'd rather have a wiki with thousands of pages.
- The important thing is not what you did - the important thing is what you sold. You can improve your code for days and correct other people's mistakes, but so far this has no effect on sales and the result of efforts is impossible to sell - your work means practically nothing. No one is interested in your code changes in pursuit of its purity or stylistic unity; nobody is interested in solving problems with architecture. You may even be offended if you do this. When I was a student, they didn’t tell me that.
- Not everyone cares about programming. You will not always work with those who dearly love software development. Most people here have something else in life (family, children), so the desire to write clean code is most often not part of their plans. And this is normal. I learned not to wait for enthusiasm from everyone and everyone.
- 2-3 hours of pure coding per day is a wonderful figure. Before I got to my work, I programmed 8-10 hours every day, sitting at my projects. And in the new environment, I barely manage to write code 2 hours in a row. I spend most of my time trying to understand how someone else’s uncommented / undocumented code works, debugging strange program behavior, and attend daily meetings. All of the above concerns not only me, so it happens that days pass without a single commit in the whole team. And this is also normal.
- Doing nothing for others in return is normal. In my organization, I have not met a single blogger or open source developer who would devote part of his time to any “repayment” of the community. Googling answers to Stack Overflow is a pleasure, but no one will ever write their answer to a question there. I understand them.
- It is not too aware of what is happening in the outside world. I think all of you read various IT-related news every day on blogs, on Reddit or Hacker News. This is not accepted here. I was surprised to find out that none of the Windows Azure team had ever heard of Heroku or Rackspace - and these are their direct competitors. This is acceptable, but not everyone should know about it. (There really is a striking resemblance to Apple, according to Adam Lashinsky's book “Inside Apple” - a translator’s comment)
- The bottom line is to get things done. If the manager asks you for a button that will do this and that, then nobody cares what you do there. When the requested function begins to work, we can assume that the task is completed - everything else can be corrected later. Although, to be honest, I myself have never come across this promised “later”. In college, they told me that the quality of the code is as important as the result of its work. It turned out that this is not so.
- Copy-paste code is normal. If someone on Github catches you at a similar trick, get ready for the reprisal in the dark gateway. Immediately, I repeatedly met the source code, which simply copied from project to project. Since they were doing their job (more on that later), nobody was interested in the fact that the code was completely unsupported.
- For the sake of speed, you can do without code review. This is one of the customs of our team - if you contacted someone else's code, then you should send code review. Usually, no one does this, and you can wait a lot of time before someone answers you after the tenth letter.
- Latest software versions, yeah, well . Not everyone likes the latest versions. 90% of my colleagues use older versions of Office, Windows, Visual Studio, and the .NET Framework. There is a superstition that new versions completely break the established workflow. Probably, they are guided by those who still run all their applications in Java 1.3 - 1.5. So I learned how to wait for the use of the latest software versions in projects.
- Your specialization does not matter. Students are hired by thousands and randomly shoved into teams (which you cannot change for another year and a half). It doesn't matter if you had fun with MongoDB, developed applications for iOS, committed to Apache, designed interfaces or bootstraped your personal startup. You were hired to do what they say. I did not expect this. It is too difficult to find a place where you could do what you love.
- In conclusion. You work for your manager and for his salary. No one has ever spoken to me about this before.