Hacker News new | ask | show | jobs
by mborch 1017 days ago
You don't need to measure software developer productivity. The article (or ad) admits as much:

> Further, attracting and retaining top software development talent depends in large part on providing a workplace and tools that allow engineers to do their best work and encourages their creativity.

So do that!

Happy people are productive, and talented, creative people move your business forward.

1 comments

One issue with that logic is when you have people that don't care about being happy at the workplace and just act like they are working. Even if you intervene and try to honestly understand what is making them work the way they do, some of them will feed you with BS.

An option to deal with those people is to just fire them, simple. But that means you are giving up on them. Another option is to have an hybrid approach: those that work great with having happiness as a motivation, we can just continue to foster a happy workplace; for those that don't care about happiness, find another approach, one example would be to introduce KPIs for those specific people and formulate a performance recovery plan if needed, if all else fails, fire them.

Having mentored a dozen of developers over the years, I've arrived at a strong bias toward hiring intrinsically motivated individuals. It's much easier to grow skills given someone is motivated than vice versa. KPIs (or "SMART" objectives) are mostly managerial toys that seldom improve work ethos.

Happiness in the workplace is more often than not related to other aspects than the primary process of developing software. If the subject matter itself (as in: "I earn a living while hating the building websites in PHP") is the root cause of unhappiness, no recovery plan, KPI or reward can fix this. Best find another job.

SMART goals and KPIs are meant to improve work focus, not work ethos. Those two are not in opposition to each other. IME engineers who don't want to do measurably good work are inexperienced, disgruntled or unmotivated.

Forcing goals onto a disgruntled/unmotivated engineer will end badly. Giving no goals to motivated engineers will also end badly. Giving bad, unrelated or unachievable goals to motivated engineers will end in disgruntled or unmotivated engineers.

You have to get both right.

I have never met a productive software developer that didn't fundamentally enjoy his or her work ("happiness"). What do you do with an unhappy person? At some point, if everyone else is happy, it's just time for them to move on I think, and you probably have to "help them out".