Debunking a widely misconceived myth
Sometimes I hear executives, programmers, and even managers talking about how "programmer happiness" is essential for a project to succeed. Some of them have read an essay from DHH from 4 years ago where he talks about how optimizing for programmer happiness helped Ruby on Rails thrive in their niche. Others have been influenced by the programmers demand to work with better tooling and better frameworks.
It turns out there are programmers who interpret the idea of "programmer happiness" incorrectly. They see it as a principle supposed to make them happy, and only them. Like they should be allowed to work with better build tools and work with the latest shiny framework or library. Guess what? Although those demands can be reasonable, they miss the whole point of the idea.
There is a massive misunderstanding around this idea of "programming happiness" inside and outside programming circles. Although Ruby on Rails succeeded by focusing on programming happiness, it did so because programmers were also Ruby on Rails "consumers".
When DHH talks about "programming happiness", intentionally or not he's talking about the happiness of the people who consume a product and extract value out of it. That's what can help a product to succeed. It's all about maximizing value vs effort and receive feedback from the ones who use the product, not the ones who make it.
The product, in that case, was Ruby on Rails and the consumers were the programmers.
In most businesses and open-source projects, optimizing for the happiness of the consumer is vital for success.
In most traditional SaaS models, for example, the consumers of your code are the ones who pay for the result of that code: the "customers". It's easy to identify them as your "consumers": they pay for what you code and you get a salary. If Ruby on Rails were a traditional SaaS product aimed at non-technical consumers, then they would call the idea of "programming happiness" as "customer happiness" instead.
The core idea is to listen to the feedback of people who extract value out of your software if you want to make an impact in your industry, regardless of which domain it is. Suppose you don't invest significant effort towards your consumer happiness. In that case, you'll miss a lot of groundbreaking ideas from the trenches and also run the risk of nobody using your software.
It's tempting to focus on making yourself and other programmers happy by discussing what's the best front-end framework of the week. It's tempting to focus on the best reactive library for "convenient" UI design or the best tool to improve the build process.
However, before jumping into those discussions, you have to ask:
- "Who is my customer or consumer?"
- "Is the result of this discussion going to create more value for them at the end?"
That's how you'll achieve in your organization the same results from Ruby on Rails "programmer happiness" doctrine. Otherwise, you won't. If you spend significant time trying to make yourself happy, you'll do so until the VC money runs out and you're fired. That's not ethical. That's not professional.
The most valuable idea behind "programmer happiness" is:
That's not about programmers.
Be careful, though. The opposite of programmers being "happy" is not programmers being "miserable". That's a False Dichotomy. It's entirely reasonable for you to love producing value to your customer daily. It makes sense to exercise your skills to provide the simplest solution, even if that solution requires no code at all.
More than programmers, we are creators, designers, problem-solvers. It makes no sense for a company to hire someone who can plumb a few libraries together if their goal is to create more long-term value at a lower cost. Perhaps it makes sense for some companies, like the ones who have a lot of VC money to burn, but that doesn't make them more efficient.
Creating value is what makes me a happy programmer.
If you want to make an impact in the industry you work, listen to the feedback of the people who extract value out of your software.
If the software you develop doesn't have "programmers" as your primary consumer, that is, programmers that potentially pay your salary and extract value out of the code you write, then it's more likely the idea of "programmer" happiness doesn't apply to you. It's counter-productive to follow the concept literally as it will make you focus on yourself and other programmers satisfaction instead of your customer's happiness.
Sometimes, to create a piece of software and make a customer happy, you only need basic tools and "boring" technology. You may not need the best library or framework, only the knowledge on how to create more value more efficiently. If these principles don't align with you, then you should reconsider how you're bringing value to a reasonable organization.
To become efficient, try to not confuse a "customer" with a "programmer" unless you're developing a programming language. Instead, think about "customer" or "consumer" when you hear that term.
Find your consumer, understand their needs, and then code against their interests.
They will appreciate some happiness too.
And you will appreciate their payment back.
Thanks for reading. If you have some feedback, reach out to me on Twitter, Facebook or Github.
Wanna chat in person? You can find me in the Sydney Software Crafters meetup.
Top comments (0)