Hacker News Reader

Comment by MattGaiser | Hacker News Reader

1. Most developers don't work for the end-user. They work for who is paying their salaries, which is often someone is mostly interested in luring the end user and using them to sell a product to someone else (everyone from Google to Facebook to DoorDash has this model). Without those megabytes of JS analytics and whatnot, the end-user cannot be packaged into the actual company product.

2. As the real customer for the developers consists of these institutions, they care more about development costs than whether customer internet is wasted. Developer convenience means cheaper projects.

3. Users blame themselves for the performance tax. They think they downloaded a virus, have an old computer, or need faster internet and they go and upgrade all those things, making the performance tax seemingly disappear.

View on HN

> Most developers don't work for the end-user.

This is extremely reductionist.

If you want to take it further, then nobody works for the end user ever. If you have any funding at all (even from the public markets) then you "work for investors".

Can you see how this is theoretically true, but practically not as true?

But it does explain a lot of things in practice. Many developers will choose to use a technology not because it makes the end-product better for the end-user, but because it will make their resume more attractive for potential employers.

I don’t doubt that these developers exists, but I’ve never knowingly met one in 13 years of full time dev work.

You work for whoever is deciding how much money you get. In bigger companies that decision gets made many layers away from the end user.

I dunno, this feels like a technicality. Almost all of us work for a company, not the end user. We look at the company to figure out the balance it wants to maintain between user experience and maintainability. And companies are focused on the customer relationship, which is the sum of all experiences a customer has with the company over time.

And part of the way you can actually deliver a good customer experience, consistently, at scale, is by focusing on developer efficiency. To consistently deliver a great experience to customers in a world of constantly shifting customer expectations, you need to be able to ship features from design through delivery very quickly.

This means enabling your developers to be more efficient by designing products that are flexible. Maybe the user experience isn't 100% optimal for a given customer interaction, but the goal is to keep the sum of all interactions over time as high as possible.

I don't see your point.

Maybe the OP's argument doesn't fit every case, but there's many where it does (e.g. large companies). Calling it reductionist, doesn't necessarily invalidate it...

Maybe nobody works for the end user ever, but some people work more for the end user than others.

If you work for a web site that makes its money by lead gen or advertising, you're often working against the end user. This isn't necessarily true, it's just how the incentives will align.

If you sell SaaS to the enterprise, you're not working for the end-user, you're working for their boss, or whoever else is making the purchase decision.

If you're selling a product directly to end users, and usability is a factor in whether or not they choose pay you, that's a little closer to working for the end user.

And, best-case scenario, if you are the end-user, or your boss is the end-user, then you can truly be working for the end-user.

I suspect OP is referring to the Principal-agent problem: https://en.wikipedia.org/wiki/Principal%E2%80%93agent_proble...

Practically, end user interests are different then buying manager interest which are different then developers employer interests.

End user interests are different then buying manager interest: software that can tick all the checkbox, has all the features, but is hard and unpractical to use. Buying managers dont know they are buying crap and typically dont listen to low level employees who have to use the software. Instead, buying managers put pressure on whether checkboxes are ticked and price.

Company that develops software is interested in getting it out cheaper and in pretending checkbox is ticked. Where buying manager really want checkbox ticked, employer wants minimum cost way to do it. They are juggling multiple customers with incompatible requirements. Plus, managers are interested in their own departments and own empires in expense of overall product.

By the time developer gets assignment, end user matter only little. And developer does not have any way to even learn about his pain points and much less have time to do something about it.

Reply on news.ycombinator.com