Comment by trescenzi

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.

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

efficiency is the enemy of employment, no?

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.

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.

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

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

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.

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.

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.

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

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.

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

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

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.

[dead]

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

You need to be a product-minded engineer.

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

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.

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

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.

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.

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.

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.

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

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>

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

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

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

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.

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

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.