[sebmellen]

The thing with a lot of white collar work is that the thinking/talking is often the majority of the work… unlike coding, where thinking is (or, used to be, pre-agent) a smaller percentage of the time consumed. Writing the software, which is essentially working through how to implement the thought, used to take a much larger percentage of the overall time consumed from thought to completion.

Other white collar business/bullshit job (ala Graeber) work is meeting with people, “aligning expectations”, getting consensus, making slides/decks to communicate those thoughts, thinking about market positioning, etc.

Maybe tools like Cowork can help to find files, identify tickets, pull in information, write Excel formulas, etc.

What’s different about coding is no one actually cares about code as output from a business standpoint. The code is the end destination for decided business processes. I think, for that reason, that code is uniquely well adapted to LLM takeover.

But I’m not so sure about other white-collar jobs. If anything, AI tooling just makes everyone move faster. But an LLM automating a new feature release and drafting a press release and hopping on a sales call to sell the product is (IMO) further off than turning a detailed prompt into a fully functional codebase autonomously.

[LPisGood]

I’m confused what kind of software engineer jobs there are that don’t involve meeting with people, “aligning expectations”, getting consensus, making slides/decks to communicate that, thinking about market positioning, etc?

If you weren’t doing much of that before, I struggled to think of how you were doing much engineering at all, save some more niche extremely technical roles where many of those questions were already answered, but even still, I should expect you’re having those kinds of discussions, just more efficiently and with other engineers.

[ragall]

> I’m confused what kind of software engineer jobs there are that don’t involve meeting with people, “aligning expectations”, getting consensus, making slides/decks to communicate that, thinking about market positioning, etc?

The vast majority of software engineers in the world. The most widespread management culture is that where a team's manager is the interface towards the rest of the organization and the engineers themselves don't do any alignment/consensus/business thinking, which is the manager's exclusive job.

I used to work like that and I loved it. My managers were decent and they allowed me to focus on my technical skills. Then, due to those technical skills I'd acquired, I somehow got hired at Google, stayed there nearly a decade but hated all the OKR crap, perf and the continuous self-promotion I was obliged to do.

[SoftTalker]

It seems that to some number of folks, "engineering" means "writing code."

[danans]

> I’m confused what kind of software engineer jobs there are that don’t involve meeting with people, “aligning expectations”, getting consensus, making slides/decks to communicate that, thinking about market positioning, etc?

I'd suspect the kind that's going away.

[bandrami]

In a lot of larger organizations there is a whole stable of people whose job is to keep stakeholders and programmers from ever having to talk to each other. This was considered a best practice a quarter-century ago ("Office Space" makes fun of it), and in retrospect I concede it sometimes had a point.

[pmontra]

In my case

* meeting with people, yes, on calls, on chats, sometimes even on phone

* “aligning expectations”, yes, because of the next point

* getting consensus, yes, inevitably or how else do we decide what to do and how to do it?

* making slides/decks to communicate that, not anymore, but this is a specific tool of the job, like programming in Java vs in Python.

* thinking about market positioning, no, but this is what only a few people in an organization have agency on.

* etc? Yes, for example don't piss off other people, help custumers using the product, identify new functionalities that could help us deliver a better product, prioritize them and then back to getting consensus.

[tayo42]

Ime a team or project lead does that and the rest of the engineers maybe do that on a smaller scale but mostly implement.

[sebmellen]

Well that’s why AI will not replace the software engineer!

[mrguyorama]

>If you weren’t doing much of that before, I struggled to think of how you were doing much engineering at all

Isn't like half of our industry just churning out JS file after JS file to yet again change how facebook looks?

[lich_king]

> making slides/decks to communicate those thoughts,

That use case is definitely delegated to LLMs by many people. That said, I don't think it translates into linear productivity gains. Most white collar work isn't so fast-paced that if you save an hour making slides, you're going to reap some big productivity benefit. What are you going to do, make five more decks about the same thing? Respond to every email twice? Or just pat yourself on the back and browse Reddit for a while?

It doesn't help that these LLM-generated slides probably contain inaccuracies or other weirdness that someone else will need to fix down the line, so your gains are another person's loss.

[sebmellen]

Yeah, but this is self-correcting. Eventually it will get to a point where the data that you use to prompt the LLM will have more signal than the LLM output.

But if you get deep into an enterprise, you'll find there are so many irreducible complexities (as Stephen Wolfram might coin them), that you really need a fully agentically empowered worker — meaning a human — to make progress. AI is not there yet.

[ozgrakkurt]

Thinking is always the hardest part and the bottleneck for me.

It doesn’t capture everyone’s experience when you say thinking is the smaller part of programming.

