1 post tagged “hr”

I've always harped on the importance of good developers.  I know this is clearly a biased view, I myself being a developer, but nonetheless I remain steadfast that it is absolutely true.  You just about can't overpay for a good programmer.  It'd be hard.  The companies that recruit the best talent, that fight the hardest for the best developers, are also the most successful companies.

The knowledge worker is more important than ever and grows more important all the time.  It's amazing not every company has already picked up on this...but the companies out ahead, leading the way, already recognize it.

So given this fact, I was surprised by yegge's latest post that Google programmers are essentially interchangeable.  People can switch teams at almost any point without wailing and suffering.  They require a specific set of languages, and documentation, that diminish the otherwise irreplaceable nature of any one programmer.

It took me a bit of thought to coincide these two seemingly disparate facts.  1) Google pays tons of money for developers. 2) Google treats them as interchangeable and intentionally reduces their individual value to the company.

I started reflecting upon this when a particular employee left our company recently.  She was a great programmer to start with, but made herself magnitudes more valuable to our company by contributing SO MUCH to some of our most important frameworks.

A software company needs great programmers.  And if you have extremely complex software, a brilliant one is definitely worth 375k/year.  Once a company has invested so much in a person, it's the natural response to give them lots of control over lots of important code.  But the problem is the company doesn't guard against the inevitable result of becoming hopelessly desperately dependent upon a single person.  In video-game development post-mortems , just like everywhere, one of the biggest contributions to failure is "lead" developers quitting or even just going on vacation!

The insidiousness of this problem is that the greater the developer the more natural the tendency for their code and architecture to infiltrate every nook of your code base.

It's an odd contradiction, but I think companies should recognize the enormous value of great developers, and yet simultaneously fight to prevent them from growing even more enormously valuable over time.

If you have a webserver that's critical to your business, you'd be dumb not to have at LEAST one backup ready to go immediately should the first fail.  And that's when webservers can have 99.9% uptimes!  In a lot of large software companies your lead developer is easily as important as that webserver (apples and oranges, I know), but the company doesn't make the same attempt to have a "backup".

I'm not saying every project needs developer redundancy, but frameworks and products that aren't one-off probably do.  The real company win to "pair programming" is not speed or code quality.  I think the best of the pair could probably do better on both accounts all on her own.  But the goal at this juncture is avoiding catastrophe by having a backup.  The more important the venture, the more backups there should be.

It is an unusual result to say that more successful companies a) pay more for employees b) devalue them more once they are hired.  I think it also runs counterintuitive to the sensibilities of more traditional "architects" or "engineers" in other fields, because most software lives and breathes for much longer than other architected or engineered structures.  When engineering a bridge or architecting a skyscraper, there's not going to be a version 1.1.  And if there is a version 2.0, the maker of version 1.0 will probably be long retired.  It wouldn't matter anyway though, because 2.0 would be a complete rewrite...since new bridges and new skyscrapers are not normally built as some sort of scaffolding on top of the original 1.0 (maybe it's happened I don't know...)

So when constructing things in the physical world, generally speaking, you do not really NEED to retain the achitect/engineer after your product has shipped, because it will not be undergoing continuous refinement.  Not so with software, where your entire structure is made out of easily-refined thought-stuff.  The process of refinement happens frequently and almost endlessly.  Software can grow organically for a decade or longer, constantly piling on more logic and processes.