[BrandonMarc]

He mentions increasing salary won't lead to increased productivity ... and that's true, if the same developer remains. But what if we remove that constraint? What if increased salary means a higher quality of developer takes the position? Wouldn't this mean higher productivity?

Bit of a cold scenario, but one way to game it out is hypothetically removing the current dev and then hiring someone better at double the pay.

Or, less unfair seeming, double the pay by hiring a second dev. That might not double productivity ... depending on the situation it might 1.5x it, or just as easily 4x it.

[devonkim]

Productivity is a measure I hate to use for individuals because it’s similar to the problem of root cause analysis in systems - our individual productivity comes from many different levers and influences and we tend to act like what works for some archetype of person should work for everyone and even most managers just go by feel basically, which is hardly objective nor measurable let alone accountable. If my CI system is crappy and gives me poor feedback that makes it hard to tell I’m doing something wrong in my commits, it can demotivate me. But fixing it doesn’t mean that I’ll suddenly become a 10x developer either. Similarly, conditions for maximizing potential reliability and performance exists at all times in systems but at least we can open up our editors and go inspect running systems while we really can’t do that with people.

Sometimes firing someone ironically gives them a wake up call and they’ll do great for their next job. Sometimes they don’t learn, sometimes they’ll never recover. Sometimes promoting people helps them, sometimes they become overwhelmed and performance drops again (I’m not speaking Peter Principle either).

[throwaway0950]

I worked for a telecom company for ten years. The first few, everything was good, but we were struggling and raises and bonuses were non-existent and layoffs were frequent. Eventually I realized I was making a lower salary from when I started so I just started working less. Toward the end I was working less than four hours a week, getting positive feedback from my manager and skip-manager.

It hurt my career staying at a dead-end job but it gave me years of free time doing pretty much whatever I wanted.

[kemiller2002]

I don't completely agree with this. Money can affect developer productivity, but it takes time to realize its value. Money makes things easier. That person whose being paid the smallest amount possible, is probably trying to just scrape by. Paying people more money frees their personal life up to handle other things, less stress about family stuff etc. I never believed the "leave your personal life at the door," thing. How you live affects your work, and making life easier makes people more productive (on average, not all cases). Now this isn't an immediate thing. It's an investment and it takes time. The person has to realize that money is available (emotionally) and start to trust it will be there.

[digitalsushi]

Two engineers who are not aligned with each other's goals will easily do the work of zero people.

[gootdude]

Well said, this point can not be stated enough!

[908B64B197]

He's right and wrong at the same time.

If I pay above market rate I'll attract better devs for sure, and the caliber of folks in my hiring pipeline will get better. It's not obvious at all unless you know where to look. College is the prime example of that. If you pay better you'll have more new grads applying and they will prioritize you over other offers (unless you are an exceptionally prestigious employer). But even then, you'll never talk to the student who interned twice at FAANG and got a firm offer a year before graduation. You can get that guy only if you are willing to employ him at FAANG salary for two summers.

Employing these guys won't make my existing hires any better than they are in the immediate future.

However

Better hires leads to better teams. I find that certain developers have a multiplicative effect that applies to other devs. They mentor, document, review and help everyone grow. That might actually slow them (taking half a day to explain high level architecture to a lowly junior coder) until you realize the junior coder is now capable of answering questions from his teammates.

[commandlinefan]

> hiring someone better at double the pay

Well... if you knew how to spot somebody twice as good as the one you have now, why didn't you hire that guy in the first place?

[username90]

Because he demanded twice the salary?

[commandlinefan]

Well, in that case, I’m 10 times as good.

[suprfnk]

> a higher quality of developer

So what is a "higher quality of developer"?