Developer happiness considered harmful (sometimes)


Let’s take another look at W3C’s Priority of Constituencies:

In case of conflict, consider users over authors over implementors over specifiers over theoretical purity. In other words costs or difficulties to the user should be given more weight than costs to authors; which in turn should be given more weight than costs to implementors; which should be given more weight than costs to authors of the spec itself, which should be given more weight than those proposing changes for theoretical reasons alone. Of course, it is preferred to make things better for multiple constituencies at once.

That last line is a creeper if you think about it.

Making things better for multiple constituencies at once is a fine trick if you can pull it off.

I once had a healthy and robust discussion with a fellow developer about the benefit of making changes that are seemingly aimed only at developer happiness.

My colleague argued that anything that makes developers happier and more productive will eventually propagate to better outcomes for the end user and business.

But I couldn’t see how this would always be the case. This argument assumes that the interests of developers will always be aligned with the interests of other constituents.

If this were true we wouldn’t see products with beautiful code fail because there was no value in them for users. And we wouldn’t sacrifice performance in the name of over-engineered frameworks and bloated off-the-shelf solutions.

This is where dogma and zealotry are harmful. Ascribing to a fixed point of view, no matter the context or evidence to the contrary, can be damaging to other groups involved in your product.

As a leader, it’s your responsibility to ensure that you understand and engage with needs beyond those of the developers.

Developer happiness is only a benefit if it first does no harm to others. Even better if it genuinely amplifies benefits to those further up chain of priorities.

Think for a minute: Can you remember a decision that was made solely in the interest of developers? What impact did it have for users? For the business? For others?

All the best,

– Jim

Receive emails like this in your inbox

I write about front-end engineering leadership every weekday.

Sign up now and get my Front-End Engineering Responsibilities Laundry List PDF for free.

You'll get regular emails about front-end development. Unsubscribe at any time.