Customers want features as fast and as cheap as possible. I derive joy from solid test suites that avoid me getting paged while on call and team processes that don't allow config changes on Friday so pages don't happen on the weekend.
Very few craftspeople derive their joy from the customer experience. An electrician isn't happy because their work allows me to watch TV. A carpenter isn't happy because a new set of stairs lets me get to the basement faster. They're happy because of their perception of the quality of their work. This goes away when the visible or fun parts are no longer "their work"
If all they see is code, they will get satisfaction from tidy code, not user happiness. One good thing about AI is it elevates product engineers because they more directly bridge the customer-product-code divide.
I've been at a place that is basically microservices slop (several dozen services per engineer). They're all poorly maintained and at least a solid 40% of all this code that they've written could have been just a traefik or nginx configuration/container.
When you have a lot of inexperienced (relative to industry) and overworked software engineers, the solution to every problem becomes to write code and writing new code should be a last resort.
Worse still, there's just a poor general understanding of the internet protocols they're working with and of how to do distributed systems right. Unfortunately with LLMs I've been seeing this get worse, not better.
They use the LLMs for code generation but not architecture review. Bad ideas are getting fully-baked quickly before anyone with good sense can intervene.
Quite a few don't, no.
Different people derive enjoyment in different things and some of the best engineers do not find satisfaction in "delivering better customer experience" but in working with, and improving, cool technology. Its up to management to find areas of the business where they can deploy these people in a way that dove-tails with business success.
Its also the case that only working on projects that "deliver customer value", and having to justify every single endeavor through that lense, is how you end up in a local maxima in your tech stack, get mired in technical debt, and then get lapped by your competitors who have the foresight to work on foundational technology that enables future velocity.
To be frank, its endlessly frustrating that your median Hacker News poster doesn't get this, and instead prefer to brow-beat people about how they're caring about the wrong things.
It's not about new technology for the sake of new technology, it's about taking pride in one's work and what that person created.
Honestly, the American obsession with "everyone should think of what the customer wants" is exhausting verging on toxic. The people who talk about that point loudest are inevitably owners saying "you should all care more to make me richer". If you want your employees to care about the customer more than their own personal satisfaction, give them significant equity and significant autonomy such that they can see how their actions have direct impact. Saying they should think of the customer and then treating the employees as an interchangeable cost to be minimized is insulting and won't lead to anyone focusing on the customer.
> It's not about new technology for the sake of new technology, it's about taking pride in one's work what what that person created.
Thank god, I really want to say that I appreciate that you got what I said. A simple upvote didn't feel like enough.
Employees are humans, not robots. Its inconvenient, but if you want a world-class team then you're going to have to deal with the fact that people derive satisfaction from different things, and you're not going to be able to motivate them by beating them into submission about what they "should care about." This may involve having to think creatively about how to manage your people instead of treating them as fungible work units.
> Platform and internal dev teams have customers as well. I'm not terribly frustrated that you don't get this.
Respectfully, this response here is a perfect example of you not getting it and assuming that I am the one that doesn't get it. You have not said anything that I have not already heard and understood before. The fact that people have different values does not mean they "don't get it." But saying something like "Do the engineers not derive enjoyment in their jobs from making the customer experience better?" does imply that you don't understand other peoples' values.
The fact that you posted "Platform and internal dev teams have customers as well." indicates to me that you missed the point. Whether they are on those teams and whether they consider other engineers their customer is besides the point; they may not derive satisfaction from "delivering value" to those people regardless. That doesn't mean they don't care about their customers, which is the take away the median HN poster takes, but rather that they are not energized and motivated at the end of the day by delivering value to them.
> I've certainly worked with devs (and managers) who wanted to push new technology for the sake of using new technology,
Sure, everyone has. But the flip-side of this is a class of people who assume any tech improvement that doesn't directly move a metric is just an effort at resume-building. Just as often I've seen efforts and building a more robust system as unneeded resume building despite clear need (usually because the need is very hard to measure).
> and they should have found a side project as an outlet for this.
I mean, this is incredibly dismissive and exactly the attitude I was talking about. No-one is saying that engineers should be allowed to just do whatever to have fun. Work is work. But ideally you find ways to organize your team so that everyone is motivated and energized by their work, and doing so requires that you understand that not everyone is motivated by the same thing. But in these discussions, the attitude comes across as "everyone should be motivated by delivering good customer experience and if they aren't we shouldn't care."
If there's no opportunity to give these sorts of people fulfilling work, then fair enough. It *is* work. But the attitude displayed here is that we shouldn't even try and understand their values and think about ways to productively deploy that.
As an aside about customers, internal and external customers are, in my experience, treated vastly differently. We care about experience for external customers, but internal customers is usually all about velocity and trade offs. The bar is substantially lower, and rough edges are almost always ignored. So I am skeptical at the idea that we can just frame internal users as customers and all the discrepancies go away.
It also misses the fact that other people on my team are also my customers, because they have to maintain the system! And I am also my own customer, because I also have to maintain it!