No there is not, in most companies. In most firms, if you try to be an "intrapreneur" while the middle manager to whom you report has to deal with typical corporate dreck, you'll break this "Law of Power" (Never Outshine the Master): http://www.youtube.com/watch?v=WMy8Tf-zCag Then you get fired for being "distracted" because the perception is that you care more about your career goals than your manager's. (Of course, this is usually true for most people and there's nothing wrong with that, but one can't be brazen about it.)
There are benefits to working in larger companies, but the idea that one can just decide one day to recast his job description to "intrapreneur" is laughable for most people. The people who have jobs that would allow that (in small or large companies) don't need to fall back on some templated concept.
"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 hindsight is 20/20.
It was a risk for them to post an article that could be considered critical of the mothership.
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.
That was certainly my experience in devdiv. People barely seemed to realize that a world outside the Microsoft ecosystem still existed. I have forgotten the details, but there was a meeting once where I suggested we look at some open source project for ideas about solving the problem we were working on... possibly LLVM?... in any case the response was completely blank, like, what possible relevance could that have, why are you wasting your time thinking about some weird open source thing in the first place? It was a really strange attitude to encounter, as someone who had never even used Microsoft tools before going to work there.
Matches my experience as well. I was there for nearly a decade, with several years in windows client, and I was always amazed that nobody there ever seemed to learn anything outside of microsoft tech. It's stunning how there are two almost completely separate worlds. Just taking web development as an example, outside microsoft, there's this whole culture of github, ruby, python, node, various open source frameworks, gems/eggs/npm. If you're a web dev outside of microsoft and you are completely ignorant of all this stuff, you're stunted. Whereas inside of microsoft, most people will stare at you blankly if you mention ANY of that stuff.
Mind you, none of this says anything about developer competency. There's no shortage of great developers at microsoft. They're just very insular and good at using microsoft tech and that's it. Oh, and these great developers are obviously hamstrung by the fact that microsoft isn't in the business of making great software, but that's a whole other rant.
(Hi there, I'm the author.) Scott, you are a PM manager, you have to hear about it. What I am pointing out is individual contributors (SDEs and SDETs) mostly have never heard of these. Even the senior ones, I am pretty sure.
My guess is this is because of the separation between engineers and product managers (PMs). Engineers are supposed to focus on development and PMs (and more businessy folks) are supposed to focus on the competition.
Legal departments also get in the way of contributions to open source. "We don't want any of our proprietary code to end up in that library" is a common theme found among legal teams that paint with too-broad of brushes. I am currently experiencing this.
Not to mention Microsoft is terrified, and I mean terrified of any open source code accidentally getting copypasted into some Windows or Office. A team I worked on there had to indirectly use linux and there was literally one designated person who was allowed to have a linux machine, and the machine had to be set up by a contractor whose job it was to ensure it was scrubbed of any source code before being handed over to the one guy who was actually allowed to touch it. I swear, you could make the lawyers jump a mile by sneaking up behind them and whispering "GPL"
He sounds like someone who is significantly lowering his standards. Seems like working at a big corporation is killing his spirit and energy. That is just sad.
The real world is an awfully broad place. There are plenty of places you can go where mediocrity is not encouraged, people do more than 2-3 hours of real work a day, they're passionate about their work and curious about outside developments, and your specialties do matter. If you want to work there and find that you're not able to do that in your current job, change your job.
You tend to get the life you believe you deserve - if you're willing to put in the leg work to make it happen, you can very easily reconfigure the world around you to something you're satisfied with.
Yea, I had a similar experience at a Wall Street firm to the OP. However, my conclusions were different. My advice to this guy is the same advice I had for my younger self back in 2009: "Get out while you still can!".
I wrote a blog post reflecting on my experience. Here is the relevant snippet:
Working at the bank was a huge change from the rest
of my life. The primary focus of my job became my
paycheck. Technology decisions were made for me, by
external committees. I was expected to follow all sorts
of processes and procedures. I was expected to become
a conventional programmer. I found myself building
products that had an unclear end-user.
I did learn things there, too. I learned what it was
like to work with engineers on a daily basis. I learned
a lot from my managers and colleagues, many of whom were
just astoundingly intelligent individuals. I learned how
big companies operated. But mostly, I learned a lot about
myself.
I learned that work meant more to me than a paycheck.
Work should be about solving problems, helping people,
and creating enduring value. Money is important, but
it wasn't what attracted me to technology in the first
place. And that's why I knew I had to leave that firm.
Started a company... failed. Came crawling back to the corporate world, regretfully; it hasn't been all bad but I've experienced most of your pain points.
I work at a big enterprise and yes, lots of things are familiar. Then again, I work on a project that's about 5-8 years late, and migration will finally be completed next week. People are figuring out documentation matters, and large parts are being properly documented and/or rewritten. There are corporations where people get it.
This bothers me. Multiple companies I've worked at have made me want to work on some sort of Code Quality team to go in and rip apart and rewrite entire sections of shitty code that won't make any immediate noticeable impact. The business impact it will make is next time another programmer has to touch that code it'll take them a tenth the time to understand, use, or extend it.
I dunno. Numerically that seems right - Google has 30k+ employees, and I definitely spend 95% of my time interacting with less than 1% of them.
But I've found that the breadth of interactions in that remaining 5% reaches across a wide expanse of the company. I work in Search Features. I have friends and professional contacts not just in Features, but also in Ranking, Maps, Glass, Google+, GFiber, Chrome, Android, AppEngine, YouTube, Research, Brain, CourseBuilder, Doodles, legal, and PR - not to mention a whole bunch of infrastructure teams and research projects that I can't tell you about.
And I've found that one's effectiveness in a big company is to a large extent dependent upon the breadth of your internal professional network. The folks who seem to shoot up and don't get pigeonholed into just writing code for their manager are the ones who have a wide network and always seem to know somebody who can get this thorny task done.
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 my projects. The only mention I could find of said software was a slide saying "This software has no documentation, here is a link to .NET decompilation software".
One surprise I can add is that Windows does not have an internal package management system. I expected to see a apt-get like tool. Instead there are various download.com like sites hosting installers.
Windows has a package management system (Windows Installer). It's crufty and quirky and gets abused (package files that are just wrappers around standalone installer programs, for example) but is generally pretty usable. I've always wished more Windows developers would use it.
Hey there, author of the post here. By "documentation" I mean docs for millions of lines of code written for the infrastructure running our systems internally and not shipped to public. These are dark areas that one can't easily find documentation in corporations, IMO.
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.
Publishing something that HR/PR can consider slander under your real name while being junior developer is not a recipe for stable employment. These guys tend to freak out over minor stuff like that.
Lets hope it does not have negative consequences.
Otherwise familiar - these companies are like supertankers - move slowly and few people are empowered to make meaningful decisions and contributions. Worked for a few years in a telecom ... it was meetings, meetings, meetings, signing contracts with delivery dates before the day they we signed, absurd promises, turf war and NIMBY.
From now on - 20-50 person companies for me only, unless I am at the very top.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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 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.
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)
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.
> 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.
| Publishing something that HR/PR can consider slander under your real name while being junior developer is not a recipe for stable employment. These guys tend to freak out over minor stuff like that.
Agreed. This is not something you write publicly WHILE working for the company. I know his intentions weren't to slander the company that is paying him, but it will most likely have bad consequences within his team.
I do think there's a different between opinion of a manager who's been working for ten years and a new-grad who's just had his first job for eight months.
>Publishing something that HR/PR can consider slander under your real name while being junior developer is not a recipe for stable employment. These guys tend to freak out over minor stuff like that.
That's to me the equivalent of saying: "sitting on the front of the bus, as a black person, is a recipe for trouble".
Not in the sense that it's racist, of course.
But that it trivialises a problematic situation, and asks for caution from the (potential) victim.
It's not what he did that's problematic, it's the very notion that a company would consider firing someone over sharing something as innocent and truthful as this.
And that we should somehow "accept it" and just "be cautious" not to have this happen to us.
Even if someone is going to be brave and try to change things, it's good if they know what they're getting into, rather than just blunder into it. Although, blundering might have it's positive points in this scenario.
Okay - I will elaborate a bit. Fortune 500 companies tend to be trigger happy lately and not backing their employees. You saw what happened with the #dealwithit guy. And that was for sentiment the whole company backs because it just happened to be true.
If Snowden did not leave the US so fast we would all agree that this would have been stupid. Not the leak but not taking the basic precautions.
Also he is not having personal issues or being harassed from what I read - so the situation is not a civil or worker's right problem that would require that kind of whistleblowing.
It is a rant with proper place on thedailywtf with good privacy protection.
Getting fired from a job that sounds as miserable as his description depicts seems like a good thing to me. It's not like he'll have trouble finding a new one.
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.
To be fair, the job of the academia is to do research. Coding is just a means to an end. If on the other hand, you're distributing your code or it's intended as an ongoing project, then good comments and architecture are important (Disclaimer: I'm a PhD student).
There's still an opportunity cost to writing documentation. How many other people will work on that code? 2-3? 12? 100? 2000? If it's 2-3 or even a dozen, you're better off explaining in person how it works, while if it's 2000 there better be some persistent written documentation.
It probably also doesn't help that the number of people who look at a given piece of code follows a power law, which means that when you're doing the looking, you are probably looking at a piece of code that many other people have looked at. Everybody remembers the terrible mess that they had to puzzle out without any documentation. Most of the time they don't remember all the little experiments they did that never saw the light of day, where time spent documenting would just be wasted.
If the product you're working on is a long term project of the company, it's likely you'll leave before it's over in which case there will be a future person who'll have to figure out your code.
In such a case, documentation is essential as otherwise this person would have to contact you after you've moved onto other projects and may have forgotten the intimate details of the code making things tricky.
That's why you have at least two people work on every part of the code, ideally together, but you could easily arrange a hand-off. Solo-developer projects are bad ideas for other reasons, notably that if you get hit by a truck the company is SOL.
Hey there, author of the post here. Thanks for pointing that out, this is supporting and it feels good. I was also thinking about the academia path before my graduation.
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.
Out of curiosity, which division were you in? Given the size of Microsoft, I'm not surprised there would be some major differences between different teams.
How long ago? Do you think it was different when you were there, that it was better in your group specifically, or that it's better in most other groups?
I was in Online Services (aka Windows Live) about two years ago. Some groups are obviously better than others, that can be said for any company. I think the problem here is that the author does not realize that unlike college, corporate world requires you to be a bit more proactive. Large companies may suffer from bureaucracy but on the upside, they have vast resources and smart/accomplished people you can tap into if you check your ego at the door, don't expect everything handed to you in a silver platter and tone down the poisonous attitude.
I'm actually in the windows services group now (no longer called Live). I can confirm that the author's experience is quite different from mine. Papercruncher's assessment is pretty much spot on.
Given there are 10k's of employees here in Redmond, it's not surprising that different groups are, well, different. I've noticed that rather large subcultures emerge in different areas. Once you're in the door, there's encouragement to move and find your "fit". All this blog post taught me is that I probably wouldn't be a good fit for Azure :)
I got that encouragement too, after I realized I was never going to be happy at devdiv, but I still don't understand how it was ever supposed to work. It's not like you get special visibility into the working conditions you would encounter in some other group just because your badge will get you into their building. I just said "fuck it" and quit, and I've never regretted that decision.
This seems extraordinarily unfair to the author. Being "proactive" can't retroactively make your team write documentation, make them care about engineering quality, or stop them wasting time in meetings, it's just a lame, corporate-speak, equivocation; the kind used by managers in reviews, and nowhere in the real world.
Kids fresh out of college may need to adjust their expectations to the real world, but most of his complaints are legitimate problems if true, and accusing him of having a "poisonous attitude" for raising them is exactly the kind of oppressive, censorious behaviour that allows such mediocrity to exist.
I worked at Microsoft as well (and even on the Azure team as little as 2 years ago) and I agree, none of this sounds like any of the teams that I worked on. I'm guessing it has more to do with his perception as a junior dev suddenly working on a large team than with reality.
I think on a large corporation like Microsoft, both your cases can happen at the same time. The OP wouldn't blatantly lie and I assume you are not lying too...
This huge disparity between teams are normally a sign of very big management issues.
which is why blogging this is dangerous for him. First off, it his team reads it what will they think? He is inadvertally calling out problems with his management team and got a lot of exposure.
Hey there, author of the post here. Yes I believe there are different realities in Dev and Test organizations and this may be the pure source of my experience (in both positive and negative aspects). Thanks for pointing that out.
I have a gut feeling that he works as an SDE in Test (SDET). I have been through the same experience in my first 2 years. SDETs go through a very different experience as compared to a PM or SDE at Microsoft.
Hey there, author of the post here. Yes I am an SDET but what does this change? Are SDETs supposed to go through all this experience? Why nobody is fixing this? So if people are escaping from being a Test engineer, what can we infer about current test engineers?
I tend to agree with your post as I have been through what you are going through. I still regret taking the SDET role. In general SDETs do a lot of janitor kind of work. Cleaning up after the Devs and PMs. At the end of the day what everyone cares is that you have tested everything and not how you do it. I used to do a lot of system admin kind of work i.e. setting up machines, installing OS, running scripts, running existing test suites, etc. instead of writing new tests or new test frameworks. I am afraid this will take a long time to change. The only thing we can do now is move away from the SDET role. I can't guarantee if it'll be any better but it won't be as worse as being an SDET.
I spent 3 years as an sdet; loved it! Know for sure that my dev skills were superior to the senior sde's. know this coz I wrote their code on more than one occasion.
Been at msft twice - first team was shit, second was awesome. Impossible to make blanket statements, the org is just too big.
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.
Thank you for posting. I think you will inspire a lot of younger devs to seek more meaningful employment than working for big corp. However I fear that you will lose your job over this post.
I understand his experience. I've been mainly, (70% of the time), a third party Windows developer and admin for the last two decades and have spent thousands of hours working with and talking to Microsoft folks. Even have a few family members that work for the corporation.
NIH: Many Remondites live in the "bubble" where technology from the outside doesn't exist or doesn't matter. (It reminds me of the hard core Republican base.) This extends to much of the user base as well. There is a strong denial of OSS and there used to be taunting of Apple. (Until the iPhone kicked the smartphone market in gear.)
Future: Redmond has some serious issues to deal with: dysfunctional management, growing OSS usage, rejection of Win8/Xbox One and how to get people to use Azure when it's known you are the NSA's bitch.
hn works better without this kind of snark. I'm sure the "hard core Democratic base" believes most of what they read on the Daily Kos, too. Almost everyone has a bubble around something in their lives.
As others are saying, Microsoft is a very large company with a great deal of variance in the quality and maturity of teams. I wouldn't consider this description representative.
Azure is still a comparably new team, so I'm not surprised if it is still sorting out its processes. I've hear similar descriptions of Bing teams, and other "startup" divisions in the company.
But there are definitely some brutally effective teams there that far outshine any other non-Microsoft team I've ever seen.
Good luck. I hope this was not a mistake to publish, but it is definitely true of ALL jobs, not just developers or tech in general. I have noticed that it usually has to do with people being greedy of their knowledge and wanting to be indispensable. However, many of us have a choice to contribute to this and other places where we can share info as you said in your post, so thanks.
It is fortunately not true of all software jobs; if it were, I would have changed careers a very long time ago. Perhaps I have been lucky, but my experiences in small companies have generally been much, much better than what the author describes.
You know, you are right about that. I think that you are right about there being some small companies that are very good and some developers that are excellent at documenting code, sharing knowledge, etc. All software dev companies should probably require Code Complete as regular reading and sharing info should be encouraged as well.
Those are good things to learn. All of them correspond to my own experiences in large companies; none of them are specific to Microsoft. He is fortunate to discover this early, with what sounds like a fairly minimal degree of trauma, so that he can either learn to deal with it or learn to avoid such environments.
I'll never work for such a company again, that's for sure! Been through it three times and that's enough to be certain.
I can't comment on MS, but I can certainly tell you that not all large companies work that way.
Some points just don't apply - I happen to be lucky enough that I do work with passionate engineers, manage to get about 5 hours of coding done, and actually look at reasonably decent documentation.
And some things are as they should be. Your "specialty" rarely matters that early in your career. Most of the things mentioned (create iOS app, know MongoDB, etc.) are things that I'd expect a good developer to pick up as needed. Working as a software engineer is about being able to think logically, not mastering a particular subset of skills.
And yes, latest software is frowned upon. You'll know why once you've been on a project that went completely off the rails right before finish just because somebody needed to upgrade the compiler. Those are things you plan for. You test the new software extensively, and see when you can best absorb the inevitable cost of switching.
"Expect no documentation in corporations"
TechNet has so many valuable articles! It helps me every day to figure out the issues I have without having to hire an expert;-)
This is one of the things that has always bugged me.
I've had my share of work in a-large-company-i-shall-not-name. In my experience, given higher tiers that are receptive enough (read: people with technical backgrounds and some technical experience -- not necessarily glorious, even some QBASIC hacking is ok) and team members that are not mediocre, this stuff can be helped. Even in large companies. Not in all departments, not in all teams, but it can be different -- although the technical challenges involved in doing it "right" are insignificant compared to the non-technical ones.
Most of it seems to stem from the fact that, while large companies are very eager to enforce non-technical compliance (sometimes to unhealthy extremes, where they value conformance over performance), technical discipline is not as eagerly enforced. The same people who, in virtue of their hunger for promotion, would ship anything that compiles and seems to work, will tolerate any amount of crap. If enough team leaders, product managers, department heads and, in general, enough people who are not directly responsible for code they write, regularly contribute mediocre technical solutions, no one will ever get sanctioned for mediocrity, just for outright failure.
That being said, I would personally fire any manager responsible for the following:
> Expect no documentation in corporations. I have seen the knowledge inside the company is mostly transferred by talking and hands-on sessions.
If this happens, things are fucked up beyond recovery. If a company can afford to budget weeks and weeks of paperpushing for approving the first draft of the approval form for the architecture, they can afford extra time for proper documentation. When this happens, it's often a symptom of middle management wanking it until the upper management begins thrusting the hierarchical cock down their ass, and then immediately raining all responsibility down on the technical layers, which cannot rain it on anything else.
I can't claim that the teams I worked in had brilliant, completely up-to-date documentation, but it was good enough that newcomers had to begin pouring questions only when they actually struck tough code for the first time. In exchange for that, we treated blatantly missing or out-of-date documentation like any other bug -- we had timeframes for fixing it and people who were being paid to do it. I never had anyone from the upper layers ever complain about it. They were reluctant at first, but then, when the new employees who were handed over to our team were up to their necks in code after two weeks, whereas their equally recently-hired colleagues were still attending training sessions, no one had any chance of unhappiness anymore.
> 2-3 hours of coding a day is great.
2-3 hours of coding a day, for everyone in the team, every day of the week, is something the team leader should be strangled for. Slowly. In several stages. Just before moving to the micromanagement-obsessed higher layers.
Non-technical/upper-management hated me for it, but every Monday I screamed, yelled and kicked and any necessary, but unproductive bullshit they had for us was scheduled either on Monday, or on Friday. Technical meetings were always scheduled at least one day in advance (well, whenever possible, but it rarely wasn't).
At the end of the week, one day was definitely wasted, but I made it a goal that we get at least one day a week when we can do nothing but code. If the people who like meetings can get a day -- fuck, can get every day of the week -- when they can have meetings from the first hour of work to the last hour of overtime, coders deserve a day where they can do nothing but code. Yes, it results in people hating you. It also results in them not being able to do squat about it.
> The world outside is not known here a lot. [...] It’s not common here. I am surprised that no one I met in Windows Azure team heard about Heroku or Rackspace, which are direct competitors. That’s acceptable,...
285 comments
[ 4.6 ms ] story [ 76.0 ms ] threadThere is always being an intrapreneur. People are people and can be influenced. It isn't easy.
No there is not, in most companies. In most firms, if you try to be an "intrapreneur" while the middle manager to whom you report has to deal with typical corporate dreck, you'll break this "Law of Power" (Never Outshine the Master): http://www.youtube.com/watch?v=WMy8Tf-zCag Then you get fired for being "distracted" because the perception is that you care more about your career goals than your manager's. (Of course, this is usually true for most people and there's nothing wrong with that, but one can't be brazen about it.)
There are benefits to working in larger companies, but the idea that one can just decide one day to recast his job description to "intrapreneur" is laughable for most people. The people who have jobs that would allow that (in small or large companies) don't need to fall back on some templated concept.
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 hindsight is 20/20.
It was a risk for them to post an article that could be considered critical of the mothership.
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.
Mind you, none of this says anything about developer competency. There's no shortage of great developers at microsoft. They're just very insular and good at using microsoft tech and that's it. Oh, and these great developers are obviously hamstrung by the fact that microsoft isn't in the business of making great software, but that's a whole other rant.
Uh, this is Microsoft, they may have a slightly more close-minded view of the open source movement than, say RedHat or Google, or hell, even Oracle.
http://arstechnica.com/business/2012/04/linux-kernel-in-2011...
Legal departments also get in the way of contributions to open source. "We don't want any of our proprietary code to end up in that library" is a common theme found among legal teams that paint with too-broad of brushes. I am currently experiencing this.
Edit: Unless he is being sarcastic?
The very fact that there is so much doubt means it is not sarcastic. Or it is exceptionally poor writing.
You tend to get the life you believe you deserve - if you're willing to put in the leg work to make it happen, you can very easily reconfigure the world around you to something you're satisfied with.
I wrote a blog post reflecting on my experience. Here is the relevant snippet:
from "What One Does", http://www.pixelmonkey.org/2010/10/16/what-one-does> It is not what you do, it is what you sell.
This bothers me. Multiple companies I've worked at have made me want to work on some sort of Code Quality team to go in and rip apart and rewrite entire sections of shitty code that won't make any immediate noticeable impact. The business impact it will make is next time another programmer has to touch that code it'll take them a tenth the time to understand, use, or extend it.
The first thing he should have learned about Microsoft: every team is almost completely separate.
On average, at a big company, you're going to spend 95% of your time interacting with less than 1% of the employees.
But I've found that the breadth of interactions in that remaining 5% reaches across a wide expanse of the company. I work in Search Features. I have friends and professional contacts not just in Features, but also in Ranking, Maps, Glass, Google+, GFiber, Chrome, Android, AppEngine, YouTube, Research, Brain, CourseBuilder, Doodles, legal, and PR - not to mention a whole bunch of infrastructure teams and research projects that I can't tell you about.
And I've found that one's effectiveness in a big company is to a large extent dependent upon the breadth of your internal professional network. The folks who seem to shoot up and don't get pigeonholed into just writing code for their manager are the ones who have a wide network and always seem to know somebody who can get this thorny task done.
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 my projects. The only mention I could find of said software was a slide saying "This software has no documentation, here is a link to .NET decompilation software".
One surprise I can add is that Windows does not have an internal package management system. I expected to see a apt-get like tool. Instead there are various download.com like sites hosting installers.
Lets hope it does not have negative consequences.
Otherwise familiar - these companies are like supertankers - move slowly and few people are empowered to make meaningful decisions and contributions. Worked for a few years in a telecom ... it was meetings, meetings, meetings, signing contracts with delivery dates before the day they we signed, absurd promises, turf war and NIMBY.
From now on - 20-50 person companies for me only, unless I am at the very top.
- 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.
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.
(Yeah, that last sentence is a tidal wave of mixed metaphore tossed like a salad.)
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
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.
#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.
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.
[Edited to fix redundant sentence].
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.
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.
I suggest the OP just fire up the MSDN.
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.
Time is money.
It is absurd. Experience teaches you that.
There's a world out there for you to enjoy, and many people fought hard for workers rights so we don't have kill ourselves over work.
I don't expect one. My basic salary is what I expect.
The things that make me stay at a company isn't the carrot dangled in front of me like some circus animal who needs to do their performance.
People are too grateful for jobs. Employers use this to enforce servitude on people under terrible terms and people just lap it up every time.
I'd rather sleep on the street than sell my soul.
My only real life regret is that I didn't realize it a bit sooner.
It is an extremely difficult thing to accept that one should not think of one's identity and aim in life by their employment, isn't it?
It really isn't. Why would you even begin to think in that in the first place?
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?
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.
Life is way too short to be one-dimensional.
Hi, if you don't mind, I am going to use this citation a lot.
I understand the benefit of hard work but I see too much youth wasted on free labor given to corporations.
...on the other hand, I think 10 AM - 6 PM is a pretty reasonable work day.
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.
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 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.
Thanks for comment!
I'm shocked they hadn't been "renewed" by "Carrousel". Or were they runners?
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.
Agreed. This is not something you write publicly WHILE working for the company. I know his intentions weren't to slander the company that is paying him, but it will most likely have bad consequences within his team.
The truth can not under any reasonable definition be considered slander.
"truth serves as an affirmative defense to an action for libel or slander"
That's to me the equivalent of saying: "sitting on the front of the bus, as a black person, is a recipe for trouble".
Not in the sense that it's racist, of course.
But that it trivialises a problematic situation, and asks for caution from the (potential) victim.
It's not what he did that's problematic, it's the very notion that a company would consider firing someone over sharing something as innocent and truthful as this.
And that we should somehow "accept it" and just "be cautious" not to have this happen to us.
If Snowden did not leave the US so fast we would all agree that this would have been stupid. Not the leak but not taking the basic precautions.
Also he is not having personal issues or being harassed from what I read - so the situation is not a civil or worker's right problem that would require that kind of whistleblowing.
It is a rant with proper place on thedailywtf with good privacy protection.
All the more reason to speak his mind rather than try and feign some sort of loyalty to the man, which will never be returned.
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.
See, it's easy to ship responsibility on either side, with the exact same line of reasoning.
It probably also doesn't help that the number of people who look at a given piece of code follows a power law, which means that when you're doing the looking, you are probably looking at a piece of code that many other people have looked at. Everybody remembers the terrible mess that they had to puzzle out without any documentation. Most of the time they don't remember all the little experiments they did that never saw the light of day, where time spent documenting would just be wasted.
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.
Given there are 10k's of employees here in Redmond, it's not surprising that different groups are, well, different. I've noticed that rather large subcultures emerge in different areas. Once you're in the door, there's encouragement to move and find your "fit". All this blog post taught me is that I probably wouldn't be a good fit for Azure :)
Kids fresh out of college may need to adjust their expectations to the real world, but most of his complaints are legitimate problems if true, and accusing him of having a "poisonous attitude" for raising them is exactly the kind of oppressive, censorious behaviour that allows such mediocrity to exist.
This huge disparity between teams are normally a sign of very big management issues.
Honesty should be encouraged specially in big environments, since it finds the pains on the middle management that normally does not show up anywhere.
VAST difference in quality between the two disciplines.
For others: SDET: Software Development Engineer in Test
http://programmers.stackexchange.com/questions/44623/microso...
Been at msft twice - first team was shit, second was awesome. Impossible to make blanket statements, the org is just too big.
http://blogs.msdn.com/b/eric_brechner/archive/2011/05/01/tes...
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.
NIH: Many Remondites live in the "bubble" where technology from the outside doesn't exist or doesn't matter. (It reminds me of the hard core Republican base.) This extends to much of the user base as well. There is a strong denial of OSS and there used to be taunting of Apple. (Until the iPhone kicked the smartphone market in gear.)
Future: Redmond has some serious issues to deal with: dysfunctional management, growing OSS usage, rejection of Win8/Xbox One and how to get people to use Azure when it's known you are the NSA's bitch.
hn works better without this kind of snark. I'm sure the "hard core Democratic base" believes most of what they read on the Daily Kos, too. Almost everyone has a bubble around something in their lives.
Azure is still a comparably new team, so I'm not surprised if it is still sorting out its processes. I've hear similar descriptions of Bing teams, and other "startup" divisions in the company.
But there are definitely some brutally effective teams there that far outshine any other non-Microsoft team I've ever seen.
I'll never work for such a company again, that's for sure! Been through it three times and that's enough to be certain.
Some points just don't apply - I happen to be lucky enough that I do work with passionate engineers, manage to get about 5 hours of coding done, and actually look at reasonably decent documentation.
And some things are as they should be. Your "specialty" rarely matters that early in your career. Most of the things mentioned (create iOS app, know MongoDB, etc.) are things that I'd expect a good developer to pick up as needed. Working as a software engineer is about being able to think logically, not mastering a particular subset of skills.
And yes, latest software is frowned upon. You'll know why once you've been on a project that went completely off the rails right before finish just because somebody needed to upgrade the compiler. Those are things you plan for. You test the new software extensively, and see when you can best absorb the inevitable cost of switching.
And I love the Microsoft Test Lab Guides (http://social.technet.microsoft.com/wiki/contents/articles/1...) which is continuously updated.
I've had my share of work in a-large-company-i-shall-not-name. In my experience, given higher tiers that are receptive enough (read: people with technical backgrounds and some technical experience -- not necessarily glorious, even some QBASIC hacking is ok) and team members that are not mediocre, this stuff can be helped. Even in large companies. Not in all departments, not in all teams, but it can be different -- although the technical challenges involved in doing it "right" are insignificant compared to the non-technical ones.
Most of it seems to stem from the fact that, while large companies are very eager to enforce non-technical compliance (sometimes to unhealthy extremes, where they value conformance over performance), technical discipline is not as eagerly enforced. The same people who, in virtue of their hunger for promotion, would ship anything that compiles and seems to work, will tolerate any amount of crap. If enough team leaders, product managers, department heads and, in general, enough people who are not directly responsible for code they write, regularly contribute mediocre technical solutions, no one will ever get sanctioned for mediocrity, just for outright failure.
That being said, I would personally fire any manager responsible for the following:
> Expect no documentation in corporations. I have seen the knowledge inside the company is mostly transferred by talking and hands-on sessions.
If this happens, things are fucked up beyond recovery. If a company can afford to budget weeks and weeks of paperpushing for approving the first draft of the approval form for the architecture, they can afford extra time for proper documentation. When this happens, it's often a symptom of middle management wanking it until the upper management begins thrusting the hierarchical cock down their ass, and then immediately raining all responsibility down on the technical layers, which cannot rain it on anything else.
I can't claim that the teams I worked in had brilliant, completely up-to-date documentation, but it was good enough that newcomers had to begin pouring questions only when they actually struck tough code for the first time. In exchange for that, we treated blatantly missing or out-of-date documentation like any other bug -- we had timeframes for fixing it and people who were being paid to do it. I never had anyone from the upper layers ever complain about it. They were reluctant at first, but then, when the new employees who were handed over to our team were up to their necks in code after two weeks, whereas their equally recently-hired colleagues were still attending training sessions, no one had any chance of unhappiness anymore.
> 2-3 hours of coding a day is great.
2-3 hours of coding a day, for everyone in the team, every day of the week, is something the team leader should be strangled for. Slowly. In several stages. Just before moving to the micromanagement-obsessed higher layers.
Non-technical/upper-management hated me for it, but every Monday I screamed, yelled and kicked and any necessary, but unproductive bullshit they had for us was scheduled either on Monday, or on Friday. Technical meetings were always scheduled at least one day in advance (well, whenever possible, but it rarely wasn't).
At the end of the week, one day was definitely wasted, but I made it a goal that we get at least one day a week when we can do nothing but code. If the people who like meetings can get a day -- fuck, can get every day of the week -- when they can have meetings from the first hour of work to the last hour of overtime, coders deserve a day where they can do nothing but code. Yes, it results in people hating you. It also results in them not being able to do squat about it.
> The world outside is not known here a lot. [...] It’s not common here. I am surprised that no one I met in Windows Azure team heard about Heroku or Rackspace, which are direct competitors. That’s acceptable,...