Understanding the problem is more important than the solution

AI has completely devalued the solution. The wealth is in understanding.

Writing code, engineering code and solving problems and then solving them with code aren’t all the same thing. There three layers that map nicely onto what the basic layers of learning any topic. The basic stuff, the intermediate stuff and the advanced stuff. I didn’t pull these out of thin air. I’ve learned more subjects and skills that the average person and I’m also a teacher that qualified in 2010.

Teaching

I’ve taught at the FE college level (arboriculture and woodland management) and university level (HTML/CSS, typography and some Python / Django). I also spent some time doing technical training workshops in a freelance and employed capacity for Mozilla.

In any topic the basics are always easy to teach as most students are roughly in the same cognitive state. Rules, syntax, idiomatic patterns, tooling and basic debugging approaches are the playbook for teaching basics. The approach is quite behavioural. Do this, don’t do that kind of thing. It’s “drone over the woodland” level.

Intermediate gets a little harder because the each student is developing their own cognitive landscape. That is what makes the student intermediate. The approach switches to a more constructivist approach where it’s a conversation between teacher and student1. The dialogue informs both sides understanding. It’s less drone over the woodland and more “walking around the woodland”.

I’ve always struggled to teach advanced topics to groups. I suspect it’s because advanced topics are less about being “taught” and more about being “facilitated”. It is where teacher mode requires a mindshift into facilitator mode. An advanced student, by definition, already understands basics, interemediates and more importantly has a scaffold over the entire domain from which they can traverse the subject. Their advancement largely depends on their intrinsic motivation and willingness to explore and execute in very specific areas. If intermediate was walking around the woodland then advanced is at the “inspecting the soil with a microscope” level.

The aim of any teaching or learning endeavour is to creating understanding to such a depth that you find yourself able to navigate your comprehension the topic and navigate Blooms Taxonomy.

Blooms Taxonomy - a surprisingly accurate way to visualise learning

I don’t think I’d bother teaching code in todays world of AI because LLMs are very effective teachers. They can be good facilitators if you can prompt in such a way to prevent the LLM from giving the solution, but in sharing it’s understanding. It’s not easy.

Teaching a person to understanding to the level of “create” on Blooms Taxonomy is a two way street. Initially it’s mostly the teacher whilst the drone flies over the woodland and covers the basics. Then it’s more 50/50 as you walk through the woodland with the student. You can guide them but you’re in a dialogue. Learning depends on it. But at the advanced level, it’s all 90% student and 10% facilitator.

“Hey teach, this black Mycorrhizal hyphae suggests honey fungus”, “yes it does, but what role does it play?”. To put that in tech product terms it is something like this “If we refactor the ten functions where On(2) operations become On we can improve response time by 98% and reduce the cluster size and CPU size”, “Sounds great, how much money do you think we’ll save…”.

Solutions

In the pre-AI days solutions were expensive. They cost engineering salaries. At some point product managers became a thing and to me, it was to ensure the engineers understood (or at least had a chance to understand) the problems that their code was solving2. A big side-effect of making the solution for any engineer was that they banked the cognitive learnings. It was the waste of the operations. As far as the salary went however, they were being paid to solve the problem. For a long time the engineer could have their cake (cognitive learnings) and eat it in the form of pleasing their corporate overlords in delivering the solution.

Here’s the thing though and this should come at no surprise, solutions are now like ideas - largely worthless and ten-a-penny. Brutal reality is hard, but I find some comfort in the fact it’s the worst possible way to look at things.

Consider this again:

“If we refactor the ten functions where On(2) operations become On we can improve response time by 98% and reduce the cluster size and CPU size” hopefully, you, the engineer

“Sounds great, how much money do you think we’ll save”. finance person who also influences layoffs at the board level

This kind of work used to be the remit of seniors and staff engineers. It’s big picture from small picture kind of thing. It’s terrifying to juniors and a challenge to mid-levels. It’s also not the kind of thing that pre-AI engineers would spot when they were focused on the handful of codebases they “owned”.