I don’t even believe a regular person is capable of producing good quality code without thinking 2x the amount they are coding

[SoftTalker]

Agree. I remember in school in the 1980s reading that a good programmer can write about 10 lines of code a day (citing The Mythical Man-Month) and I thought "that's ridiculous, I can write hundreds of lines a day" but didn't understand that's including all the time understanding requirements, thinking about design, testing, debugging, etc. Writing the code is a small portion of what a software engineer does.

[jama211]

Most people (and most businesses) aren’t making good quality code though. Most tools we use have horrible codebases. Therefore now the code can often be a similar quality to before, just done far faster.

[sebmellen]

As I wrote in a separate comment to someone who responded to me, there is a difference between:

  (a) thinking about, and deciding upon, what will be done, and 
  (b) the thinking that is required during implementation.

{type (a)} was always the majority of my time, but {type (b)} consumed a lot of effort, especially for languages or syntaxes I wasn't very familiar with. {type (b)} consumes very little of my time now.

[overgard]

> The thing with a lot of white collar work is that the thinking/talking is often the majority of the work… unlike coding, where thinking is (or, used to be, pre-agent) a smaller percentage of the time consumed.

WHOAH WHOAH WHOAH WHOAH STOP. No coder I've ever met has thought that thinking was anything other than the BIGGEST allocation of time when coding. Nobody is putting their typing words-per-minute on their resume because typing has never been the problem.

I'm absolutely baffled that you think the job that requires some of the most thinking, by far, is somehow less cognitively intense than sending emails and making slide decks.

I honestly think a project managers job is actually a lot easier to automate, if you're going to go there (not that I'm hoping for anyone's job to be automated away). It's a lot easier for an engineer to learn the industry and business than it is for a project manager to learn how to keep their vibe code from spilling private keys all over the internet.

[sebmellen]

> I'm absolutely baffled that you think the job that requires some of the most thinking, by far, is somehow less cognitively intense than sending emails and making slide decks.

OK, to quote you: WHOAH WHOAH WHOAH WHOAH STOP!

You've made a lot of assumptions.

I'm not saying that coding is not thinking. What I'm saying is this:

There is a difference between:

  (a) thinking about, and deciding upon, what will be done, and 
  (b) the thinking that is required during implementation.

In my experience, coding is at least 50/50 (even for the best developer) in the sense that figuring out how to structure and fix your code {type (b)} used to require very deep thinking. But then the other thinking time was spent on your system design/architecture {type (a)}, and not debugging type errors, etc.

AI has already changed that split. If you have a good test harness and problem definition, you can throw Codex at a really massive task and have it do quite well at the finer details of implementation.

Other white-collar office work, as stupid as it may be, will be a lot harder to automate because it is primarily the "thinking about what will be done" {type (a)} kind of work and not the "thinking that is done during implementation" {type (b)} kind of work.

If you haven't seen what I mean by "enterprise office work" it may be hard to grasp what I'm talking about... But thinking that people are just doodling around making slide decks or writing shitty emails is the wrong mental model for the breadth of non-technical work available in a large company.

[Kiro]

Our job is not the intellectual exercise you think it is. We're not smarter than anyone else and software development is not automatically more thought-intensive than other jobs. The fact that programming is the first job task to be fully automated says it all.

[8note]

> unlike coding, where thinking is (or, used to be, pre-agent) a smaller percentage of the time consumed. Writing the software, which is essentially working through how to implement the thought, used to take a much larger percentage of the overall time consumed from thought to completion.

huh? maybe im in the minority, but the thinking:coding has always been 80:20 spend a ton of time thinking and drawing, then write once and debug a bit, and it works

this hasnt really changed with Llm coding either, except that for the same amount of thinking, you get more code output

[sebmellen]

Yeah, ratios vary depending on how productive you are with code. For me it was 50:50 and is now 80:20, but only because I was a relatively unproductive coder (struggled with language feature memorization, etc.) and a much more productive thinker/architect.

[DaedalusII]

when the work involves navigating a bunch of rules with very ambiguous syntax, AI will automate them to the point computers automated rules based systems with very precise syntax in the 1990s

https://hazel.ai/tax-planning

this software (which i am not related to or promoting) is better at investment planning and tax planning than over 90% of RIAs in the US. It will automate RIA to the point that trading software automated stock broking. This will reduce the average RIA fee from 1% per year to 0.20% or even 0.10% per year just like mutual fund fees dropped in the early 00s

[arctic-true]

You could have beaten the returns of most financial professionals over the last several years by just parking your money in the S&P 500, and yet plenty of people are still making a lucrative career out of underperforming it. In some fields, “being better and cheaper” does not always spell victory.