My internship at Microsoft Windows Azure started exactly two years ago, right after college, and she took place in the same team that I worked with for the last eight months.
Recently, I got the idea to summarize a certain result and talk about some principles that I learned during these eight months. It may seem to the reader that they make the work not the most pleasant - 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 not say that I was unhappy, and I do not 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 have seen - all the knowledge in the company is transmitted mainly through conversations and master classes. Some of the available information is transmitted via e-mail and is not stored anywhere at all. In the rest of the world, this is not the case now, because if someone suddenly knocks a bus accidentally, then no one else can easily pick up 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 would prefer to have a wiki on thousands of pages.
What is important is not what you have done - what is important is what you sold. You can improve your code for days and correct other people's mistakes, but as long as it does not have any effect on sales and the result of efforts cannot be sold, your work means practically nothing. No one is interested in your editing code 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, I was not told that.
Not everyone cares about programming. You will not always work with those who dearly love the development of software. Most people here have something else in life (family, children), so the desire to write clean code is often not part of their plans. And that's fine. I learned not to expect enthusiasm from one and all.
2-3 hours of pure coding per day is a great number. Before I got my job, I programmed 8-10 hours every day, sitting at my projects. And in the new environment, I barely manage to write code for 2 hours in a row. Most of my time I spend trying to understand how someone else’s uncommented / undocumented code works, debugging the strange behavior of programs and attending daily meetings. All this applies not only to 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 a part of his time to any “payback” to the community. Googling the answers to the Stack Overflow is a joy, but nobody will ever write your answer to the question there. I understand them.
They are not too aware of what is happening in the outside world. I think you all read various IT news every day on blogs, on Reddit or Hacker News. Here it is not accepted. I was surprised when I learned that no one from the Windows Azure team had ever heard of Heroku or Rackspace — and that’s their direct competitors. This is acceptable, not everyone should know about it. (There really is a striking resemblance to Apple, according to Adam Lashinsky’s book Inside Apple - the translator’s comment)
The bottom line is to do business. If the manager asks you about a button that will do this and that, then nobody cares what you are doing there. When the requested function starts 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". I was told in college that the quality of the code is as important as the result of its work. It turned out that this is not the case.
Copy-paste code is normal. If someone on Github catches you for a similar technique, get ready for a massacre in a dark alley. Immediately I repeatedly met the source code, which simply copied from project to project. Since they were doing their job (about this below), nobody was interested in the fact that the code is absolutely 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 a code review. Usually, no one does this, and you can wait a lot of time before someone after the tenth letter answers you.
The 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 the new versions completely break the established working process. Probably, they are guided by those who are still running all of their applications in Java 1.3 - 1.5. So I learned not to wait for using the latest software versions in projects.
Your specialization does not matter. Students are hired by the 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, commits in Apache, designed interfaces, or bootstrapped your personal startup. You were hired to do what you were told. 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 his salary. Nobody has told me exactly about this before.