[trescenzi]

> At scale, even your bugs have users.

First place I worked right out of college had a big training seminar for new hires. One day we were told the story of how they’d improved load times from around 5min to 30seconds, this improvement was in the mid 90s. The negative responses from clients were instant. The load time improvements had destroyed their company culture. Instead of everyone coming into the office, turning on their computers, and spending the next 10min chatting and drinking coffee the software was ready before they’d even stood up from their desk!

The moral of the story, and the quote, isn’t that you shouldn’t improve things. Instead it’s a reminder that the software you’re building doesn’t exist in a PRD or a test suite. It’s a system that people will interact with out there in the world. Habits with form, workarounds will be developed, bugs will be leaned for actual use cases.

This makes it critically important that you, the software engineer, understand the purpose and real world usage of your software. Your job isn’t to complete tickets that fulfill a list of asks from your product manager. Your job is to build software that solves users problems.

[Aurornis]

> The load time improvements had destroyed their company culture. Instead of everyone coming into the office, turning on their computers, and spending the next 10min chatting and drinking coffee

One of my early tasks as a junior engineer involved some automation work in a warehouse. It got assigned to me, the junior, because it involved a lot of time working in the warehouse instead of at a comfortable desk.

I assumed I’d be welcomed and appreciated for helping make their work more efficient, but the reality was not that simple. The more efficient I made the technical part of the job, the more time they had to spend doing the manual labor part of the job to keep up. So the more I reduced cycle times, the less time they had to sit around and chat.

Mind you, the original process was extremely slow and non-parallel so they had a lot of time to wait. The job was still very easy. I spent weeks doing it myself to test and optimize and to this day it’s the easiest manual labor job I’ve ever worked. Yet I as the anti-hero for ruining the good thing they had going.

[rahimnathwani]

  The more efficient I made the technical part of the job, the more time they had to spend doing the manual labor part of the job to keep up.

Imagine you like writing code, and someone automates that part of the job so you have to spend more of your time reviewing PRs and writing specs...

[SJMG]

What a great comparison; I've never thought of it this way. It's obviously not perfect since the automation is so temperamental shall we say, but this does give me more empathy for the countless workers whose jobs have been re-natured by technology.

[isk517]

From their prospective, the efficiency increases and more gets done, but the hours and wage stay the same and the number of co-workers may decrease.

[einsteinx2]

I don’t even have to imagine it, you just described my job now that we have LLMs.

[sd9]

I believe that was the point

[einsteinx2]

Reading it back now it does seem pretty obvious. That’s what I get for commenting right after waking up!

[sd9]

All good, it's a Monday morning

[lazylizard]

efficiency is the enemy of employment, no?

[regularfry]

The amount of work expands to fill the available labour. All other things being equal, at least. Which they aren't, but it's a usefully wrong model.

[intended]

There’s many praises to sing about efficiency, (and I don’t take your 1 liner as a position against it). That said, efficiency, job creation, and underemployment overlap quite a bit.

There’s far more scientists, programmers, and doctors today than farmers and stablehands.

At the same time, people who lost manufacturing jobs to automation and outsourcing, did not get jobs with equivalent pay and growth.

Human brains do not get retrained very easily, and so every technological revolution is a boon to those who grasp it, and a challenge for those who invested their time in skills no longer in demand.

[wbl]

Nursing massively expanded but they didn't want to take it.

[psunavy03]

You can't expect factory workers to magically turn into nurses. Sure, people can learn new things, but human skillsets are not entirely fungible.

[vbezhenar]

One of my work involved automating some process which was very manual and tedious, took a lot of time and there was dedicated employee for that process. After I did the project, it turned out that this job wasn't necessary anymore and that employee was fired. I felt uneasy about the whole situation.

[wafflemaker]

In Norway there's laws for that, but other places do it even without them. You just retrain the person to do something else. He might take a job of a temp that was hoping to get a fast contract (instead of a few weeks at a time during trial period). Other than that, it's good for the person (not losing job) but also for the company - you get a tried person with good work ethics that comes on time. It's not zero cost to find somebody like that.

[rincebrain]

A lot of places in the US are not, in my experience, that intelligent about hiring people.

Or, say rather, the externalities of the cost of hiring are not imposed on the people choosing to fire, directly, so they can say they "improved efficiency" by firing someone, and then the people trying to find reliable labor do not experience any improvement that might have been available by migrating the person.

[red-iron-pine]

agreed. the "lump of labour" fallacy is a thing -- the idea that there are always more bodies and that it's trivially easy to hire, train / get up to speed, and work them.

in practice hiring and firing is expensive and often very risky. Bjorn the office worker may now be redundant and have a room temperature IQ but he's shown he'll show up on time, sober, and is liked by his coworkers enough, so throwing $5k to retrain him may be a far, far smarter investment then blowing $7k to hire a rando for another position...

[fragmede]

Yeah the bar for competent is surprising hard to hit. A human being that shows up on time and it's reliable, doesn't have a problem with drugs or alcohol, or has a sick family member and just needs an advance. Good help is hard to find!

[eloisant]

If you're only getting those kind of candidates, then your job offer isn't attractive enough.

[red-iron-pine]

then the pendulum swings the other way and now I have ruthless mercenaries chasing $$$ who will jump at the first opportunity

and not every job needs to be top-shelf.

