Hacker News new | past | comments | ask | show | jobs | submit login

100% agreement, yet:

> If companies would just wise up enough to pay a good programmer 3 times as much as a mediocre programmer to do 10 times the work...

Very few people have such a good eye for talent. It's really, really hard to do. Jack Welch, one of the better HR people of all time, said his hiring success rate was only 2 out of 3 hires working out even towards the end of his tenure. It's really hard to identify good people, know how they'll change and adapt over time, create a good environment for them, and so on. Vastly under ratedly hard. One of the reasons good people are underpaid is that it's often quite hard to tell them apart from "just okay" people. People are bad at picking talent - they mistake overconfidence and gregariousness for ability, they put put premiums on likability and agreeableness, they look for people who "look like a winner" when that only maybe slightly correlates... hard stuff. Companies whose managers have technical backgrounds have a better chance, but it's still quite a difficult challenge.




They also can mistake business for productivity. For example, there's the classic joke (at least in the sys admin world) about breaking something about a month before reviews, then stay over the weekend to fix it. You will be the savior of the company and be rewarded in kind.

Really good work is hard to see sometimes because it doesn't look like work. If you had two teams, one just delivered on time on and on budget and the other spent a heroic month overdue fixing bugs and finally shipping over budget it might appear that the people on the second team are better. They work more and worked harder than the first team. You might even decide that the first team was given too large a budget and too much time, when in reality they paced themselves and had talented people who could give good estimates and were able to deliver on their promises.

YOU might not make that mistake, but I can guarantee that many managers would give greater rewards the team working overtime to fix (their own) bugs than the one that consistently delivers on time and on budget.

I think it has more to due with the culture believing that software is buggy and impossible to schedule, and rewarding people when faced with those things.


"Very few people have such a good eye for talent."

That's OK because it's not necessary.

Management doesn't need an eye for talent. It needs an eye for demonstrated performance.

If Programmer A consistently delivers excellent software in x% of the time of Programmers B thru G, the users/customers love it, and the maintenance costs are a small % (if they have a way of measuring this), then what the f*&#%@ else does management need to know? Treat Programmer A appropriately or lose him/her.

Talent is in the eye of the beholder.

Demonstrated performance is on the bottom line.


But do managers know how to measure performance? Really?

In an enterprise situation, for example, do "customers" really know if they love the software, or the presentation that sold them the idea, or perhaps they asked for something to be built wrong.

I would suggest that "very few managers have such a good eye for performance" no matter the metric.


When I was a low-level employee using custom-built SAP crap, I could have easily lost my job if I dare suggest an "improvement" on the software.


Demonstrated performance on what? A padded resume? A minimal contribution to a well known large project?

Or is your ideal company one that hires 100 programmers to perform the same task and then fire the bottom 95% after a code review? You're assuming the company has already hired all-star talent (accidentally?) and just needs to pay off their demands. What happens when this all-star leaves to balloon across the world - how do you find a replacement?


This is why projects with large teams contributing to one system or application make it exceptionally hard to pick and reward good programmers. Their contributions just wont stand out functionally in the mass of mediocre performing system.

Moreover, their code may be considered unreadable or even dangerous by less experienced team members, leading to situations when he is considered less capable by the management than actually is.

It seems to me developing systems with loosely coupled components rather than tight, rigid interfaces, and keeping overall size small is the only way for assessing performance of products of individuals. Not an easy way, for sure.




Consider applying for YC's W25 batch! Applications are open till Nov 12.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: