A lot of people make the statement that, at least in coding, “the problem-solving part is solved”. I’m pretty moderate on this. But I want to record my thoughts on this matter using something I observed in another industry (oil and gas) that I came from.

I used to study Seismic Processing/Imaging. While I was in college, I thought I was going to go out, write code, implement imaging algorithms, do all this esoteric signal processing stuff. I couldn’t have been more wrong. Turns out, the nature of the industry is different. The world doesn’t need more than 2 or 3 fast kernels for such engines. The world would be better off if those elites wrote them and everyone used them. The same dynamic happens in the software industry, of course. That is fine with me.

The real catch is this: the company I work for (the so-called “operator”), which owns the oilfield, outsources this kind of hardcore technical work to the service company. The operator has the company rep (me) take on the “project management” role in that matter. I used to say to the vendor, “You guys do all the work, I’ll do all the talk”. They liked it (but my manager probably wouldn’t).

What did I observe? There is a saying (from some computer scientists I can’t remember) that “You should understand one layer of abstraction below what you are operating on”. The major pitfall I observed is that the vast majority of people were told “not to bother” or “you will never have to do this kind of job yourself in life”. Something like 2 generations of people took that advice. Here’s the thing: you can tell the technical judgement in the meeting is all over the place. When the problem at hand does not fit common practice or the guideline, nobody knows what to do. There was no possibility of “thinking from first principles”.

I heard many times: “let’s do seismic reprocessing (and see what we will get)” and there goes another $2 Million USD. Sometimes the problem at hand will not be solved by that method, and you have to understand how the engine (the seismic processing/imaging engine) actually works to come to that judgement. Something like why wave-equation modeling helps your salt-related imaging problem while ray-based modeling doesn’t. If you’ve ever written the imaging condition code even once, you understand it.

That can get even worse; it opens the door for the bullshitter who may possess slightly more technical knowledge than average. And that person becomes a realistically unqualified gatekeeper. I saw such a scenario play out in real time. Totally disillusioned. Totally frustrated. I never knew that we could spend almost $10 Million on some projects that have practically no value, just because a guy will have something to talk about for the next one or two years. That’s how the institution degrades over time when we label the people who have an inclination toward technical understanding as “too academic” and write them off in the meeting (eventually, the average employees all just try to get things done and move on).

If, as a company or individual, we decide to “hand the AI the keys”, that’s when I get off the bus. I don’t know how the world will play out. As distraught as I feel, I guess I’ll continue sharpening my technical skills.