Hacker News new | ask | show | jobs
by d4nt 5770 days ago
> "Move up the ladder into management, architecture, or design"

The ability to convert detailed specs into code is a fungible commodity. Management, architecture and design, on the other hand, are areas of software development where you need multiple complementary skills; technical ability, good communication, understanding of your customers and industry area, an ability to influence others, etc. People like that cannot easily be replaced, hence the higher price. In some cases technical guys appear to need those things too, but that's just because they're unofficially doing the job of an architect, manager or designer.

> Even though you may be highly experienced and wise, employers aren’t willing or able to pay an experienced worker twice or thrice what an entry-level worker earns.

Define wise. That sounds a lot like "capable of being an architect/manager/designer". If you're capable but resisting the promotion then I'm suspicious of your claim to deserve more money.

I agree with you that an experienced coder will be more productive than a less experienced one. But I would also say that 20 years experience will never make up for a lack of natural ability. I've interviewed programmers with decades of experience who failed the most basic of our technical tests (think FizzBuzz). I'll bet for every old timer who's excellent and just wants to stay a coder, there are 5 who are just below average and have never been offered a promotion.

I see the issue more as a failure by the good experienced coders to differentiate themselves in the marketplace than a conspiracy against old people. If you've been doing something for 30 years but all you're selling is "5 years python experience" just like everyone else then why should I pay you more? Tell me why you're worth more. Convince me you're lack of promotion comes from a passion for your craft and not just down to a lack of ambition or ability.

2 comments

> The ability to convert detailed specs into code is a fungible commodity.

I strongly disagree. The point of a commodity, in the economic sense I assume you meant, is that one item is just as good as another. You pay a certain amount of $$$, and you get a certain amount of Stuff.

IME, one piece of code implementing a particular requirement is very much not the same as another. Assuming otherwise is the kind of naivety that leads managers to make the sort of mistakes we've been discussing.

> I see the issue more as a failure by the good experienced coders to differentiate themselves in the marketplace than a conspiracy against old people. [...] Tell me why you're worth more.

If you believe code is a commodity, you don't want to hear and won't believe the answer anyway.

I love that you're fighting the good fight, but to these people who run things, code is in fact a commodity and so is the person producing it. From the owner's perspective you buy coders low, you maximize their output and sell it high, accumulate the difference, and repeat. If you're a more liberal owner, you buy them free lunches and build up a "culture", let them wear sandals, send them to conferences, tell them they're not little units to be counted, but at the end of the day these pretty lies are just costs -- costs, which may or may not yield profit over the long run.

As a coder, and somebody who loves the craft and identifies strongly with it, I "disagree" with this relationship ( as much as that is possible, since nobody asked me to vote on it or anything ) and I think it is dehumanizing. But wishing it away or romanticizing what we do, avoiding the fact that we are commodities just like every other worker in a corporate enterprise is just a terrible strategy for overcoming it.

I like what the guys at http://www.bettermeans.com are doing with the open enterprise governance model. I don't want human activity to continue the process of commodification, and this is a big step taken to change course.

Oh, I understand the problem; it was "management error #2", I think. And I understand that discussing it here will have little real impact on the managers concerned. I got off that train personally and no longer work as anyone's employee.

I hope that my contributions to discussions like this will encourage others to do the same, and that maybe, if those people one day have employees of their own, they will be a little smarter than the managers of today and the industry will be better for it.

In the meantime, I don't see why we should place any faith in the established practices of managers who, as an industry, run more projects that fail than projects that succeed. Can you name any other industry where it would be considered acceptable by the market if over 50% of the products bought failed, even if the costs ran to millions? I sure can't, it's just that the management idiocy is so widespread in IT that the market seems resigned to the inevitability that whatever they pay for will be crap that doesn't work properly.

"The ability to convert detailed specs into code is a fungible commodity."

If you have a good programming language, the code should be the "detailed specs."

"But I would also say that 20 years experience will never make up for a lack of natural ability."

20 years of "experience" won't, but 20 years of dedicated practice will.