I spent two summers interning as a Program Manager at Microsoft (Xbox and Office), and his statements are nearly 100% accurate:
- Literally any piece of documentation was always 1+ years out of date. Setting up a dev environment could take days when it should have only taken hours.
- A lot of my coworkers were over 35. Starkly different from my experience later at Google. Working past 6 was considered absurd, and a lot of people were perfectly happy just riding the Microsoft wave. There were plenty of engineers who had been at the company 12-18 years with only a single promotion or two.
- I actually was able to do some open source work with Codeplex
- Not a single person I worked with read HN or Reddit, that I knew of.
It's a bit depressing reading the post, but at the end of the day Microsoft was and is still an amazing place to work. I was paid well, the engineers are well taken care of, and the consumer offerings are still fun and exciting.
Although things were done differently than they are done in Silicon Valley, the difference is not necessarily bad, perhaps more eye-opening. This is how MOST computer science majors spend their careers. Not mastering MongoDB, collaborating on Google Spreadsheets, or posting things to HN, but using Windows XP, Visual Studio, and Microsoft Word 2003 on a 2008 Lenovo laptop. And MS is perfectly happy taking their money.
Although things were done differently than they are done in Silicon Valley, the difference is not necessarily bad, perhaps more eye-opening. This is how MOST computer science majors spend their careers. Not mastering MongoDB, collaborating on Google Spreadsheets, or posting things to HN, but using Windows XP, Visual Studio, and Microsoft Word 2003 on a 2008 Lenovo laptop. And MS is perfectly happy taking their money.
I think this is a dangerous line of logic that leads to equating 'new' with 'important.' I think once you get to the point where you judge someone for the tools they use or the sites they browse you go down a pretty negative path. It's shockingly easy to forget how much of the world runs on J2EE and ASP.net.
There's a ton of wrong with that statements tone, not that I think the author meant it that way, but I'll point it out regardless:
#1 - The majority of HN seems to involve typical latests web crud app fads. It's probably also not that interesting to *nix system developers either, though many might read it for the apps being created as opposed to the how.
#2 - Having MongoDB on your CV generally means you're developing for your CV. Occasionally it means you had a valid usecase, but if you tried to sell me on that for a typical app, I'd never hire you.
#3 - The bleeding edge is called that for a reason. Sometimes you'll bleed and theres very good reasons to stick with tried and tested.
#4 - It's easier to make it simple to get up and running when you have that from the start or early on, and working with techs that make that easy. Not so much when you're inherited a lot of legacy, some of it you don't even understand.
For what it's worth, MS make some decent products, so it's hard to entirely slate them but I imagine the GPs opinion that they could be doing things a lot better is also true, just some of the points were kinda off base imo. If anything.
Microsoft is the complete opposite of Facebook's "Move fast and break things". And that's a good thing, in a lot of ways. When entire companies (industries?) are dependent on you: slow & steady to get it right is much, much better than moving quickly to integrate the newest technology.
Sure, it's "move slow and break things". As judged by my experiences with most Microsoft products over the last twenty years, and reinforced by my current experience with Windows Azure's bizarre engineering choices and instability issues (the team to which the OP was assigned).
I drive an MRI scanner or 2 that are built on windows 2000. It's so very painful that modern scanners use such old OSs. The OS is masked from the user, but as soon as you try to do something complex (real complex, like getting images onto a memory stick) you have to use a series of crude hacks to get an explorer window up, then work around the disabled functions to get data off the scanner without using the network port.
Heh, that reminds me of all the bad scanner software I've ever dealt with in my time, and wondering how dead inside that person truly must be to have had to write it in the first place.
Granted I don't work at Microsoft so I don't see their internal code. I have worked a bit with their .NET and older Visual Studio suites, and found that their documentation there was probably some of the best I've ever seen (better than Analog Devices, which I've used as a hardware documentation standard for a while). MSDN is a fantastic resource, and is extremely well organized (or was 10 years ago, I imagine it hasn't changed a ton since then).
And I more meant that they have to stick with technologies that they know work for two reasons: legacy & reliability. If Microsoft changes something within their legacy code, that could cause absolutely massive problems around the globe. If reliable features in their code breaks, same problem.
Internal documentation of functionality/features/whatever and documentation of externalized API's & protocols meant to be consumed by any johnny come lately are two separate beasts. If the QA/validation process that is applied to external documentation was also imposed as a requirement on internal documentation then nothing would get done.
He mentioned copy/pasting code and skipping reviews were popular things to do. The first one is definitely a sign of poor code quality, and the second isn't as definite but is surely a practice that makes room for poor code quality.
I'd say without documentation any code loses quality.
I'm not talking about giving a manual for every piece of code you write, but any code that will be used by others (specially in big companies) should be well documented.
If good code is not documented, it will probably cause the same amount of trouble for people using it, than a bad piece of code.
People often forget that their code normally ends up outliving them.
People also often forget that a lot of code doesn't survive the week, which is common in an agile setting. Documenting code is something you do when you know it can live for awhile.
Also, if the focus is on maintainability, the person documenting the code shouldn't be the same person who wrote it, who already has biases on what is obvious or not. Rather, it should be someone with access to the author(s) who can ask questions and document what they didn't get right away.
Interestingly, many companies including mine are dependent on Facebook and their APIs. They do move fast and break things, and we feel the pain of it practically every day.
All these things are fine, except for the suggested Microsoft culture of not knowing what's out there, what the competition is doing. If you don't at least keep one eye on what's going on, then you're not going to see other people's mistakes and learn from them.
It's curiosity that's important, not new stuff. We read HN because we're curious, and we don't want to miss anything. We don't get stuck on old inferior tools (at least not at home) because we like to tinker and explore. You can judge people, to some extent, based on their reading, their tools, how informed they are about the competition. Programming is like surfing a tidal wave of information and change; you don't improve by sticking your head in the sand.
(Yeah, that last sentence is a tidal wave of mixed metaphore tossed like a salad.)
Programming is more like surfing an infinite amount of tidal waves of information change. Every wave is different, but ultimately they're all just waves regardless of how much people argue which is superior to the other.
Point being, when you're 35 and an expert in your field, you probably need to spend less time learning what the cool kids are up to as opposed to when you're 23 and learning your field and everything you learn is new.
That doesn't mean that you can let yourself not be current, but if your future plans are to work 12 hours per day then go home and read HN at night, I pity your wife and family prospects. :p
Yes. And it's not just learning new stuff. It's important to just keep learning stuff.
It's shocking how many of my team mates haven't even heard about Scheme, let alone tried to learn it. And yet learning that language (I'm still working on it) is revolutionising the quality of my code. There's a lot of important stuff that was developed years ago that's just as important as stuff that's coming out today.
This is a very accurate statement. Only developers with several years of battle-tested, crunch-time experience know the dangers and headaches of trying to fix something that was implemented because it was 'new' and 'cool'. Sometimes new stuff is awesome. Most of the time, it's just new.
I like to avoid being an early adopter for anything business or work related because it is so much easier to use things when there is an already established user community who has found and fixed/worked around most the major bugs.
I didn't know ASP.NET was considered something in the same level of winxp or word 2003 at the point - maybe the original ASP. Unless that's not what you were implying.
This. Joy to the European work ethic. I haven't worked past 5 for the last 10 years. I refuse to do unpaid work and overtime. Would your employer bill you out for free? Nope.
Employers hand out bonuses to incentivise enployees to stay. Employees do unpaid overtime to incentivise employers to keep them. My point is that they are fundamentally similar concepts. It's great that you're in a position where your employer wants to incentivise you to stay around by giving you bonuses yet you don't need to do overtime to keep your job. I'm also in a similar position. Some people aren't, and this has nothing to do with European work culture or work ethics. It's supply and demand.
I agree if you're working in some drone farm. Without a personal stake, why do people feel enthusiastic about following orders that keep them locked up at work all day? I understand that there may be coercion, like the threat of being fired, but if you're just writing software for your company, where does the enthusiasm for long hours come in? I'm freelance, and I love working on my projects. I often work long hours. I hardly stop. But I have a 100% stake in what I do and generally choose projects I believe in, like endangered language preservation or stuff that I find intellectually stimulating. Why would someone want to work at Microsoft or Google past 6pm? Why do people give their souls to hives?
Even if you're not working at some drone farm you should probably take time to yourself to relax and spend time with your friends/family. I understand if you're freelance and you have deadlines and whatnot you'll need to work long/odd hours, but honestly you shouldn't have to kill yourself with work. I enjoy what I do and have a large equity stake in it, but I'm not going to burn myself out because "I love what I'm doing." It's not good for me, it's not good for my family, and it's not good for my work. If there is a tight, important deadline sure I'll work longer hours, but in most cases it's almost certainly unnecessary and definitely negative.
Or, more generally, there is more to life than one single thing. Some people let a single thing (or a very, very small number of things) define themselves, and it's a bad idea.
Think critically - how are you defined? If you asked the 5 people closest to you, how would they describe you? If they can't get much further than "good software guy", be careful.
Without some drive and enthusiasm about what you are doing those 9-5s could end up being a lot worse than the alternative of putting in some extra effort because you are really enthusiastic about what you are doing.
I totally agree. I only work past 6 if I came in late. Otherwise there are plenty of hobbies to catch up with. Mine is making a nice dinner for myself at the end of the day. In that way you also get more time to work on your personal/side projects or even contribute to open source.
I love my family, my health, and life more. Work, while important to me, isn't even near the top of my priority list. I work so that I can do the things and be around the people I truly care about.
My only real life regret is that I didn't realize it a bit sooner.
Plenty of reasons. Firstly, look at how society interacts. "What do you do?" is a frequent conversation starter with new people, and already pigeon holes us by our employment. That starts to build a sense of identity with our work.
Then there's the vicious reward cycle. Do something right with work and you're rewarded with praise, with positive feedback, with kudos. Do something wrong and... well you see where it's going. It's more subtle than how I train my dog, but not much.
And then the tech world is in awe to entrepreneurs and startups, where long hours and being defined by passion for what you do and it being the sole calling in life are the norm. You or I, older now I suspect (I certainly am) may look at it and shake our heads and think of the failed relationships we've seen (the same in any high-powered area of work), but for people without that view it's not easy. I had the same way of thinking as the OP, and even now I still get jealous of those who achieve much by having their work as their identity and aim in life.
And finally society again. There seems to be a growing expectation this is the norm and the right way, like the acceptance that single parent families are normal and a good way for children to be brought up (don't argue with the subject, think about how long that's been an accepted view). For ambitious, maybe insecure graduates starting out in work, that's a huge sense of competing to 'get to the top'. Why they're not sure, but it sure gives one an identity... or does it?
Sorry if I've offended, I didn't phrase that very well. I didn't mean you have to work late if you like your job. I meant it's a trade-off, and sometimes working late and giving up other things is worth it.
On the other hand, I had different experiences both times when interning at Microsoft.
Anyone that works or has worked at Microsoft should all end any "my experience" post with one sentence: your mileage may vary.
Microsoft is a gigantic company where team culture varies widely. Some may consider this a good thing, others a bad thing. I don't really care. I just call it a fact and as such "my experience at MS" posts are usually pretty meh unless the author him/herself realizes that their team's culture is probably extremely different (for better or for worse) from other teams' culture.
I think it's a pretty important footnote to include, that's all.
This is how MOST computer science majors spend their careers.
And I'm thankful they do. Most of the very large projects that act on an extremely large scale require that sort of day-to-day grind. The spark is important too, but great things are 1% inspiration, 99% perspiration.
Just look at the code studies. Open-source projects of great accomplishment like the Linux kernel have just as many hours (those hours are just distributed a bit more)
I know what the corporate norm is, but I do not care, because I live on planet hacker. My brain does nothing of any value before around eleven AM and its peak productivity kicks in around 2-3 pm. An 8-5 schedule would be a great way to waste my time and my employer's money.
Yea true. I'm just saying there are tons of things to be done even if it's not coding. I agree with you on the coding productivity but if you walked into a company the first day and said "Oh I'm just working 11 to 2 every day", they probably wouldn't like that too much.
> I actually was able to do some open source work with Codeplex
Nice, I guess people in your area had done this before and nobody was scared of sharing code. My experience wasn't so good.
I wrote some BizTalk VS-LoadTest extensions while contracting at Microsoft UK and battled for the best part of 3 months to get permission to share them on CodePlex.
While everyone agreed it was good for the company and the products and an all-round good idea to open source the code, nobody would put their neck on the line and give me written permission to do so. So it didn't happen.
Hey there, author of the post here. Thanks for supporting me, that feels good and I agree your points 100%.
I organized a "hackathon event" in The Garage for 2011 summer interns, maybe you have heard of it. I still push these sort of events and seminars that we all can more learn the outside world beyond the individual efforts.
- Literally any piece of documentation was always 1+ years out of date. Setting up a dev environment could take days when it should have only taken hours.
- A lot of my coworkers were over 35. Starkly different from my experience later at Google. Working past 6 was considered absurd, and a lot of people were perfectly happy just riding the Microsoft wave. There were plenty of engineers who had been at the company 12-18 years with only a single promotion or two.
- I actually was able to do some open source work with Codeplex
- Not a single person I worked with read HN or Reddit, that I knew of.
It's a bit depressing reading the post, but at the end of the day Microsoft was and is still an amazing place to work. I was paid well, the engineers are well taken care of, and the consumer offerings are still fun and exciting.
Although things were done differently than they are done in Silicon Valley, the difference is not necessarily bad, perhaps more eye-opening. This is how MOST computer science majors spend their careers. Not mastering MongoDB, collaborating on Google Spreadsheets, or posting things to HN, but using Windows XP, Visual Studio, and Microsoft Word 2003 on a 2008 Lenovo laptop. And MS is perfectly happy taking their money.