Betty in Accounts-Payable just sorta needs to be there and not screw up too often. I don't need a super-star, and if we have to move her to another part of Accounting that's fine; I'll save my money for a solid CPA or two, etc.

[yamakadi]

I understand the rest, but an otherwise capable person with a sick family member does not clear the bar for competent? Saddening if that’s where we are as a society.

[strken]

I think the key part of that sentence was "...and just needs an advance", implying that they're going to take the job, ask for a cash advance for a (possibly fictional) sick family member, and immediately quit.

[virtue3]

It’s hard for some people to understand that situation until they are in it. Unfortunately.

Totally agree with you.

[_heimdall]

Why do the laws exist if its better for (almost) everyone involved? Without the laws why would people not do it that way if its the better approach?

[abdullahkhalids]

Many laws solve the problem of high initial cost dissuading globally good actions. Laws forcing everyone to buy insurance, for example. It's very easy to see that where such laws don't exist, almost no one buys insurance, making everyone worse off.

This is also an example of the same kind of law.

[_heimdall]

Insurance is an interesting example, I would have expected one that causes more direct harm to others like drunk driving.

How are we all worse off when fewer people have insurance?

[wafflemaker]

Norway has very strict pro-workers laws in general, it's just one facet of them. One Norwegian explained it to me like that: in the late '60 when Norwegian oil industry started developing, workers realized that they can incur great losses on the companies if they organize/unionize and strike together. They used that as a leverage to both change their contracts (to include paid sick leave and such) and also get better working conditions (Norwegian platforms have both better safety and on platform to on land ratio).

And later other trades did the same. Some of the things in contracts trickled down to the law. But still some laws apply only to companies where at least a certain % (is it 50%?) are unionized.

The general picture is more or less like that, but please verify the details.

[Panzer04]

And they will have to go find another job instead. It feels weird but this is how we raise living standards - removing human labor from production (or, in other words, increasing the amount produced per human)

Automation is a game of diffuse societal benefit at the expense of a few workers. Well, I guess owners also benefit but in the long term that extra profit is competed away.

[elmomle]

That's a highly idealized view that I hope we can agree doesn't completely jive with what we see in society today. If a small number of shareholders reap all the profits, the vast majority of the benefit from automation flows to them, and it's even possible for the lives of average people to get worse as automation increases, as average people then have less leverage over those who own the companies.

[rictic]

Inflation adjusted incomes are up in the US across the board. The affordability problem is largely the price of housing because it's illegal to build.

[rswail]

Incomes are up, but the expenses are up as well, especially with the upcoming changes in healthcare for people on the ACA.

Also any comparison of wage growth vs corporate profit growth over the last 30 years shows that wages have not kept pace with the increase in productivity.

So incomes are only just barely keeping up, when they should be booming.

[xboxnolifes]

How can inflation adjusted income be up and there still be an affordability crisis?

[samiv]

Yet more and more people are struggling to afford even basic necessities and one can only dream of the luxury of the 50's when a single working class person was able to pay and cover for housing, car, family and even have enough for leisure. Where has all the economic surplus gone? Right...to the bourgeois, the capital owning class that exceedingly extract more and more of the wealth generated by the society.

[powerapple]

because the developing world is producing a lot of things except the housing.

[phyzix5761]

On average, most large cap stocks (MSFT, GOOG, AAPL, etc) are owned by millions of retail investors through 401Ks, mutual funds, ETFs, and direct ownership.

[BobbyJo]

Median net worth at 40 years old in the US is less than 150k. Most Americans benefit very little from share prices rising, at least directly.

[couchridr]

Of the US stock market half is owned by 1%.

https://fred.stlouisfed.org/series/WFRBST01122

[wisty]

> If a small number of shareholders reap all the profits

It's not greater profits but lower costs (and prices) that matter here.

[adrianN]

Lower costs only translate into lower prices if sufficient competition is there. That is not true for many markets

[eru]

Everybody can be a shareholder in a publicly traded company. It's pretty easy.

If you want to spin up some conspiracy theory about elites snatching up productivity gains, you should focus on top managers.

