Live data from Hacker News

In 8 months at Microsoft, I learned these things

ahmetalpbalkan.com

21–30 of 286 posts

Re: In 8 months at Microsoft, I learned these things

#22
post #13

I am doing an internship in Windows and I have to say his first few points are right on the dot. The windows debugger does have proper documentation. I know this because two separate people on opposite ends of Windows Org made a point to mention this. Yet the documentation itself is not more than one would expect from complex software's man page. This contrasts well with the software I am integrating with for one of…

If you're interested in package management solutions on Windows, you might want to see http://chocolatey.org

Re: In 8 months at Microsoft, I learned these things

#24

Earlier quoted context omitted.

I find that statement hard to believe. The Azure Insiders mailing list has multiple threads mentioning other competitors such as Heroku and Rackspace.

I don't. Microsoft has such a high level of not invented here (NIH) syndrome sometimes that I'd find it easier to believe that engineers on the ground are simply unaware of the competition.

I'm not suggesting they should all know, but I don't believe all are completely oblivious to the outside world.

Re: In 8 months at Microsoft, I learned these things

#25

"I am surprised that no one I met in Windows Azure team heard about Heroku or Rackspace, which are direct competitors. That’s acceptable, not everybody has to know these." WOW! It's one thing to ignore competitors, it's another to not know who they are. I thought (by reputation) that Microsoft was a competitive place. "It’s hard to find a position in corporations matches what you love to do." Seems obvious, but hinds…

Ya, he's not paying attention. I work for Azure and everyone is very clearly aware of the world and the competition.

Re: In 8 months at Microsoft, I learned these things

#26
I wish I could say things were better on the academic end of scientific computing.

Expect no documentation in corporations. --> Expect no documentation in research code.

It is not what you do, it is what you sell. --> It is not what you do, it is what you publish.

Not everybody is passionate for engineering. --> It is not what you do, it is what you publish.

2-3 hours of coding a day is great. --> It is not what you do, it is what you publish.

Not giving back to the public domain is a norm. --> Not giving back to the public domain is a norm because you might not own your data, or because you might not have any documentation.

The world outside is not known here a lot. --> Ivory towers?

It is all about getting shit done. --> It is all about getting shit published.

Copy-pasting code can be okay. --> Copy-pasting code is okay.

Code reviews can be skipped. --> Code reviews? You're lucky if we keep track of revisions.

Your specialties usually do not matter. --> You are your specialty.

At the end, you are working for your manager’s and their managers’ paychecks. --> At the end, you are working for your advisor and your advisors’ grants.

Re: In 8 months at Microsoft, I learned these things

#27
I spent 5 years at Microsoft as a dev and share almost none of the author's sentiments. I had very few meetings, my manager went out of his way to make sure that I was not blocked, code reviews were mandatory, blogging on technical aspects was ok, had ample free time to work on any side project I wanted (even encouraged to work with MSR on things that were more researchy), etc etc... I could go on for a while.

Sure, there was a huge emphasis on shipping rather than spending days space architecting the codebase and sure, not every piece of code was a stellar example that would show up in a college textbook but I'm having the exact same problems while doing my own startup, where at times I knowingly incur some technical debt in order to ship on time.

Re: In 8 months at Microsoft, I learned these things

#28
I can't decide if this post is a joke or not. Yes a lot of what he describes goes on in many large corporations (although rarely ALL of what he describes unless you're one of the unfortunates stuck at one of the REALLY dysfunctional companies), but the way this article is written makes it sound like you should expect and be satisfied with all the things he describes. If the company you work for suffers from about half of what he describes that's probably about "average" for the industry, but that just means you've got a mediocre job. If your company checks 3/4 or more of that list, your company sucks, look for something better. If your company exhibits none, or only a couple of the problems, that's a pretty good company, consider yourself lucky (although try to fix the problems if you can).

Just because something is dysfunctional in the company you work for doesn't mean you should just accept it, you should try to change it if you can, but depending on how far down the totem pole you are you probably won't be able to make that big a difference. In general, the better the company you work for, the more likely you'll be able to fix what problems there are. If a company is so dysfunctional that there's no hope for change, start looking for something better, don't put up with a horrible working environment just because the company is "big" or well known.

Re: In 8 months at Microsoft, I learned these things

#30
post #15

This post is spot on and applies to more companies than you can imagine. Reading Hacker News gives you a really skewed view of how things work and how people think in the software business.

I completely agree. Even late stage startup will begin to look more like what the blogger has described. The blogger should gain some exp and move on to a small/early stage startup or find a way to move in to R&D role within Microsoft -- these positions normally offer more freedom and greefields.
Post reply on HN