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.

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

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

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.

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.

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.

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?

It is absurd. Experience teaches you that.

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'm shocked they hadn't been "renewed" by "Carrousel". Or were they runners?

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.

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.

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!