It's easy to read the first page (or just the headline) and come up with the "you're not paying enough/your problems aren't interesting enough" response. That's what pretty much everyone who's posted here so far has said. (And that's what my initial reaction was, too.)
But that's not a terribly useful reaction, and it's especially not a terribly useful one to be posting here, where pretty much everyone agrees with you already.
First, this guy understands (or at least claims to understand) a lot of the points you're all making already, and describes some of the steps he's taking to address them. (Mostly on pages 2 and 3.) Maybe it'll work for him, maybe it won't; I know far too little about the details to have any idea. In either case though, repeating the same "more money/interesting problems" thing over and over doesn't really have any effect.
Second, some of the problems he's having are actually real problems. Any company that's been around more than a few months is going to have existing systems, and it often doesn't make sense to rewrite the entire thing every time you need a new feature...even if the existing system is a bit ugly. As a programmer, that's an important thing to understand, and it's something people who don't have a lot of practical programming experience aren't necessarily going to understand. Knowing that this is a potential issue is something that can help you both as an employer and as an employee.
edit: I'm not saying that this guy actually knows what he's talking about, and that the things he's doing will actually fix the problems he's having. I'm saying that reactionary "this sucks" responses aren't very useful, especially here.
I don't know what is disappointing, I read the full thing, it sounds like your regular IT sweatshop if you read between the lines. Things like:
1) Giving the new guy an entire module to own (written by someone else).
Ok, so it's an entire module, no one explains htf it works? Every job I've been to, this is how it works, and it sucks. When I write something and someone new comes along to work on it, I try and give them some help. Otherwise, you get the "We should rewrite this from scratch", because it's probably crappy looking code. New guy might make more crappy looking code, but that's the natural reaction most people have to 'a pile of code'.
2) Back in his 'day' IT guys worked around-the-clock.
Seems like the shortage today is in labor, not in jobs. We no longer work around the clock because WE DON'T HAVE TO.
3) And I quote " They don't have the same notion that you go to one place and you stay there for five, 10 or 15 years. But the incentives to do that aren't there anymore because there are fewer pension plans and less profit sharing."
This. So much this. I often joke about becoming a school teacher so I get a retirement package.
I'm a mercenary for hire to the highest bidder. Until I find a company that can demonstrate some kind of loyalty towards me, that's how it is. I don't particularly like it, but I have a wife/kids/mortgage and can't take a year off to start my own company at this point.
I know I'll get downvoted since HN frowns upon culture and fun, but 'qdog: code mercenary' has a nice ring to it. Get someone to make a webcomic about your exploits.
I've already talked about the things in here that were directly contradictory with what I personally want in a job (not interesting, low pay, etc), so I'll ignore those. Here's a huge, huge problem with his mindset:
> Secondly, we're working more closely with folks to determine their strengths and desires and align them to the right systems. Third, as new developers come in, we are teaming them with a business partner to help them understand the impact of their system on the business. We're trying to get them more invested in the strategy. We're trying to engage them in where the company is going.
This sort of reality distortion -- changing the developer's frame of reference as to what is interesting or not -- is one of the absolute key problems this company will have with retention. First year developer: Great, I'm working on this app with does X for the business, which causes us to save $Y on Z; I'm psyched. Second year developer: Wait, I don't see X or Z, and whether or not we save $Y or $Y * W, it's all the same to me; why am I doing this again?
You have to adapt to the developer, not adapt the developer to the business. There are simply too many great opportunities for a developer to expect them to put up with this.
Edit with one more thing: One of the huge underlying things that I saw in just about every part of the article was that developers weren't to be agents of their own destiny. They were to be told what to do, how to do it, and when to do it. Unless you give people some degree of power over the things they do, then 1) they're not connected or invested, and 2) they feel like a rat in a maze. Now, it seems that he has recognized this as a problem -- e.g. "They've got to take something that exists, but they don't have to live with it the way it exists." -- but it seems like a proper solution is a bit away.
It's easy to read the first page (or just the headline) and come up with the "you're not paying enough/your problems aren't interesting enough" response. That's what pretty much everyone who's posted here so far has said. (And that's what my initial reaction was, too.)
But that's not a terribly useful reaction, and it's especially not a terribly useful one to be posting here, where pretty much everyone agrees with you already.
First, this guy understands (or at least claims to understand) a lot of the points you're all making already, and describes some of the steps he's taking to address them. (Mostly on pages 2 and 3.) Maybe it'll work for him, maybe it won't; I know far too little about the details to have any idea. In either case though, repeating the same "more money/interesting problems" thing over and over doesn't really have any effect.
Second, some of the problems he's having are actually real problems. Any company that's been around more than a few months is going to have existing systems, and it often doesn't make sense to rewrite the entire thing every time you need a new feature...even if the existing system is a bit ugly. As a programmer, that's an important thing to understand, and it's something people who don't have a lot of practical programming experience aren't necessarily going to understand. Knowing that this is a potential issue is something that can help you both as an employer and as an employee.
edit: I'm not saying that this guy actually knows what he's talking about, and that the things he's doing will actually fix the problems he's having. I'm saying that reactionary "this sucks" responses aren't very useful, especially here.