There's a ton of wrong with that statements tone, not that I think the author meant it that way, but I'll point it out regardless:

#1 - The majority of HN seems to involve typical latests web crud app fads. It's probably also not that interesting to *nix system developers either, though many might read it for the apps being created as opposed to the how.

#2 - Having MongoDB on your CV generally means you're developing for your CV. Occasionally it means you had a valid usecase, but if you tried to sell me on that for a typical app, I'd never hire you.

#3 - The bleeding edge is called that for a reason. Sometimes you'll bleed and theres very good reasons to stick with tried and tested.

#4 - It's easier to make it simple to get up and running when you have that from the start or early on, and working with techs that make that easy. Not so much when you're inherited a lot of legacy, some of it you don't even understand.

For what it's worth, MS make some decent products, so it's hard to entirely slate them but I imagine the GPs opinion that they could be doing things a lot better is also true, just some of the points were kinda off base imo. If anything.

Microsoft is the complete opposite of Facebook's "Move fast and break things". And that's a good thing, in a lot of ways. When entire companies (industries?) are dependent on you: slow & steady to get it right is much, much better than moving quickly to integrate the newest technology.

Sure, it's "move slow and break things". As judged by my experiences with most Microsoft products over the last twenty years, and reinforced by my current experience with Windows Azure's bizarre engineering choices and instability issues (the team to which the OP was assigned).

I drive an MRI scanner or 2 that are built on windows 2000. It's so very painful that modern scanners use such old OSs. The OS is masked from the user, but as soon as you try to do something complex (real complex, like getting images onto a memory stick) you have to use a series of crude hacks to get an explorer window up, then work around the disabled functions to get data off the scanner without using the network port.

Heh, that reminds me of all the bad scanner software I've ever dealt with in my time, and wondering how dead inside that person truly must be to have had to write it in the first place.

How is Microsoft slow and steady when he just told you they have poor code quality, no docs, etc.

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.

[Edited to fix redundant sentence].

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.

Where did he mention poor code quality? Out of date documentation is all I see mentioned.

He mentioned copy/pasting code and skipping reviews were popular things to do. The first one is definitely a sign of poor code quality, and the second isn't as definite but is surely a practice that makes room for poor code quality.

I'd say that's implicit, if code that doesn't deliver business value (refactoring, documenting, etc.) is wasted, people won't do it.

I don't think code quality and documentation quality are strongly correlated, they are just complementary.

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.

> no docs

I suggest the OP just fire up the MSDN.

Interestingly, many companies including mine are dependent on Facebook and their APIs. They do move fast and break things, and we feel the pain of it practically every day.

All these things are fine, except for the suggested Microsoft culture of not knowing what's out there, what the competition is doing. If you don't at least keep one eye on what's going on, then you're not going to see other people's mistakes and learn from them.

It's curiosity that's important, not new stuff. We read HN because we're curious, and we don't want to miss anything. We don't get stuck on old inferior tools (at least not at home) because we like to tinker and explore. You can judge people, to some extent, based on their reading, their tools, how informed they are about the competition. Programming is like surfing a tidal wave of information and change; you don't improve by sticking your head in the sand.

(Yeah, that last sentence is a tidal wave of mixed metaphore tossed like a salad.)

Programming is more like surfing an infinite amount of tidal waves of information change. Every wave is different, but ultimately they're all just waves regardless of how much people argue which is superior to the other.

Point being, when you're 35 and an expert in your field, you probably need to spend less time learning what the cool kids are up to as opposed to when you're 23 and learning your field and everything you learn is new.

That doesn't mean that you can let yourself not be current, but if your future plans are to work 12 hours per day then go home and read HN at night, I pity your wife and family prospects. :p

Yes. And it's not just learning new stuff. It's important to just keep learning stuff.

It's shocking how many of my team mates haven't even heard about Scheme, let alone tried to learn it. And yet learning that language (I'm still working on it) is revolutionising the quality of my code. There's a lot of important stuff that was developed years ago that's just as important as stuff that's coming out today.

'Inferior' is often a matter of perspective.

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 agree.

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.

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.

Referring to comments as dangerous is dangerous.