[kqr]

This is an important point. My light-bulb moment was when I talked to a product owner in a previous job, and I expressed surprise around an expensive planned change, because it didn't seem that valuable to our customers.

He said, "Almost half of what we do is not that valuable to our customers, but it's valuable to him, and her, and him", pointing through the conference-room window at my fellow programmers, "and that's why we do it. If we only did things that were very valuable to our customers, we wouldn't have nearly as many good engineers on the team as we do."

[apical_dendrite]

A better way to put it is that these things do have value to the customer, the customer just doesn't have a way to understand how the work you're doing provides value because it's the part of the product you don't see. If you clean up technical debt, improve test coverage, improve your deployment systems, etc, it doesn't change the immediate customer experience in a meaningful way, but it does allow you to deliver the changes that customers do see faster and with fewer risks.

This quote makes it seem like the work is self-indulgent, and I have seen that happen sometimes, but it's not half of what we do.

[threetonesun]

Do the engineers not derive enjoyment in their jobs from making the customer experience better? This does track with what I've experience in my career, where we've gone from everything being to better the user experience to tech companies sort of trying to out-do each other in their technical solutions while the software continuously gets worse and more antagonistic.

[Arainach]

Plenty of value comes from things the customer doesn't care about.

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"

[suttontom]

I wouldn't agree with that. The issue with software is that the people you make things for are usually anonymous and you'll never meet them, but if you've ever built software that helped someone and you witnessed it, it feels really good.

[Arainach]

Meeting your customers feels good. It's still not why I do it. I've written components that were used by billions of people and generally loved (pieces of the Windows 7 taskbar) and talked to people about that work. I've worked in the education space and talked directly to the staff at schools who use my product to hear their use cases, thoughts, and feedback. It's fun, humbling, and rewarding. It's not what motivates me day to day.

[thedevilslawyer]

how are you navigating the AI wave? Those parts of the job are fully out, and the customer engagement/value are fully in.

[Arainach]

I don't agree with your statement. Individual productivity is very different from team productivity. AI is much like the traditional cowboy coder - prioritizing speed above all else leads to disaster.

As to customers, customers value stability. They don't want the UI changing every week, they don't want random changes of the data model that corrupt their content, and so the traditions of quality, strong testing and integration pipelines, and so on are just as important in established products - in some ways more important than ever, as there are plenty of opportunities for your competitors to burn user trust and drive them away.

I have yet to encounter an established product demonstrating a massive improvement in velocity due to AI. Being able to spit out prototypes doesn't matter all that much.

I'm handling the AI wave by holding on to my sanity and skills and working to establish a reputation in preparation for big paychecks fixing the messes everyone else is creating with their tokens.

[lubujackson]

This is the danger of isolating engineering from customers, or even internal customer-interfacing employees.

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.

[busterarm]

Not just isolating them from customers but also from engineering-adjacent work that isn't code.

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.

[tracker1]

That's my take as well... the dev effectively takes on QA/QC and PM roles as a team working with AI for the baseline of development work. Of course, this is also a slightly different skill set and cognitive load. It also needs to completely upend how project planning happens when you are using Dev+AI in coordination.

[jasondigitized]

There are plenty of projects that are green lit that have good intent but are bone headed when it comes to solution and implementation. Good engineers hate these types of projects. Good PMs try to avoid these at all costs but sometimes your hand gets forced because some VIP, either internal or external volun-tells you to do it.

[kentm]

> Do the engineers not derive enjoyment in their jobs from making the customer experience better?

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.

[threetonesun]

Platform and internal dev teams have customers as well. I'm not terribly frustrated that you don't get this. I've certainly worked with devs (and managers) who wanted to push new technology for the sake of using new technology, and they should have found a side project as an outlet for this.

[Arainach]

The person you're responding to never said those teams didn't have customers.

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.

[kentm]

> The person you're responding to never said those teams didn't have customers.

> 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.

[kentm]

I'm going to apologize in advance for being long-winded, but I feel there's a lot to unpack here.

> 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!

[wbl]

Force me to click hundreds of buttons per release and I'm going to be disinclined to go through that. You wouldn't have a surgeon have to go hunting for the right tools.

[agentultra]

I dunno about everyone, but I do. It drives me up the wall when software is slow, stutters, etc. There’s almost no good excuse for it. But it happens anyway because of some combination of, “nobody cares,” and, “money.”

I derive joy out of people using a thing i helped design and they never get frustrated with it. It works, it’s fast, it solves the problem and it’s rarely a pain to maintain or extend for me or my team. Thats good, solid stuff right there.

[duxup]

That's kinda software development ... generally and not really new as far as I'm concerned.

Even everyone earnestly trying to identify the feature that IS IMPORTANT to clients and will actually be used and appreciated frequently is something of a crap shoot.

[mettamage]

By that logic, pair programming should have taken off

[plaidthunder]

I always found pair programming a bit.. hellish. Chatting about things. Rubberducking. Playing code review ping pong. All great. But the feeling of being shoulder surfed killed my ability to play around with the freedom that I do when I'm alone -- and that playing around sometimes led to better/more interesting outcomes than I'd have gotten otherwise.

[sanderjd]

Yeah, I always bought the premise that it was good for the software, but it didn't work for me as a person, it drained my energy way too fast to spend hours of the day having to be "on" in conversation with another person.

In many ways, I think what's working for me with AI is that it is very similar to pair programming, but without the social-emotional investment required to interact with another person for long periods of time.

[98codes]

Far too many introverts in software development for that.

[Arainach]

You can be extroverted and not want to spend an entire work day interacting with people without a moment of privacy or introspection.

[jbxntuehineoh]

thank God, if anyone knew how much time i spend swearing at our codebase i'd have a meeting with HR scheduled within a week

[yosefk]

Certainly puts "good" into perspective

[unlikelytomato]

Perhaps those “good engineers” need a reminder of who enables their situation to exist at all.

[skrebbel]

How this goes is the engineers start raising arguments in meetings full of nerdy technical terms such as “refactor”, “technical debt” and “accidental complexity”. As time progresses, more of them say more of this. At some point management learns that when engineers say engineery words like this you sometimes gotta say yes and let them do it even if it means urgent features are delayed, or the engineers will walk.

[gamblor956]

Let them walk. Good programmers can write code that doesn't degrade the customer experience.

In the last 15 years it's been all about the programmer's experience and user-facing software is objectively slower, buggier, and more resource intensive.

[unlikelytomato]

Good engineers would communicate effectively of something is impacting the product. Good product understands how to judge that impact and prioritize it. Frankly, if the engineers are making enough tech debt that they don't want to play in their own sandbox as part of regular practice, maybe they should walk.

[darkwater]

It's a two ways street though, isn't it? With lazy/unskilled/unmotivated developers you will have a shitty product, or maybe your SaaS would explode the day it's starting to get traction.

[dragonshed]

Are you all hiring?

[jameshart]

I mean if half of what you do isn’t delivering customer value maybe you don’t need to have as many good engineers on the team as you do.