I think people who understand how computers and software work will be better positioned to generate those new ideas.
A software engineer isn't going to come up with a revolutionary new mining technique or robot or something. But someone who works at a mine might. Previously those people would go find a software engineer to try and validate their idea. Now they will go to AI
I dunno. Maybe I'm wrong, but I just don't see software engineers as being the best people to generate a lot of new ideas for domains outside of software engineering
If I was going through university right now I'd want to double-major in computer science and something else.
Domain expertise is good, but coupled with software knowledge is almost a superpower, when it comes to software projects.
I have seen projects that took 6 months when done by 1 expert + 1 engineer taking mere weeks when done by a single person who were good at both, in a competitor.
I see two issues with this however, which probably need to be addressed somehow:
- 1 is that, similar to tech, the positions may be seen as cush/low-effort... Like they did half the real work and are going to phone in the rest with LLMs. (Maybe this is already an existential problem, idk.)
- 2 is that domain knowledge is still difficult to aquire... (which may affect whether this manifests, not necessarily that older engineers like myself can jump in)
Nevertheless, if the pattern of dual expertise were to become common, it could open up a lot of opportunities, and is a positive vision of the future, which I think we pretty desperately need.
We need to experience and see how the world actually works, the pain people are actually experiencing. I deeply believe we build better software that way.
Have a software engineer working for a mining company that's a good candidate to drag out into the field for a bit? Get 'em out there, encourage them to ask tons of questions.
Real example: my wife is a nurse who works for an insurance company to coordinate care for injured workers to help maximize their recoveries. I hear a ton about the stuff she has to do, and just having her tell me about how things work has given me a glut of ideas of how I could help her bypass all the administrivia so she can focus on helping the folks she's really passionate about helping. Wouldn't have had any idea about any of this, otherwise. Unfortunately for her, I don't work for her company so can do nothing about it, but the ideas!
90% of the time when you really break down the "real" problems. You learned they aren't gon a be fixed by fucking software.
Less software coupled with operational changes would have helped many organizations I've witnessed across my career, but that's not politically palatable in a lot of places.
For example, when I was working in a finance team, I'd come across all sorts of situations where someone had a task of "once a week, download this data from this application, apply the following transformations, then upload the results to this other application". Anybody reading this site would think "ah, that's like a dozen lines of code! We should automate that". But that thinking is incredibly rare outside of our field.
On the flip side of that, you'll have the people who think they can simply buy software that will solve all their problems. "No, ma'am, buying a fancy new Spend Management System will not magically make everyone know or care about the difference between 'GL 10754 - Employee Appreciation: Meals' and 'GL 10822: Employee Meals (Discretionary)'".
My take on it is that the ability to recognize automatable problems boils down to 1) having an intuitive understanding of algorithmic reasoning ( this solution comes in 4 parts, the first part can be divided into 3 separate problems, which...) 2) having an up-to-date understanding of the extant capabilities of computers. 3) having the kind of bull-headed hubris that makes someone say "Sure, we currently do it this way, but I can do it better".
And at the end of the day, those features end up meaning you need some sort of engineer.
I do think perhaps LLMs could give product-minded developers more time to think about and refine those ideas, though.