In 8 months at Microsoft, I learned these things
ahmetalpbalkan.com
ahmetalpbalkan.com
I've been working for over 20+ years now. During that time, I've worked at half a dozen large corps, a few medium sized ones, and a few startups. I've seen both great teams with great practices and bad teams with poor practices. One thing that I can say though: the size of the company didn't seem to have much to do with it. Even with my experience, I don't think I've seen much more than a thin slice of the variance in practices that is out there.
Note, I'm not saying that this guy didn't experience what he wrote about at Microsoft. But at a corporation that size, you'll likely find that different groups have different practices. This was certainly true at the large companies I've been at. Some teams were super-sharp, others were sloppy beyond words. Even if all teams at MS suck (which I doubt, but I will admit it's possible), this says nothing about how other companies operate and very little about how large corporations operate.
Word of advice: don't mistake the worlds you extrapolate inside your head for reality.
Can you just learn from his experience that he describes, and get over an inconsequential phrase at a tiny part of the post?
Even if it's not applicable "everywhere", it's a nice description of what he found in his parts of Microsoft.
Not to mention that as a senior engineer that's seen several companies (and had done contract work for others), it's pretty much spot on in general.
>Even with my experience, I don't think I've seen much more than a thin slice of the variance in practices that is out there.
Which is besides the point. What he describes it pretty normal stuff, going on all around:
1) companies not having much internal documentation for lots of their stuff,
2) not everyone being overly enthusiastic for coding,
3) code fixes that doesn't have business value are not very welcome,
4) people can mostly squeeze 3-4 hours of good coding a day, etc.
That's not some obscure practices, or some arcane rituals that only happen on a small slice of companies. Those are pretty much the norm all around.
Some companies might do better or worse in some aspects, but it's not like there are some alien practices or some novel ways to deal with software that are out there in companies and you have to explore very hard to find them... Even if they were, they would be so little spread that it won't matter.
>I can't wrap my head around the sort of arrogance and myopia that makes a 21 or 22 yr old think that he can describe an entire world from such limited experience.
Are you fucking kidding me? That's what 21 year olds do. Make strong statements and have strong opinions on their limited experience.
It's the myopia of not knowing this very basic fact, that I cannot wrap my head around.
Not all, i have the pleasure of working with some 20-22 year olds who would be very unlikely to make such a statement.
That goes without saying as the intended meaning for every* use of "everybody", "nobody", "every", "all" etc in normal conversation. Those are statistical qualifiers, not absolutes.
(*well, almost every -- which reinforces my point).
Actually, no. The post wasn't phrased as "here was my experience", and rightly so: there are lots of terrible engineering organizations, and many readers wouldn't hugely care about yet another such horror story. Rather, the post reads as advice that new grads learn early to be resigned to what they might otherwise perceive to be dysfunctional engineering. I think there's too much of that already, and it's frustrating to see a post advocating that.
Fwiw, I read it as a way of (plausibly) covering his ass if he was ever hauled in front of management about the post, not a way of overstating his experience. YMMV.
The way that reads in the paragraph makes it seem as though it was thrown in as an afterthought and that it applies as a separate statement on its own - unrelated from the 8 months. It's the only line that says anything about other companies. Maybe someone read his post, and said "hey, you know it's like that everywhere right?" Or, "Hey you know higher ups might not like you hating on us like that." And so he throws in a sentence to solidify the fact that he's not trying to single out Microsoft.
I have worked for a few different large organizations and have often faced the size excuse for being unorganized and ineffective. I personally feel it is a cop out, and self fulfilling prophesy once it becomes an accepted perspective, because then people stop trying to be better.
I have also worked in big organizations on kick-ass teams who are willing to fight uphill battles against "we are too big to change" attitude. Thats what made them awesome teams.
I have friends in almost all big companies and I discuss them about these issues a lot. Almost all of them agree that they are in a similar situation.
I know that even Microsoft is a huge world and NOT all organizations are the same. All organizations have their own culture so there's no common culture in the company I can describe. In a way this is good.
So the statement "Even if all teams at MS suck" would be really wrong. In addition to this, organizations get better and develop culture over time. Thanks for the comment.
Now I'm at a smaller company, and my quality of life has improved tremendously.
We also have a ton of specs, archived off over the last 15 years. Those can sometimes be quite useful.
Really? You have friends in almost all big companies?
There's a lot of truth in the points you mention, but even in my limited experience (six years at two companies, one very large and one pretty small), it's much more complex than you suggest. Many of these things were flat out not the case at both companies (e.g., the points about "the world outside"), some of them were absolutely true of both (2-3 hours of coding per day is common), and some were worse at the small company (e.g., documentation).
I'm with the parent: these issues have little to do with company size, but they do reflect the quality of an organization. In both environments I've worked in, to the extent that these issues were present, they were considered problems to be fixed, not something to be resigned about.
But that undermines the original point about big companies even more. Having friends at mostly big companies is not only not enough to generalize about big companies, but it provides no information about whether other companies struggle with these issues too.
I was reading this post as if he was not working for M$ anymore. Also, he might be safeguarding a future for him in small startup with the same attitude... if he is fine limiting his options so much, good luck.
As you get older, you'll find there's a stark difference between first & second-hand experience.
I like him already, If were Microsoft I _will_ hire him asap. He's the type of person who wants to make things better.
This isnt to say you can't make change. You just have to play work as a very strategic game of chess and, often, take risks most others won't/don't. I've done it and that is one of the only reasons I still play the game. I'm genuinely interested in making things better and pushing out the cruft.
The downside is that it wears on you. I generally get burnt out or bored after a couple years and look for something new to reset and challenge myself on. And as bad as this reads for Microsoft (really - were you surprised?) I don't think there's any other factual data to support Azure being a market leading product and these sort of indicators only solidify that position (garbage in/garbage out).
These types of perspectives are good for those who are considering the reality of working for these size organizations. Not because it's a guarantee that things will surely mirror what's been outlined, however it lends candidates a tool to ask questions which would be indicators of the reality of the work environment.
Kudos to the author.
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.
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...
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.
True anywhere. Lots of OSS is horribly documented. Documentation is not only hard, but adds debt that now must be maintained. No documentation is better than wrong documentation.
It is not what you do, it is what you sell.
Welcome to business (and life really). While selling styling changes is going to be hard, selling bug fixing, code changes to be more robust and easier to manage are easy sells. If changes will make it easier (aka cheaper) to add new features even the least technical business person will get it.
Not everybody is passionate for engineering.
Not everyone has the same engineering passion. I don't care that my new router with IPV6 gives me some large number of IPs, but I do get excited when I can integrate a new framework which makes my job easier.
It is all about getting shit done
This is life. Do you really think the small companies of the world don't care about getting shit done? The small companies of the world are often more concerned because they don't have MS Office level cash cows keeping them afloat.
Latest software, meh.
Because it often breaks shit and gets in the way of getting shit done.
* I spend most of my time trying to figure out how others’ uncommented/undoumented code work, debugging strange things*
Programming is mostly reading code. I don't feel like looking it up right now, but Clean Code references the study. Reading code is coding.
Well said - certainly the most valuable skill I've picked up post education and working for $BIGCORP is the ability to quickly read and understand other people's code.
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.
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.
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.
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:
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.
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.
Yes. Exactly. IMHO this is the factor that's responsible for at least 50% of corporate clumsiness.
> If this would have been my own company there would be tons of wiki pages.
Just having wikis won't help much. I worked at a company that had wiki, people were putting things there as an afterthought. I was total and complete mess. Lot's of information was outdated, duplicated, horribly messy but it still was something. There should probable be some person with sense of structure to prune those pages, nag people about details, construct some sort of tree from these splinters of information.
Corporation also had task tracking system. But it wasn't helping. It was used as afterthought to leave a trace that some work is to be done and some work was done. What's actually to be done was passed via face to face contact. Therefore noone cared about task tracking system and what's written there.
If you want to keep information, you have to use the system that stores it as crucial (only?) communication chanel.
Make a change to source, then you have to figure out where the wiki page is for it. Can't find the wiki page? Make a new one. What folder does it go in? Do you make a new folder? What if a page does exist, but it's wrong? Do you fix the whole thing? Just the part you added? Email the person who last updated it?
After 6 months it ends up being a tangled mess of insanity, and no one relies on it. You complain about outdated/indescipherable comments? Imagine that multiplied out. In fact, it's almost worse; at least with code you can try to think like a compiler and figure it out. Without code--yikes!
In the opposite direction.
Wiki documentation 99% of time: we have no documentation, nobody cared to write any, and we setup a barebones wiki app in the hope random people can write some documentation for us.
In my experience wikis are far from perfect and need regular gardening BUT they are vastly better than a shared folder or a sharepoint with a ton of word documents...
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.
"It is not what you do, it is what you sell" -- Capitalism -- welcome to America.
"Not everybody is passionate for engineering" -- You could probably find a place to work where everyone is passionate about engineering, but I sense that these places are uncommon and highly competitive.
"it is almost impossible to get 2 hours straight of coding for me. I spend most of my time trying to figure out how others’ uncommented/undoumented code work, debugging strange things..." -- That doesn't count?
"The world outside is not known here a lot." -- This is probably symptomatic of the time when Microsoft was the center of the universe. It's not true everywhere.
"Copy-pasting code can be okay. If somebody sees you doing this outside the corporations, you’ll probably get punched in the face. I’ve seen source files copy pasted across projects." -- In college, you have to show that you can do the assignment yourself. In the open source world, you have to be mindful of copyright and licensing. Inside a company, it's all the company's code, so there's nothing wrong with it. You don't have to prove that you can write it yourself.
"Almost 90% of my colleagues use older versions of Office, Windows, Visual Studio and .NET Framework." -- It's pretty common knowledge that that's true outside of Microsoft, but it's interesting to know that it's true inside.
"You are hired to do get something needed done. I was not expecting that. It’s hard to find a position in corporations matches what you love to do." -- Again, capitalism. You make things for other people, not yourself.
There's always a tension between competing priorities; the thrill of engineering something wonderful, the reality of being part of an organization made up of people, and the need to keep money coming in the door. A lot of things are just facts of life, but an environment can also become toxic. At that point you have to leave.
Source Code documentation seems better than most companies I've worked at, and Code Reviews are not skipped. The source control system won't allow you (without overrides) to commit without review and approval for most projects.
We also don't like committing hacks just to get something to work. It is generally understood that a //TODO -- will clean up later, or promise to do so will almost never actually be cleaned up later. Rushing creates technical debt. Not saying it doesn't happen, but the degree to which people commit something they know to be wrong just for expediency is low.
This certainly affects agility. All of the burdens of docs, reviews, testing, et al do slow down iteration, but I've also been slowed down by hacky code at other companies. It's a trade off.
Personal projects are a way to let off steam and feel agile again. There you can bypass reviews, tests, docs, and just hack hack hack.
Couple of karma points isn't worth pissing your co-workers. If you really want karma, just make an empty post with title "If you don't vote up, I'll write a stupid post that will ruin my career." I promise I will vote up.
Overall, Test was a joke in Bing and most of the people there weren't passionate about coding. They were simply concerned with their bonuses and paychecks. 360 feedback was all about bringing others down. Managers cared about their promotions and fat checks. This problem might be common across large companies - I've heard that from several friends across the industry.
Since I left MS, I've been happier than ever!! Now, I'm making a difference in the world saving millions of lives and the extra time that I put in is well worth it as it's not about competing against yet another product! :)
Nobody OFFICIALLY does that. Probably because subsection 89 paragraph 12 clause 9 specifically prohibits that kind of activity on company time, and the company owns everything you produce or think of outside work blah blah blah, only company officers may speak for the company and you're not an officer, and you are never off duty and always working for the company who owns everything you may ever say, therefore you may never communicate with another human being in any manner... officially... in theory...
In practice psuedonymity is the rule. No one he's met in 8 months has seen fit to give a kid leverage over him for no apparent reason.
I've worked with enough small to large companies, to feel confident saying that if the culture does not value and encourage documentation, then you shouldn't plan on staying. Back in the day we made do with SMB/NFS shares, but with todays wikis, SharePoint, and google docs, there is no excuse.
From internal APIs docs, VPN setups, build env. setup, POs, to expense reports, you shouldn't have to find the right person. Any company < 2 years should be in the process of developing this stuff, and any company older should either have it or you should be looking for a new job.
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.
First of all this is not how all large companies work. This is how bad companies, with poor leadership, bad process, and a complete lack of understanding work. And no, the answer isn't to be stuck so deep in process that you cannot move! The answer, like most things, is a considered, fitting and appropriate balance.
Secondly this attitude stinks. There is no way on Earth I would employ you to work for me. Is it any wonder that the software industry has such a lackluster reputation? An industry full of cowboys and CPs (copy and pasters) like yourself. If you really think like this then you should be looking to change your profession. Yes things need to ship, and no we can't develop forever, but without continuous improvement where do we end up? I am sick of hearing the 'people have lives you know' excuse for utter laziness. If you feel like this then you picked the wrong (rapidly changing) industry to work in. Too bad, so sad. Quit whinging and get a job you can leave behind at the end of the day e.g. shelf stacker.
Companies like this already have extensive internal ecosystems of tools. These tools were built to work together with other company systems, they adhere to various internal development standards, have teams dedicated to supporting and enhancing them, and are already known and trusted by other engineers and management.
For any problem you are likely to encounter as an engineer, there is typically an existing system that already does what you need, or close. This tool can quite probably be improved or reconfigured to do what you need with less effort than it would take to bring in an outside tool and make it fit internal expectations.
Because of this, the smart bet is usually to use or extend existing solutions rather than exploring and importing new ones. And really, just learning all about the internal systems is a job in itself, quite enough to sate the curiosity of nearly anyone.
I have to imagine that a job that allows for 8-10 hours of pure coding (not debugging, not discussing design, etc) every day has a boatload of half-finished-but-not-operational projects sitting around, waiting to be tested & completed.
that word, "agility". I do not think that it means what you think it means.
I would like to offer one other realization that you need to make early on. Your bosses are your bosses because they are better at playing politics than the people that came before them, not because they are more skilled or talented. The best part of working for a large selective company like MS is that you get to work with skilled/talented Type A personalities. Start building your rolodex. This way when you want to move into a director position or start a company you are miles ahead of everyone else.
Cheers!
Also, Microsoft is a massive company, and this person thinks a single team reflects the entire company culture? It's a huge company with hundreds of teams. One team does not define the organization.
This post should be titled "I worked at Azure 8 months out of college and here's what I learned." That would be a more accurate title.
Ah how naive :)
> The world outside is not known here a lot. I bet you’re reading what sort of latest technologies and tools are out on blogs, Reddit or Hacker News every day.
Not reading any tech news sites at all? That is odd, so many developers do.
> Not everybody is fond of latest versions here.
Must be a Windows culture thing. I don't know many Linux users who aren't using the latest version with all programs often or even automatically updated. Except some university computer labs using ancient Linux distros like Mandrake.
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.
And I love the Microsoft Test Lab Guides (http://social.technet.microsoft.com/wiki/contents/articles/1...) which is continuously updated.
There 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.
I'm surprised you learned this in college. My department couldn't care less about code quality, and in fact they teach a lot of stuff that goes against the majority of style guides. In an extreme case, I've seen code written by a senior student that repeated tons of code because he didn't use loops, and he passed the assignment just fine.
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.
> 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.
Yes, it it were your company you would have all you employees write tons of document instead of working on new project and actually making money, I know all freelancer and small company have tons of document and run on CMM5.
Wonder why all old CEO never thought of this. They should hire this guy to be the new CEO.
You are working to get the shareholders a better share price and dividend payout.
If managers and stockholders benefit from that, that's cool with me.
I hope for his sake that he has understanding managers up the chain and a good second job planned out.
Hmm. I see lots of excellent answers on Stack Overflow from declared Microsoft engineers, and undoubtedly many more undeclared ones. I think the OP is extrapolating, but also that s/he may have caught something of the culture there..
> Every company has its own problems.
Over time you'll find most companies/organisations operate in very similar ways.
I'd say it's not even specific to the I.T. industry, but rather, just the way people tend to operate.
It’s the politics of human interaction and the bigger the organisation the more politics you will find.
code reviews can be skipped sometimes, usually I too go by offline review and checkin. even the people I work with don't give a fk about open source, HN/reddit or about competitors. at our level we are there to develop what we are told to. If you are interested in something you have to spend time after 6PM at home which is reality in most agile teams. to end 'LIVE WITH IT'
Nevertheless these points are valid and we all know the problems of this stuff.
Am I the only one that thinks this is completely unacceptable?
Ah, to be young and naive again. This is one of those lofty goals that I'm sure everyone aspires to but absolutely no one really ends up doing.
:)
"I am surprised that no one I met in Windows Azure team heard about Heroku or Rackspace"
Aside from the obvious ambiguities, this simply cannot be true.
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, not everybody has to know these.
This is very, very, very wrong, it's wrong beyond words. Not having heard about the competition -- especially in such a trendy thing -- is a symptom of your people not being familiar with the technology they develop. Not cool. Someone in Recruiting had to meet a recruitment quota. You can't make racing games with people who don't know there are other racing games beyond those they develop, and they most certainly cannot be creative if what everyone else calls "reinventing the wheel" is "new development" to them.
That isn't to say everyone has to have a perfect picture about the competition, their strong points and weak points and so on. That's what the Marketing and Sales folks are paid for. But a lot of things, from motivating people to exploring new features, is difficult -- hell, if you ask me, it's impossible -- if they don't have a full picture of the field they play on. It's like fielding a football team and asking them to play against an unknown team, blindfolded.
> It is all about getting shit done in corporations. [...] As long as that functionality is ready, it is okay and can always be fixed later.
Windows Azure is just three years old IIRC. Let them bask in their Getting Things Done attitude for another ten years. Either their developers will get their shit together, or three quarters of the team will be interns, new employees who have no idea what they got themselves into, people who just couldn't be made to fit anywhere else but the company is afraid to fire over crackpots' lawsuits and a horde of business majors to run the project.
Don't get me wrong -- both the approaches I outlined and the ones presented in the article can be equally lucrative under the right management, and the supply of teachers' pets eager to climb the corporate ladder will always be drawn towards the fiery chasm of companies like Microsoft. Hell, even smart and brave folks will do it, thinking they will be able to take it an fit in, will try it -- I've done it myself, twice even (in true experimental science way). But the one this guy talks about tends to drive away most of the smart, dedicated, creative people. You can run a corporation on corporate drones, but your market leader position will constantly be usurped by technical shortcomings, even among brilliant products, and constantly be saved only by savvy business tactics. Profitable (even in the long term), but sorrily futile in the greater picture of things.
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.
The nonsense (endless meetings, anti-intellectualism, lack of passion) is why so many people check out for good around 40. I really hate the stereotype that that's normal, though; I go to Lisp meetups and fairly often run into people in their 50s to 70s who are still passionate about technology.
I want to know, now and in 6 months, where the OP ends up. I'm not going to get into more detail than this, but one learns a lot (about others, organizations, and oneself) through whistleblowing.
It is so obvious (and ridiculous) that nginx has more market share than IIS precisely because of lack of meetings and design documents.))