I feel like we've been here before, and there was a time when if you're going to be an engineer, you needed to know core equations, take a lot of derivatives, perform mathematical analysis on paper, get results in an understandable form, and come up with solutions. That process may be analogous to what we used to think of as beginning with core data structures and algorithms, design patterns, architecture and infrastructure patterns, and analyzing them all together to create something nice. Yet today, much of the lower-level mathematics that were previously required no longer are. And although people are trained in their availability and where they are used, they form the backbone of systems that automate the vast majority of the engineering process.
It might be as simple as creating awareness about how everything works underneath and creating graduates that understand how these things should work in a similar vein.
Exactly right now, I am helping a big oil and gas company have a process simulation software to correctly converge on a big simulation. Full access to the source code, need to improve the Newton method in use with the right line search, validate the derivatives, etc.
I do think that for most of the people, you are right, you do not need to know a lot, but my philosophy was to always understand how the tool you use work (one level deeper), but now the tool is creating a new tool. How do you understand the tool which has been created by your Agent/AI tool?
I find this problem interesting, this is new to me and I will happily look at how our society and the engineering community evolve with these new capacities.
That's an interesting take - that you like the act of writing code. I think a lot of builders across a variety of areas feel this way. I like writing code too.
I've been experimenting with a toolchain in which I speak to text to agents, navigate the files with vim and autocomplete, and have Grok think through some math for me. It's pretty fun. I wonder if that will change to tuning agents to write code that go through that process in a semi-supervised manner will be fun? I don't know, but I'm open to the idea that as we progress I will find toolchains that bring me into flow as I build.
> It is worth noting that software salaries are artificially inflated HEAVILY due to a general unwillingness or lack of interest in hiring overseas developers.
Yes that's right; business hates saving money and loves hiring super expensive US talent.
The author's point is valid - innovation requires more knowledge as the tech that required less knowledge gets built. Today we face the "dual phd" problem, tomorrow the tri.
Obviously that is not sustainable. If society is to continually innovate, you need to stop building innovative systems and start growing them. One approach to this is true AI; not improving your NLP algorithm by 10% with 3x the math complexity IE the transformer model (quote taken from Michael Stonebrake, although he was referencing database research), but by building math that can grow math.
Hell even math is becoming a road block (try integrating THAT Bayes!). The point is as long as we must learn to build, we will run into a wall as humans have finite lifespans and don't scale horizontally (nor do they want to). If we build something that we can feed or point to un-wrangled, raw information into such that it can learn on our behalf, we might have a shot.
Now BACK to pumping out small improvement papers, innovators!
Yeah, if innovation requires people to receive more and more institutionalized education, then expect innovation to stop eventually.
From what I have seen cross disciplinary innovation usually happens because someone's interest in one domain has created a demand for a solution that can only be fulfilled with a different one. It's rarely about being skilled in both domains, it's about committing yourself to something a single domain expert has no interest in.
reply