But now solutions are easy-ish. They are one £200 a month subscription to whatever AI tool you use3. Enter stage left AI layoffs.

Any engineer who wasn’t thinking like the engineer I’ve described above is toasted. No longer do engineers get to have their cake and eat it. The job now is about deep understanding and as I outlined above, that responsibility is on you.

Understanding

This is where I think the wealth of the future is. The hypothesis fits in with hiring freezes on everything but seniors and staffs once the juniors and mids have been tossed re-allocated into the segment of society that is the green badge wearing “open to work” crowd4.

Here’s what I’d do if was inside a company right now or what I’ll do at my next gig. Going back to the three layers of learning I introduced at the start. These rules apply to any role.

The Basics

I’d be armed with the company provider AI tool from the start5 and I’d ingest as much sales info as I could and understand who the customers are. Where the market fit is and how much is left to be captured. Who are the competitors? what state are their accounts in?6 I’m looking for weaknesses and opportunities to strategically exploit.

I’d also ingest as much of the codebase as I had access to within my role. Where is stuff deployed and how? Where can I see the metrics on resource usage, where are most faults coming from? What’s the most stable code and what codebases are rarely touched and why and what are the most frequently touched and why.

You can do this mostly alone because it’s the basics. I’m getting a layout of the corporate woodland and commercial canopy cover.

Intermediate

Now I know the basics, I’m now onto the bits where I need to build relationships and have dialogues. I’m walking around the woodland. I’m asking questions like “why this kind of commercial agreement”, “whats the common reason for failing to close”, “whats the most common reason for pro-longed talks when closing deals”. “Where does the smell in the codebase live according to you and what would you love to do about it”.

I’m aiming to apply and analyse my knowledge of the basics to build a world model I can use to inform where I go on the advanced stuff. The LLM is still there but it’s largely my own prompted critic or a wearer of a given hat colour. I’m using the people in the company to walk me around the corporate woodland.

It’s a dialogue and relationship building.

Advanced

At this level I’m evaluating and creating solutions that ideally are rooted in at junctions between understanding their pain points and the companies objectives. Most will be thrown away or rejected but that’s fine they’re cheap. The wealth is where the understanding is.

My solutions are small and targeted. I’m down in the dirt of the woodland affecting soil chemistry to promote a certain flavour of commercial ecology. Solutions at this level are informed by the basic and intermediate knowledge.

Full Circle

Solutions are now cheap. They are one prompt away. If your entire value in any role was “solution” only then I don’t know how to describe your future without the words “bleak” and the phrase “change required”.

In todays AI driven landscape, “understanding” is where the wealth is at. “Taste” has been thrown around a lot as a term, but it’s only part of the picture. Knowing how to cultivate “understanding” and get it naturally regenerating in the company is that wealth is a great tool to arm yourself with. That prompt requires understanding and that’s on you.

  1. This is why teaching is a great way to learn – but you have to be open to it. ↩

  2. Obviously, there’s much more to an engineer role (performance, maintainability, security etc) and product manager (market fit, priorities, privacy, strategy into tactics etc) role, I’m just defining a single interface between the two roles. ↩

  3. So is chaos by the way. These tools are not 1:1 replacements for engineers despite what boards and executives think. I’d say they’re a between at best a 3:1 replacement. One seriously knowledgeable engineer could in theory do the work of three not so knowledgeable workers. Less fun and more stress for that engineer though. ↩

  4. A segment that currently includes me, but I wasn’t made redundant. I left my CTO/CIO role of my own free will to go learn about trees and woodlands for a few years. I’m still finding overly difficult to get a solid offer though. Perhaps I like freelance engineering too much. Topic for another day. ↩

  5. No shadow AI please. AI governance is hard enough without someone coming in with zero respect for infosec/privacy and AI compliance and sending confidential company info into their personal LLM tool which then uses that for training. ↩

  6. If you’re in the UK companies house is an EXCELLENT tool for guessing the health of a company ↩