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.