(Though honestly, it's mostly just land. The share of GDP going to capital has been roughly steady over the decade. The share going to land has increased slightly at the cost of the labour share.

The labour share itself has seen some shake up in its distribution. But that doesn't involve shareholders.)

[rswail]

Everyone with excess disposable income can be a shareholder in a publicly traded company.

The oligarchy of the CxOs and boards and cross-pollination has led to concentration of the rewards of companies into the their hands, compared to 40 years ago.

All the productivity gains have not gone to labor, its predominately gone to equity and then extracted via options and buy backs to avoid tax which means public service and investment has gone down.

The craziness of the USG borrowing to fund tax cuts is the ultimate example.

[droopyEyelids]

There have been times historically where that was true but all productivity gains have been captured by the .1% for the past few decades.

[Rzor]

And someone don't need to look further than this quite interesting report by the Rand Corp: https://www.rand.org/pubs/working_papers/WRA516-1.html

We document the cumulative effect of four decades of income growth below the growth of per capita gross national income and estimate that aggregate income for the population below the 90th percentile over this time period would have been $2.5 trillion (67 percent) higher in 2018 had income growth since 1975 remained as equitable as it was in the first two post-War decades. From 1975 to 2018, the difference between the aggregate taxable income for those below the 90th percentile and the equitable growth counterfactual totals $47 trillion.

[WalterBright]

Income is the wrong measurement. Total employee compensation is the more accurate one, and averages around 145% of salaries.

Total employee compensation includes things like the value of employer provided health insurance.

[eru]

What's your evidence for that?

[Cthulhu_]

It's narrow vs wide views. Wide views, automation and the like has improved the economies massively. But narrow views, people have lost their jobs, had to retrain and basically restart their career, and some never found another job.

This isn't just automation btw, but also just business decisions, like merging companies, outsourcing, or moving production elsewhere - e.g. a lot of western European manufacturing has moved eastwards (eastern Europe, Asia, etc). People who have a 30+ years career in that industry found themselves on the proverbial street with another 10+ years until their retirement, and due to trickery (= letting their employer go bankrupt) they didn't even get paid a decent severance fee.

[_heimdall]

I've not seen a correlation between automation and wealth, though there is an extremely string correlation between energy use and wealth.

I don't think its automation that increases living standards. We increase living standards by consuming more energy, and that often comes along with increasing the amount of costs we externalize to someone else (like pollution or deforestation, for example).

[red-iron-pine]

> It feels weird but this is how we raise living standards

yeah but it's clear that we're not doing that, and are arguably going the other direction as hard as possible

[j16sdiz]

> removing human labor from production

Karl Marx would argue this evil because this take away the value and job satisfaction from the labour.

https://en.wikipedia.org/wiki/Marx%27s_theory_of_alienation

[eru]

You might notice that Karl Marx isn't exactly the pinnacle of economics.

Quoting Marx is a bit like quoting Aristotle or Ptolemy.

[yujzgzc]

"Laid off" may be more appropriate than "fired", but in essence, removing the need for costly labor is often the main "value" of any technology. Society as a whole comes out ahead from it, I mean for all the ice transporters and merchants put out of a job by electric refrigeration, and all the sailors put out of a job by modern cargo ships I think we're better off for it. But at the individual level it does make one uneasy about the prospects of individuals affected by it. My personal conclusion is that people have a personal duty to anticipate and adapt to change, society might give them some help along the way but it doesn't owe them that their way of life will be maintained forever.

[samiv]

This is putting the apple cart before the horse.

Economy should be a tool for the society and to benefit everyone. Instead it's becoming more and more a playground for the rich to extract wealth and the proletariats have only purpose to serve the bourgeois lest they be discarded to the outskirts of the economy and often to the literal slums of the society while their peers shout "you're just not working hard enough".

[Spooky23]

Very true. We waste alot of valuable labor on “software engineering” that is grossly inefficient. Capital gets allocated to these so called startups that are incredibly inefficient.

[taftster]

This says a lot as relating to the rise of AI and the fear of job loss. There's going to be displacement in areas we can't predict, but overall it might very well just lead to leveling up the entire workforce.

[Nevermark]

> it might very well just lead to leveling up the entire workforce.

How could that possibly work?

At some point I could see white collar work trending down fast, in a way that radically increased the value of blue color work. Software gets cheaper much faster than hardware.

But then the innovation and investments go into smart hardware, and robotics effectiveness/cost goes up.

If you can see a path where AI isn't a one-generational transition to most human (economic) obsolescence, I would certainly be interested in the principle or mechanism you see.

[gnatolf]

Craftsmen will have a resurgence, that's probably a 'leveling up' in terms of resilience against AI takeover. There's just no way of automating quite a few of the physically effective crafts.

[wholinator2]

I agree. I was brought on as an intern to do automation for a business team. The company had built this gargantuan complex "programming tool" to help the boomers who'd been there for 30 years adjust to the new world (a noble endeavor for mortgage holders without college degrees, i believe). I was brought in to basically fuck around and find little things to optimize. In 2 months I wrote a python script to do about 50% of the teams work near instantly.

They had layoffs every year and i remember when the "boss's boss" came to town and sat at our table of desks. She asked me and i excitedly told her about my progress. She prompted how i felt about it and i nearly said "its very easy as long as you can program". But mid sentence i saw the intense fear in the eyes of the team and changed subject. It really hit home to me that these people actually were doing a useless job, but they all had children who need insurance, and mortgages that need paying. And they will all be cast out into a job market that will never hire them because they came on at the very end of not needing a college degree. The company was then bought by a ruthless and racist "big man investor" who destroyed it and sold it for parts. But my manager did somewhat derogatorily refer to the only programmer near them as "the asian".

[shermantanktop]

> refer to the only programmer near them as "the asian"

If they ever hired a second one, they’d have to learn actual names. Or maybe it would be “the asian” and “the new asian”!

[nicbou]

How do you feel about the whole thing years later?

[anilakar]

Back in the day one company had a dedicated copier operator who was very unhappy after a Xerox service tech did away with the job by enabling the network printing and scan to email functions. The customer had upgraded their old copier out of necessity but had never changed their workflow.

[Cthulhu_]

This will not be unusual for any kind of software engineering work to be honest. A big chunk of work in B2C companies has to do with customer support, for example; building websites, apps, writing content, chatbots, etc with the objective being that people do not call customer support, because people on phones don't scale very well. And the other part is that when they do call, that the CS agent can address the issue quickly and has minimal administrative overhead.

But it's a weird one, because it costs millions to build features like that.

[tonyedgecombe]

I had that on my very first project. I couldn’t understand why the people on site were so hostile to me. Afterwards I was talking to the salesman about this and he told me they were all fired when the project went live.

[wiether]

> So the more I reduced cycle times, the less time they had to sit around and chat.

Couldn't help but imagining Darryl getting mad at you.

Thanks for the story!

[zwnow]

Yup same story here, also warehouse optimization. I was the reason the employees got new scanners and oh my... the scanners didn't have a physical keyboard. Now all the 50yo+ would have to aim on a touch display which is apparently impossible.

Also we had to introduce some fixed locations and storage placement recommendations. Our storage workers almost revolted. After a few months it settled though.

[pif]

Yous story is not about optimization: it is about change imposed to people who did not request it, nor felt the need of it.

[zwnow]

It 100% was about optimization. Introducing new devices, with more capabilities (storage place recommendations for example), that weren't 10 years old and broke every 2 weeks is optimizing.

[vkou]

> The more efficient I made the technical part of the job, the more time they had to spend doing the manual labor part of the job to keep up. So the more I reduced cycle times, the less time they had to sit around and chat.

The faster the LLM spits out garbage code, the more time I get to spend reviewing slop and dealing with it gaslighting me, and the less time I get to spend on doing the parts of the job I actually enjoy.

[pif]

Mandatory reference: https://thedailywtf.com/articles/Classic-WTF-The-Indexer

[agobineau]

insane mindset. This kind of thing is why there is no industry left in anglosphere outside US

[pbhjpbhj]

Insane mindset that people should work modestly, get paid modestly and live in the fruits of a wealthy society? As opposed to breaking their backs to make a boss even wealthier?

The efficiencies are always to the benefit of the wealthy, the wage gap grows. You work hard, you still get fired.

Cap top wages to 5x the lowest, companies can't own housing except socially beneficial housing, individuals get 2 house maximum.

[kyrra]

This was well talked about in Hyrums Law, which came from a Googler as well.

https://www.hyrumslaw.com/

> With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody.

[mjevans]

I believe it.

I also believe an off the shelf example of how to use the library correctly will save everyone a lot of pain later.

[shermantanktop]

I always strongly suggest sample code to people designing new APIs. Can be a very revealing exercise.

[jacquesm]

For close to a decade my business revolved around a common bug in both Microsoft and Netscape, the dominant browsers of the day. With every release we were thinking 'this time they'll fix it' and that would have caused us some serious headaches. But they never did!

[Donald]

I was curious what the commenter's business was, and found this post about HTTP protocol latency: https://jacquesmattheij.com/the-several-million-dollar-bug/

[Lammy]

What a cool guy https://jacquesmattheij.com/domains-for-sale/

[usefulposter]

>FREEDRUPALWEBSITEHOSTING.COM

Yeah that's not gonna work nowadays.

>DOWNLOADWEBCAM.COM

Is that like Download More RAM?

>BROWSEHN.COM

Hey, I'm browsing that place right now!

>MUZICBRAINZ.COM

This sounds 100% legit no virus softpedia guaranteed.

[rswail]

Worked on public transport ticketing (think rail gates and stuff) with contactless last 30 years, when guys would tell me that the software was "ready", I'd ask:

> Is it "stand next to the gates at Central Station during peak time and everything works" ready?

We were working on the project from a different city/country, but we managed to cycle our developers through the actual deployments so they got to see what they were building, made a hell of a difference to attitude and "polish".

Plus they also got to learn "People travel on public transport to get somewhere, not to interact with the ticketing system."

Meant that they understood the difference just 200ms can make to the passenger experience as well as the passenger management in the stations.

[nickjj]

> "People travel on public transport to get somewhere, not to interact with the ticketing system."

I really like this line because it applies to so many things we build.

Public transport is an interesting one because it applies to so many things. If you need to use it but can't depend on it, it's a huge stress creator and time waster. Suddenly you need to pad times by hours to ensure you don't miss your appointment.

Notice the words there, "miss appointment" and not "miss bus or train". The outcome is what matters, not the transport mechanism.

Or, maybe you're traveling in a foreign country. Having every car in the metro display the line in a digital way showing the previous stops, current location and next stops in English is huge for eliminating doubt. Having the audio in multiple languages and clear is important too because maybe you're sitting down and everyone is standing in front of you so you can't see the display clearly. Having a non-digital map as a backup on the wall in case there's a hardware failure is a good idea too.

Thinking "no one needs any of that waste because they can just use their phone" is the wrong mode of thinking. Maybe there's no service because you're underground or maybe that person's eSIM isn't hooked up yet or isn't working. These are real problems.

The travel experience outcome in the grand scheme of things matters a lot. It could mean having a smooth trip or a questionable experience. It could be the difference between recommending the country to your friends and family or not. Suddenly it affects tourism rates at a global scale. Maybe not a lot, but it has an impact.

[Foobar8568]

Thales?

[embedding-shape]

> Your job isn’t to complete tickets that fulfill a list of asks from your product manager. Your job is to build software that solves users problems.

Very important with this, is that not every work place sees your job as that, and you might get hired for the former while you believe it to be the latter. Navigating what is actually expected of you is probably good to try to figure out during the interview, or worst case scenario, on the first day as a new hire.

[anymouse123456]

This is huge advice for people who want to climb a given career ladder.

The overwhelming majority of organizations will say they want you focused on real user problems, but actually want you to make your boss (and their boss) look good. This usually looks more like clearing tasks from a list than creating new goals.

At Google there are both kinds of teams.

[kqr]

Lehman talked about the developer-software-user triad. Each of the three have a different understanding of the problem to be solved.

Developers misunderstand what the users want, and then aren't able to accurately implement their own misunderstanding either. Users, in turn, don't understand what the software is capable of, nor what developers can do.

> Good intentions, hopes of correctness, wishful thinking, even managerial edict cannot change the semantics of the code as written or its effect when executed. Nor can they after the fact affect the relationship between the desires, needs, and requirements of users and the program […] implementation; nor between any of these and operational circumstances – the real world.

https://entropicthoughts.com/laws-of-software-evolution

[brunoborges]

> This makes it critically important that you, the software engineer, understand the purpose and real world usage of your software. Your job isn’t to complete tickets that fulfill a list of asks from your product manager. Your job is to build software that solves users problems.

You actually described the job that Product Managers _should_ be doing: "understand the purpose and real world usage of your software".

[rswail]

Everyone in the team should have that.

Obviously at different levels of focus and completeness, but the Product Manager is supposed to be communicating in both directions and they rarely do, they just take the feature list and tick them off.

Telling the customer that they can't have something or it needs to be different and having their trust that you aren't doing it just to cut corners is what good Product Managers do.

[lanstin]

As a developer of new things, if you allow someone else to capture this value from you, you become fungible; additionally, for your group, having technology designed to solve problems without grounded but expansive ideas of how much is possible, limits your team's ability to the mundane rather than the customer delighting. Some product folks have internalized the possibilities but some haven't.

[woooooo]

Ideally its a mix, a good PM should understand the customer/market more than the developer has time to do, and then they can have conversations with devs about how to most effectively fill needs. In reality, these PMs seem more like unicorns rather than expected table stakes, but hey.

[ehnto]

I worked on some software that provided results to some calculations to general web users, not experts. The calcs were done in miliseconds.

We had to introduce an artificial delay of ~30 seconds to make it seem like it was taking a while to calculate, because users were complaining that it was too fast. They either didn't believe we really did the calcs, or they thought the system must have broken so they didn't trust the results.

[astrange]

This is one reason UIs have animations added, the kind that technical users like to complain about or remove. By making things feel more physically grounded they prevent users from getting lost and confused and give them more intuition about things.

In your case you could show more intermediate values, graph things, etc.

[iosguyryan]

I often chuckle when (our) animations may have more complex math that consume more resources than the awaited logic/call that they gate.

[taklimakan]

Yes nice but also very naive. Most developers do not have that level of ownership, nor know how their users interact with the software. Their job is precisely to complete tickets from the product manager. The product manager is the one who should be in charge of UX research and “build a software that solves users problems.” Sure, in abstract that is the mission of the developers too, but in any structured (and hopefully functional) team, product strategy is not what the software engineer should be concerned with.

[jaredsohn]

Good software engineers are concerned with product strategy. They might not be able to decide things but they can help inform product about options because they're closer to actually building things.

If you just implement product tickets you'll probably get replaced by LLMs.

[jeanlou]

You need to be a product-minded engineer.

[hyperadvanced]

It’s crazy how fast the tables turned on SWE being barely required to do anything to SWE being required to do everything. I quite like the 2026 culture of SWE but it’s so much more demanding and competitive than it was 5 or 10 years ago

[rswail]

Developers shouldn't test, they should throw it over to QA who will test it precisely to meet the defined requirements.

The Product Manager's job is to communicate the customers needs to the developers/designers and the developers/designers constraints back to the customers.

It's up to the developers and designers to understand those constraints and make sure they are communicated back.

[diydsp]

Ive observed a modern trend of little to no QA. Managers and CTOs insist developers can test their own systems. Maybe this makes more sense in the early phases of product development where I find myself lately? Seems to capture a lot of dev's time.

[cm2012]

I have never seen a pure ticket based / zero ownership approach ever work.

[mangamadaiyan]

Tell us you've never worked in a faang without telling us.

[cm2012]

It doesnt work in faang either, which is why they are wildly slow to produce software. They can just print money when running at 10% efficiency.

[anhner]

It's wild to me that a lot of people consider that SWE need to be knowledgeable in business requirements and interact with clients all day.

Just try to imagine construction workers doing the same thing when building a skyscraper. Instead of laying bricks, mortar and beams, now every worker loses 1-2 hours each day asking each stakeholder separately what they want, if they like how it's going so far etc. And then make changes to the layout when the clients ask! What kind of monstruous building will emerge at the end?

Edit: if you downvote, at least provide a counter argument. Or is etiquette dead?

[ilaksh]

Construction worker is a spectacularly bad analogy for software engineer.

The architect and structural engineers design the building well in advance. Construction workers are mainly arranging materials according to a prewritten design.

Software engineers are not given specs that are equivalent to blueprints. They are given requirements or user stories. Then they have to flesh out the final real specification in place.

And then from the specification, decide how to implement it, which is not decided at all ahead of time.

Also, what software engineers are building is almost always somewhat novel, at least dramatically more novel than a typical building. It very often involves some type of research task, even if that is just sifting through components and configuring them.

There is much more room in software engineering for 1) miscommunication or poor communication of users needs, 2) substantive tradeoffs discovered based on technical details or 3) subtle contradictions in requirements from different stakeholders discovered during implementations, 4) better understanding of requirements by users discovered during prototyping, etc.

