Hacker News Reader

Comment by ForHackernews | Hacker News Reader

> If software engineering goes the way of the dodo, I suspect most other white collar jobs are also displaced (anything done entirely on the computer, really).

Strongly disagree with this. In contrast to most jobs, software engineering is unusually self-contained, with short feedback loops and immediate validation. You (or Claude) implements the feature, you run the tests, you fix the bugs.

Most white collar jobs are nothing like this: lawyers have to prepare briefs (AI can help here) but they have to file briefs, they have to wait weeks or months for rulings, they have to argue in court. Marketing execs might spend millions preparing a new campaign, launch it for the holiday season, and it has to be right the first time. Most white collar work involves judgement, anticipation, and ambiguity in a way that software doesn't.

Software lets you guess-and-check over and over again until it works.

View on HN

> Most white collar work involves judgement, anticipation, and ambiguity in a way that software doesn't.

In my current position as a software engineer, this is MOST of the job.

I don't know what everyone else's role is like, but a software engineer that isn't dealing with those three items sounds more like a compiler.

"Most white collar jobs are nothing like this: [software engineers] have to [implement features] (AI can help here) but they have to [coordinate releases across teams], they have to wait weeks or months for [real-world usage to validate architectural decisions], they have to [defend technical decisions to stakeholders]. [Engineering teams] might spend millions preparing a new [platform migration], launch it for the holiday season, and it has to be right the first time. Most [software engineering] involves judgement, anticipation, and ambiguity in a way that [isolated code production] doesn't."

> You (or Claude) implements the feature, you run the tests, you fix the bugs.

...you then take it to the customer. And wait, and wait, and wait, and maybe eventually they'll get around to trying out what you created, and if you're lucky they'll even give you some feedback to loop back with to try again. They will only try your application a few times before giving up on you, so even if the feedback loop is immediate like you claim (its not; not even close), you aren't afforded many iterations. A software engineer's job is, of course, to get ahead of the customer using judgment, anticipation, and dealing ambiguity to minimize how many round trips are required to satisfy the customer.

If AI can replace the software engineer, why can't it replace all "white collar" work?

For the record, I don't think AI is likely to replace those parts of the work, at least not in the near term (15-20 years). But at many companies, the people interfacing with stakeholders or users — deciding what problems need solving and how to solve them — are product owners or project managers, not software engineers.

I think there will be a convergence where AI enables more POs to create software directly, and more SEs move up the value chain to work on product-level problem solving.

Product owners/managers typically act as the communication channel between customers and software engineers, but engineers are responsible for designing the software. It is they who have to use judgment, anticipation, and deal with ambiguity in order to find software customers want to use. The product owner/manager does not. They simply pass messages back and forth. Of course it is possible for one person to be both a product owner and a software engineer, but often the engineer is separated from having to play telephone tag with customers so that they can more efficiently focus on their primary task.

Perhaps you have confused software engineer with coder? LLMs are most definitely the final death knell for anyone still working as a coder, but that profession was on the way out for decades already. The earlier comment was clear about software engineer.

Yeah, most PO/PMs I've encountered know awfully little about the business processes, their constraints and complex interactions within their own product. They know quite a bit about priorities the various customers voiced, fancy stuff they'd like to demo on the next review or trade fair or customer relationship meeting, or new features they want to get customers interested in. But don't ask them how those features interact with others!

If you want to go into detail with that kind of stuff, your best bet is not the PO, but the lead engineer of the team. If the team was properly staffed, the lead engineer will have a solid knowledge of the business aspects of the product while at the same time being able to cross-reference that with the most important technical aspects.

LLMs will make more people into "lead engineers", even if all they're "leading" is the LLM agents and not other humans, as it was common before the LLM age. One of those will then emerge as the "lead lead engineer" who's going to lead the humans which in turn lead the LLMs. If it wasn't for the "engineer" in the meaning of "code monkey" dying out - which I also expect - we'd have to invent a new title, but I'm currently expecting this shift to go without that. It'll still leave some engineers who made themselves comfortable just churning out code that does whatever a ticket requests, without even understanding one iota of the business process behind the ticket, without a job, but that's the kind of "software engineer" who in my opinion shouldn't ever have taken up the profession anyway.

I don't think "software engineering" is a real thing. So-called software "engineers" do not practice engineering in the way that a mechanical engineer or a civil engineer does. Consider: How often do bridges collapse? How often do elevators plunge to their doom? How often does some critical piece of software utterly fail? [0]

> They simply pass messages back and forth.

So you claim. We're about to conduct a real-life experiment to see which is more valuable: passing messages back and forth to the computer, or passing messages back and forth to the customer.

[0] https://en.wikipedia.org/wiki/2024_CrowdStrike-related_IT_ou...

> I don't think "software engineering" is a real thing.

You don't think anyone designs software? It just magically appears?

> So-called software "engineers" do not practice engineering in the way that a mechanical engineer or a civil engineer does.

And? The dictionary defines engineer as someone who designs and builds things. It does not prescribe how the thing is designed.

> How often do bridges collapse?

Not often, but often enough to know that we still consider the designer to have been an engineer and not a project manager. I still have no idea where the idea that project managers do the design work came from.

> passing messages back and forth to the computer, or passing messages back and forth to the customer.

When AI can handle the judgment, anticipation, and deal with ambiguity neither are important. The customer will go straight to he AI. Hence why "white collar" jobs of all sorts are ultimately doomed. Unless you believe AI cannot reach that level, in which case software engineers will be fine, since that's the whole reason for their existence.

What we do see happening already is the decline of the project owner/manager role. More expensive money and technology increasing engineering efficiency has made it such that it is becoming hard to justify an assistant to bridge the telephone tag gap. That doesn't really affect engineers much, though. Before ZIRP allowed budgets for project managers/owners engineers also played that same role, so it is nothing unusual for them. Engineering getting secretarial assistants for a time, something historically reserved only for the upper brass, is but a curious aberration.

> You don't think anyone designs software? It just magically appears?

Do you actually write software for money?

Most commercial software is never designed, it evolves, over the course of repeated "agile" "sprints". Every two weeks, someone hacks together something that kinda-sorta works and then that is released.

Eventually (often many years later) the thing becomes so complex and unwieldy that it's impossible to add any more features, so someone gets angry, throws it away, and starts again growing a new monster.

> Do you actually write software for money?

No. I am paid to be involved in the software industry, but as an engineer, not as a coder. Writing software is not part of what I do. That is, to use your bridge analogy, for the construction crew.

> over the course of repeated "agile" "sprints".

It is true that not all engineers know what they are doing, are good at what they do, or bold enough to push back against out-to-lunch stakeholders.

> so someone gets angry, throws it away, and starts again growing a new monster.

I never understood that. Untangling the messes was always the fun part back when coding was still a job. But I don't really see any coders in industry anymore. Any last remaining ones I knew of have already been replaced by LLMs. LLMs will also happily untangle the messes, though, so still no reason to abandon code.

> Of course it is possible for one person to be both a product owner and a software engineer

This was the norm in every job I had from late 90s to around 2015.

Engineering Managers were responsible for both technical and business outcomes, and it worked fine.

The scrum solution of having from the business side acting as a literal "product owner" or "client representative" and giving feedback IMO was a much better direction that unfortunately companies have not followed.

Reply on news.ycombinator.com