[rswail]

They should have a general idea of what they are building and why, in exactly the same way as a construction worker.

That doesn't mean they spend all day asking stakeholders what they want. It means that when there is a choice and the stakeholder has to make a decision, the developer should be able to understand some of what the stakeholder is looking for so that they can recommend a direction.

Sure, a carpenter is just putting up a wall, but if they're experienced and they see that there's going to be a joist that is going to block some feature, they should be able to point that out to the architect or builder or client.

[anhner]

Absolutely agree, but in practice this means devs are expected to sit in meetings with clients multiple times a week just to make sure everyone is on the same page. This also means that either all the devs on the team are required to be present, wasting time, OR that devs meet with stakeholders individually and knowledge ends up decentralized.

And secondly, I think that devs are expected to know WHY "all frobs are percurators" instead of just knowing that they are. Besides keeping up to date with all the tech stack, you are now expected to keep up with all the business details of your client (client which might change in a year or two).

[rswail]

The other argument about this is whether or not an SWE is a fungible resource.

When you're doing a construction schedule, you might have a pool of carpenters, pool of electricians etc. They can be assigned to the different jobs as a fungible resource, a different carpenter can take over a task just like one power drill can take over another.

We all know that no matter how much ceremony and process, SWEs are not equal, so you can't just move them around randomly.

[qwertytyyuu]

If upvoting doesn’t require justification neither should downvoting.

But let me try to express why people disagree. Change is software compared to physical systems is comparatively incredibly cheap. Unlike in building something known, design at the start of a software project is unlikely to be the one the client actually wanted nor would be the one that is one going to be build. Or at least it shouldn’t be.

The “brick-laying” part of software isn’t the hard part. Depending on want to analogise as “brick-laying” in software, that part could automated. Push to main and the deployment pipeline runs tests, makes sure things are working and voila! You have a new “house”. If its ugly or falls apart in software, easy , just revert to the previous version and its like nothing happened. Client wants a try different layout, it can be done affordably.

Most of the time in software engineering you don’t know exactly how to do something, there is always a degree of discovery, experimentation and learning involved. Heck the client probably isn’t expressing what they want clearly enough, and probably will at some point change their mind. Thus interacting with clients and customers is valuable.

[anhner]

I appreciate the reply.

> If upvoting doesn’t require justification neither should downvoting.

I disagree, since downvoting is not equal to upvoting. First off, not everyone has the ability downvote (at least on hackernews). Second, upvoting usually means you agree with something, while not agreeing should be reserved to the action of NOT upvoting. This is how most social media works. Downvoting should be reserved for something that should not belong on the thread.

Regarding the topic of the discussion, I agree that "builders" should be proactive and knowledgeable about the system that they are building, but the "chief architect"/project manager should be the intermediary between them and the clients, if for nothing other than being a single source of truth.

[WalterBright]

> The negative responses from clients were instant.

Back when I was designing TTL circuits, the TTL specifications gave a min and max time for the delay between the inputs and the outputs. I was instructed to never rely on the min delay, as the chips kept getting faster and the older, slower replacement parts will not be available anymore.

The IBM PC was frustrating to many hardware engineers, as too much software relied on timing loops and delays in the original design, which made it difficult to make the hardware go faster.

[WalterBright]

On older cars, like my '72 Dodge, the system voltage varied between 12 and 18 volts. But the dash instruments needed 5 volts. This was achieved with a clever "buzzer" circuit using an electromagnet and contacts. The circuit would open when it was above 5 volts and close when it was below. This created 5V, but was a noisy 5V.

Many people decided to improve this with a semiconductor voltage regulator, which would nail the output at 5V. But the instruments wouldn't work! The problem turned out to be the instruments relied on the noisy 5V to "unstick" the needles on the instruments.

So the electronics guys had to add a "noise" circuit to the voltage regulator circuit.

P.S. Watch an old aviation movie, where the pilot getting ready to fly would tap the instruments to unstick them.

[mike_hearn]

Ah, the Turbo Button!

I think by the time I got my first IBM PC the button no longer did anything, but it was still there on the case for some reason. I remember pushing it repeatedly, puzzled that nothing went faster.

[WalterBright]

I have one in my car. It doesn't do anything, either.

[TacticalCoder]

Craziest I got was users complaining their laptops were getting too hot / too noisey because I correctly parallelized a task and it became too efficient. They liked the speed but hated the fans going on at full speed and the CPU (and hence the whole laptop) getting really warn (talking circa 2010). So I had to artificially slow down processing a bit as to not make the fans go brrrrr and CPU go too hot.

[matvore]

If the fan was turning on where it wasn't before, it seems like cooling was once happening through natural dissipation, but after your fix it needed fans to cool faster. So the fix saved time but burnt extra electricity (and the peacefulness of a quiet room.)

This is pretty easy to understand IMO. About 70% of the time I hear machine's fans speed up I silently wish the processing would have just been slower. This is especially true for very short bursts of activity.

[AlotOfReading]

Obviously the proper solution is to adjust your system thermal management / power targets, but you can force programs to slow down yourself by changing the scheduling policy:

    chrt -i 0 <cmd>

[matvore]

  > Obviously the proper solution is to adjust your system thermal management / power targets,

My point is that I understand the users' complaint and request for a revert, not that I can't address this for my own machines. The proper solution for non-technical people is to ask the expert to fix it, which may include undoing the change if they were never interested in the process finishing faster anyway.

I did solve this problem once upon a time by running the process in a cgroup with limited CPU, though I later rewrote my dwm config and lost the command, without caring enough to maintain the fix.

[AlotOfReading]

    The proper solution for non-technical people is to ask the expert to fix it

This isn't something the developer has any meaningful control over. Scheduling policy is the responsibility of the host system, running faster usually consumes less power, and the developer has no way to know when an operation will kick in the undesirable fans because it depends on what else the system is running. The best they can do is a checkbox that runs the old code or adding sleep calls instead

[astrange]

You probably wanted a low thread priority/QoS setting. The OS knows how to run threads such that they don't heat up the CPU. Well, on modern hardware it does anyway.

[adrianN]

I’d expect any os worth it’s name to run threads in a way that minimizes total energy not fan noise.

[astrange]

People with desktop computers don't care about total energy, but they do care about fan noise for overnight maintenance tasks.

[rswail]

The OP did say this was circa 2010. So we're talking 15 years ago.

[lukeschaefer]

Absolutely - one of my favorite bug with users was an application we had made in which the loading of a filtered view was so slow, that results would come in one-at-a-time, such that clicking 'select all' would only select those ones. When this was removed, users complained until we added shift-clicking to select groups of items

[soleveloper]

This is a perfect example of a "bug" actually being a requirement. The travel industry faced a similar paradox known as the Labor Illusion: users didn't trust results that returned too quickly. Companies intentionally faked the "loading" phase because A/B tests showed that artificial latency increased conversion. The "inefficiency" was the only way to convince users the software was working hard. Millions of collective hours were spent staring at placebo progress bars until Google Flights finally leveraged their search-engine trust to shift the industry to instant results.

[devsda]

> Your job isn’t to complete tickets that fulfill a list of asks from your product manager. Your job is to build software that solves users problems.

The main benefit of understanding the purpose and real world usage of your software is that you can ask the right questions while planning and implementing the software/feature/bug-fix and that you don't make any wrong assumptions.

In a situation where you have conflicting requirements or concerns regarding the change, you'll eventually be hit with "PM knows the product & customer better" or the explicit "your job is to deliver what is asked".

[regular_trash]

Before I got into software development, I worked at a company doing technology-adjacent things. Nothing too fancy, but I got to improve a lot of things just by knowing a little powershell.

One day, a senior developer there - a guy very fond of music - was showing me his process for converting a text file into SML. His process consisted of opening two notepads: one with an SML template block, and one with the text file to be converted. He then proceeded to convert each line into SML by copying the prefix tags and postfix tags and pasting them around each line.

I wrote a powershell script in front of him to automatically do that and save an entire days worth of work, and he just stared at me. I had removed the one really mindless part of his job that he could use as an excuse to listen to a TON of music. Needless to say, he never used the script.

Reflecting on this, I feel fortunate to have had this experience early on - it really helps put things into perspective - perceived improvements to anything depend entirely on the workflow of the people impacted.

[kshacker]

1. I do that once in a while. There is only so much thinking you can do in a day or a week that you need some mindless activity

2. Today morning, fresh in the new year after a break -- I took a day off on the 2nd, and I last worked on December 19th, I am not able to get into the zone, and luckily a training email popped up -- spent an hour doing that. Normally my manager would have had to remind me.

[SanjayMehta]

I optimised out some redundant processes on a unix system and sped up boot time.

But I had to release dummy processes which just printed out the same logs, as management didn't want to retrain operators or reprint the documentation.

Mid 90s. All training and operations manuals were hard copy.

[codingbbq]

Rightly said.

I spent good amount of time cleaning up 15 year old codebase and removed almost 10MB of source code files which was being part of production build and it was never used. This helped reduce the build time.

I thought I'd get appreciated from everyone in the team, but it was never acknowledged. In fact my PM was warried and raised an alarm for regression. Even though I was 100% confident that there would not be any regression, the QA and PM got annoyed that I touched a working software and they had to do extra work.

I then posted on LinkedIn about this achievement to get my share of appreciation. :)

[NamlchakKhandro]

LoL managers.

[moinahmad]

This list really stands out because it treats engineering as more than just producing correct code. It focuses on producing clarity that others can build on. The idea that clarity matters more than cleverness isn’t about style. It’s about reducing risk when someone else has to fix or extend the code at an odd hour. That’s often the difference between technical efficiency and the contribution a team can reliably depend on.

[Jean-Papoulos]

>Your job isn’t to complete tickets that fulfill a list of asks from your product manager. Your job is to build software that solves users problems.

While I agree in spirit, when you reach a certain amount of people working on a project it's impossible. The product manager's job is to understand real user problems and communicate them efficiently to the engineering team so the engineering team can focus on engineering.

[nightpool]

No. The product manager has to understand the big picture, but when you're working on a team that big, it follows that you're going to be working on a product big enough that no one person is going to be able to keep every single small detail in their mind at once either.

You wouldn't expect the engineering manager to micromanage every single code decision—their job is to delegate effectively so that the right people are working on the right problems, and set up the right feedback loops so that engineers can feel the consequences of their decisions, good or bad. In the same way, you can't expect the product manager to be micromanaging every single aspect of the product experience—their job is to delegate effectively so that the right people are working on the most important problems, but there are going to be a million and one small product decisions that engineers are going to have to have the right tools to be able to make autonomously. Plus, you're never going to arrive at a good engineering design unless you understand the constraints for yourself intuitively—product development requires a collaborative back and forth with engineering, and if you silo product knowledge into a single role, then you lose the ability to push back constructively to make features simpler in places where it would be a win/win for both engineering and product. This is what OP means when they say that "The engineer who truly understands the problem often finds that the elegant solution is simpler than anyone expected".

[kranke155]

If it’s impossible to understand users problems then something has gone horribly wrong.

[jeanlou]

I was told at university that every software system is a socio-technical system. Keeping a mental note of that fact has helped me throughout my career.

[hbs18]

So what is the correct solution to that specific problem then, adjust loading time per customer?

[damethos]

Probably just let them vent until they adjust their habits and just chat with their co-workers, without the need to use this as an excuse. Then, they can enjoy the fast loading times :)

[wahnfrieden]

Why would the boss accept that? They automated the work to eliminate employee downtime. If the employees were upset to lose their chatting time then presumably they lack the agency to choose chatting over work duties when they’re unblocked. The only way to help them in that situation is to organize them

[Gigachad]

Because the 10 minutes of chatting has value too. Which is why corporations make you spend so much time on team building exercises and axe throwing.

[rswail]

No, that's HR justifying its existence.

Plus that's for higher stature service based roles, not warehouse logistics.

It's also mostly bullshit.

Teams work because they have the right combination of skills, both personal and technical, high EQ and IQ, leadership and ownership.

Whether or not you fall backwards into a team's arms or have to participate in childish games is not relevant.

[Gigachad]

For most people, liking and being friends with the people you work with is a huge factor in how much you like the job and are willing to stay. Most of the times I’ve left a job it’s been triggered by the people I liked talking to leaving and the remaining team members being dull and anti social.

[ramijames]

Ignoring the users is the correct solution. Defining company culture through software loading is ridiculous.

[DenisM]

What about the second order effects?

Ignoring the customers becomes a habit, which doesn’t lead to success.

But then, caving to each customer demand will make solution overfit.

Somewhere in there one has to exercise judgement.

But how does one make judgment a repeatable process? Feedback is rarely immediate in such tradeoffs, so promotions go to people who are capable of showing some metric going up, even if the metrics is shortsighted. The repeatable outcome of this process is mediocracy. Which, surprisingly enough, works out on average.

[conception]

Steve Jobs has a bunch of videos on creating products- https://youtu.be/Q3SQYGSFrJY

Some person or small team needs to have a vision of what they are crafting and have the skill to execute on it even if users initially complain, because they always do. And the product that is crafted is either one customers want or don’t. But without a vision you’re just a/b testing your way to someone else replacing you in the market with something visionary.

[DenisM]

This requires correct vision + enough influence to execute.

This is not a repetitive process. It’s pretty hard to tell apart a visionary from a lunatic until after they deliver an outsized success.

[rawgabbit]

First define who the real customer is.

Second define what the real problem is.

Third define a solution that solves 80 percent of their problem.

None of this is intuitive or obvious. It may not even be technically feasible or profitable.

[jerf]

Everyone's brain builds a model of the world.

One of those higher levels of maturity that some people never reach is to realize that when your model becomes incorrect, that doesn't necessarily mean the world is broken, or that somebody is out to get you, or perhaps most generally, that it is the world's responsibility to get back in line with your internal model. It isn't.

This is just people complaining about the world not conforming to their internal model. It may sound like they have a reason, but the given reason is clearly a post hoc rationalization for what is basically just that their world model doesn't fit. You can learn to recognize these after a while. People are terrible at explaining to each other or even themselves why they feel the way they feel.

The solution is to be sympathetic, to consider their input for whether or not there is some deeper principle or insight to be found... but also to just wait a month or three to see if the objection just dissolves without a trace because their world models have had time to update and now they would be every bit as upset, if not more so, if you returned to the old slow loading time. Because now, not only would that violate their updated world models, but also it would be a huge waste of their time!

Thoughtful people should learn what a world model violation "feels like" internally so they can short-circuit the automatic rationalization circuits that seem to come stock on the homo sapiens floor model and run such feelings through conscious analysis (System 2, as it is sometimes called, though I really hate this nomenclature) rather than the default handling (System 1).

[andsoitis]

> But how does one make judgment a repeatable process?

Principles can help scale decision-making.

[dchftcs]

Their bosses are likely happier for the lower downtime required to run the software anyway.

[notatoad]

The solution is to accept that this isn’t a software development problem, and to remove yourself from the situation as painlessly as possible.

If a manager wants to structure a morning break into their employees’ day, they can do that. It doesn’t require a software fix.

[toxik]

Completely insane, who doesn't get to have coffee breaks without manager permission? Surely any org that treats its employees as adults would not have this problem.

[wahnfrieden]

Organizing workers

What’s the alternative? Ask the boss for favors? That’s what organizing is for

[alex1138]

https://xkcd.com/1172/

[thelastgallon]

Hyrum's Law: https://www.hyrumslaw.com/

[johannes1234321]

That is https://xkcd.com/1172/

[qmr]

Please stop abusing co-opting and denigrating the title of engineer.