A while back I found myself in an argument with several of my peers about a deceptively simple question:
What is the most important skill in our industry right now?
Not the most fashionable. Not the most hireable this quarter. The most important one, the one you would tell someone to build if they only got to build one.
Unsurprisingly, there were a lot of opinions in that room. And I want to walk through them properly, because the interesting part of this story is not who won. Nobody won. The interesting part is what happened when I looked at all four answers side by side afterwards and noticed they were secretly the same answer wearing different clothes.
Four Answers In One Room
”AI, obviously”
This one came first, and honestly it came fastest. AI is taking the world by storm. It is in every product roadmap, every job description, every investor deck, every conference keynote. If you cannot work with these tools in 2026, you are working at a genuine disadvantage against people who can.
I do not think this answer is wrong. I have written a fair amount about what AI actually does and does not do, including why leading AI agents turned out to be almost the same job as leading people, and why the honest position on AI lives in the middle rather than at either loud extreme. I build with these tools every day and pay for them out of my own pocket. So I am not about to argue that AI skill is unimportant.
It is important. Hold that thought.
”Data, because AI runs on it”
The second answer arrived as a rebuttal to the first, which is the best kind of argument.
AI runs on data. Every model is a compressed opinion about a dataset. Every recommendation, every forecast, every “the system says” is a data pipeline with a nice face painted on it. And long before the current wave, the entire analytics and business-intelligence industry was already built on the same foundation. If you cannot reason about data, about where it came from, what it is missing, what it quietly encodes, then you cannot reason about anything downstream of it either.
Fair. Data deserves a seat at the table. Hold that thought too.
”Domain knowledge”
The third answer was the one that made the room go quiet for a second, because it is the one engineers historically underrate and then get humbled by.
How exactly are you going to build a good application for a business you do not understand? You can write flawless, beautifully-tested, perfectly-architected code that solves the wrong problem. I have watched it happen. I have done it. The gap between “the ticket said this” and “the business actually needed that” has probably destroyed more engineering effort than every bug in history combined.
So yes. Domain knowledge belongs in the conversation. Hold that one as well.
”The ability to learn”
And then somebody said it: the most important skill is the ability to learn.
I will be honest. In the moment, that sounded like the soft answer. It has the texture of something you put on a motivational poster. It is the kind of thing that sounds unarguable precisely because it is vague, and answers that cannot lose an argument usually have not really entered one.
But then we took a step back. And when I looked at the other three answers again with that fourth one in mind, something uncomfortable happened.
Every Answer Collapsed Into the Same Answer
Go back through the list and ask one question of each: how do you get this?
Take AI first. It is taking the world by storm today, exactly the way previous technologies did. The games industry had its moment. The internet had a much bigger one. Mobile. Cloud. Each one arrived, reorganised how people worked, and then quietly stopped being a specialism because it became the floor everybody stands on.
AI will come and stay. I have no doubt about that. But “come and stay” is not the same as “and nothing will follow it.” Tomorrow there will be something else, something I probably cannot name yet, and we will all have to catch up to it the same way we caught up to this. Whatever you learned about prompting, agent orchestration, or model selection in 2026 has a shelf life. Not zero, since the underlying judgement transfers, but the specifics expire, and faster than any of us would like.
So AI skill is not a destination. It is a thing you learn, and then keep learning, and then eventually relearn from a different angle when the ground moves. The learning never stops.
Take data second. Every piece of tech runs on data, that part is true. But data is not something you have; it is something you have to understand. Before you can do anything useful with a dataset you have to learn what it means, who produced it, under what conditions, with what gaps, with what quiet biases baked in from the collection process. That understanding is never transferable wholesale. The next dataset, in the next domain, at the next company, will hide its lies somewhere completely different.
Which means data skill resolves into: you have to learn, again.
Take domain knowledge third, and it is even more obvious. We in tech juggle many domains in a career, sometimes several in a single year. Insurance one year, logistics the next, healthcare after that, education after that. I have personally bounced across more business domains than I would have predicted when I started, and each time the process is the same: arrive knowing nothing, ask embarrassing questions, build a mental model, get it wrong, fix it.
Domain skill is not a thing you possess. It is a thing you acquire, over and over, on arrival.
Which means domain skill resolves into: you have to learn, again.
Three different answers. Three different camps in the room. And underneath all three, the same machinery running quietly in the basement.
A Detour Through Fire
Here is the part of the argument that genuinely stuck with me, and it starts with a word.
Research. Look at how the word is built: re-search. To search again. To go looking for something that is already there.
That framing is worth sitting with, because we usually talk about research as though it produces things out of nothing. It does not. Research finds. The thing was already in the world, indifferent to whether we had noticed it yet.
Now apply that to the oldest example there is.
Many people will tell you that without fire there would be no human civilisation, and I think that is close to correct. Fire gave us cooked food, which gave us more calories from the same effort. It gave us warmth, which gave us range. It gave us light, which gave us hours that were previously useless. It gave us protection. Later it gave us pottery, then metal, then everything that follows from metal, which is, roughly, all of engineering.
But notice what fire is not. Fire is not a human invention. Fire was there long before us. Lightning struck trees and they burned, entirely without our involvement or permission. It was not as though humans arrived first and fire showed up later as our clever idea.
What actually happened is smaller and far more impressive: we learned to use it.
That is the whole leap. Not creation, but comprehension. Somebody worked out how to carry it, how to feed it, how to keep it alive overnight, how not to die from it. And from that single act of learning, everything else unspooled. Learn fire, and eventually you learn to smelt. Learn to smelt, and you learn metallurgy. Learn metallurgy and you get tools, ploughs, machines, engines, and quite a lot further down that line, the rack of servers humming in somebody’s spare room.
Electricity is the same story. It was not invented; it was always running through the sky. We learned it. Mathematics is arguably the same. There is a genuine philosophical debate about whether we invent maths or discover it, and I notice the “discover” camp has never lacked for defenders.
So when I say learning is universal, I do not mean it as a compliment we pay to studious people. I mean something closer to a mechanism: the entire distance between what exists and what humanity can use is covered by learning. Everything we have ever gained, we gained by understanding something that was already sitting there.
That is a strange, slightly humbling thought to hold while arguing about whether to learn this month’s framework or the fundamentals underneath it. But it reframes the question in a way I found hard to shake.
Then The Argument Died
And then, having gone somewhere genuinely interesting, the conversation took a strange turn and stalled out completely.
We stopped there. Everyone kept their original opinion. Nobody moved.
It took me a while afterwards to work out why a conversation with that much in it ended so flat, and I think I know now. We never defined the word.
The entire argument ran on an unexamined assumption that everyone in the room was using “learning” to mean the same thing. We were not. Not even close.
Because in practice, a lot of people carry an unspoken definition roughly like this: learning is when you take a course, a class, or a lesson. Structured. Scheduled. Delivered by someone designated as a teacher. Ending, ideally, with something you can put on a CV.
And under that definition, a very large amount of human learning is silently disqualified. Getting wrecked by a production incident at 2am and understanding your system properly for the first time? Not learning, that is just a bad night. Spending two hours on a call with a client and finally grasping why their industry works the way it does? Not learning, that is just a meeting. Shipping something that failed and working out exactly why? Not learning, that is just a failure.
If that is your definition, then “the ability to learn” sounds like a soft, school-shaped answer, and of course you will rank it below AI or data or domain. You have quietly excluded most of what learning actually is before the argument even started.
So the argument was never going to converge. Four people were defending four positions against a word that was doing four different jobs.
That bothered me enough to go and look it up properly.
So What Is Learning, Actually?
The framing I found most useful comes from the lifelong-learning world, the one UNESCO has spent decades building policy around. Their exact wording varies across documents, but the substance lands consistently at something like this:
Learning is the lifelong process of acquiring new knowledge, skills, behaviours, values, and attitudes through experience, study, or instruction.
I want to pull that apart clause by clause, because every part of it is doing real work, and at least three of those parts directly contradict the schoolroom definition most people are secretly running on.
“Lifelong.” Not a phase. Not a stage you complete before your career starts. There is no point at which the process is declared finished and you move on to the applying-what-you-know part of life. The word is doing something specific here: it is denying that learning has a terminus.
“Process.” Not an event. Not a certificate. A process is something ongoing, something with a rate rather than a completion. You can be mid-process for years.
“Acquiring new knowledge, skills, behaviours, values, and attitudes.” Look at that list. Only the first two items, knowledge and skills, are what a course is designed to deliver. The other three are not curriculum material at all. Behaviours change through repetition and consequence. Values change through experience, usually uncomfortable experience. Attitudes change when reality contradicts you convincingly enough that you cannot argue back. None of those come with a syllabus, and all of them count.
“Through experience, study, or instruction.” Here is the clause that settles the argument. Three routes, listed as equals. Instruction is the teacher-led route everyone already accepts. Study is the self-directed route most people also accept. And experience, meaning living through something and coming out different, is listed right there beside them, with no asterisk, no demotion, no note saying it counts for less.
Which means the failure counts. The 2am incident counts. The client conversation counts. The project that went sideways and taught you something no course would have covered counts.
It is an extremely broad definition. And I think the breadth is the point, not a weakness. Anything narrower would have to start excluding things that visibly, obviously change what a person can do.
The Great Ones Were All Learning Machines
Once I accepted the broad definition, I started noticing something about nearly every figure I admire, across completely unrelated fields and separated by two thousand years.
They were all, in their own way, learning machines.
Caesar: learning from what went wrong
Caesar is remembered for winning, which slightly obscures how often things did not go to plan and how quickly he adjusted.
His first crossing into Britain in 55 BC is the cleanest example. It was, by any practical measure, a mess. The fleet was badly suited to the landing, the weather and tides did damage he had not planned for, and the expedition achieved little beyond proving it could be done at all. A year later he came back, and the difference was not courage, it was correction: different ships built for the conditions, a larger force, better preparation for the specific things that had gone wrong the first time.
The same pattern shows up in Gaul. The defeat at Gergovia was real and it stung. What followed at Alesia was not a repeat of the same approach with more enthusiasm; it was a fundamentally different operation, with siege lines facing both inward and outward to handle the exact problem that had previously undone him.
That is not natural genius. That is somebody who treats a bad outcome as information and builds the next plan out of it.
Napoleon: reading as an engine
Napoleon is the clearest case of study as raw fuel, particularly in his youth. As a young, unremarkable, financially constrained officer, he read relentlessly: history, mathematics, artillery theory, geography, the campaigns of the commanders who came before him, and a great deal that had no obvious application to his job at the time.
He also took notes obsessively. Not passively reading, but processing. Later in his career he famously travelled with a portable library, which tells you the habit never switched off even when his days were about as full as a human day can get.
You can hold every possible opinion about what he did with that education, and people do, strongly, while still noticing the mechanism underneath. The intake came first. By a lot.
Bill Gates: the tech case
And then somebody much closer to our own field, because tech is the domain where standing still is most obviously fatal.
Gates is well known for a reading habit that has continued for decades, and for the “Think Week” practice of deliberately withdrawing with a stack of papers and books to read and think without interruption. Read that as a scheduling decision rather than a personality quirk and it becomes genuinely instructive: he blocked time for learning, at a point in his life when his time was worth an almost comic amount of money.
That is the tell. When learning is treated as something you do with leftover hours, it does not happen, because there are never leftover hours. When it is treated as work that earns its place on the calendar, it happens.
And in tech specifically, this is not optional. To be in this industry is to adapt, constantly, to things that did not exist when you learned your current stack. The person who stopped learning ten years ago is not merely behind; they are working in a field that has quietly rearranged itself around them.
Let Me Test the Definition
Definitions are cheap in the abstract. So let me run the cases: the ones that actually came up in the argument, plus a few that should have.
For each one: is this learning?
1. Taking a lesson, a course, or a degree
Obviously yes. This is the case nobody disputes, the prototype everyone’s mental image is built from. You sit with someone designated as a teacher, they have structured the material, and you come out knowing things you did not know before.
It has real advantages worth naming. Someone has already worked out the order things should be learned in, which is a genuinely hard problem and one you cannot solve yourself while you are still a beginner. There is a syllabus, so you can see the shape of the territory. And there is usually some form of assessment, which, whatever you think of exams, is at least a check against comfortable self-delusion.
It also has a limit: it teaches you what someone decided in advance you should know. Which is enormously valuable, and is not the same as what your actual situation will demand.
2. Taking your questions to a mentor or coach
Absolutely yes, and for many people this is the highest-leverage form on the list.
The difference between this and a course is the direction of travel. A course pushes a curriculum at you. A mentor responds to your specific question, from your specific position, with your specific constraints attached. That is enormously more efficient per hour, because none of it is spent on material you already have or do not yet need.
There is a second thing a good mentor gives you that no course can: they can see the mistake you are about to make, because they made it. Most of the value of experience is knowing which paths dead-end. That knowledge is difficult to write down and remarkably easy to transfer in conversation.
3. Reading books, news, magazines, or watching video
Yes. This is “study” in the definition, and it is the most democratised form of learning that has ever existed.
What reading does especially well is give you coverage: a broad map of what exists, what is being tried, what other people have already learned the hard way. You will not achieve depth this way, and anyone who tells you they did is describing a familiarity they have not tested. But you cannot go deep on something you have never heard of, and broad reading is how you find out what is out there to go deep on.
The failure mode here is worth stating plainly: consumption feels like progress. Watching a two-hour video on a framework produces a warm sense of competence that evaporates the moment you open an empty file. Reading counts as learning, but reading instead of doing is a very comfortable place to get stuck.
4. Working with a peer or a client and talking about their business
Yes, and this one is interesting, because almost nobody logs it as learning.
When you sit with a client and they explain how their business actually works, not the tidy version in the requirements document but the real version with the exceptions and the workarounds and the one process that exists purely because of something that happened years ago, you are acquiring domain knowledge. That is precisely the thing my peer nominated as the most important skill. And it is arriving through conversation, with no teacher, no syllabus and no certificate at the end.
The same applies to a peer. Pair on something with somebody who thinks differently to you and you will pick up their habits, their shortcuts, their instincts about what to check first. Some of the most durable things I know came from watching how somebody else approached a problem, not from anything they explicitly taught me.
If this does not count as learning, then the entire mechanism by which anybody acquires domain expertise does not count, which is absurd.
5. Writing a reflection
Now it gets interesting, and this is where I would expect the schoolroom definition to start objecting, because there is no new input. Nobody taught you anything. You are just sitting with what already happened.
But this is where the input becomes yours. Experience does not automatically convert into learning. Plenty of people accumulate ten years of it and end up with one year repeated ten times, because nothing was ever examined. The conversion step is reflection: going back over what happened and asking what it actually means, what you would do differently, what the pattern was.
Writing forces that conversion in a way that thinking about it does not, because writing is intolerant of vagueness. A fuzzy thought survives indefinitely in your head. It dies the moment you try to put it in a sentence and discover you cannot finish it.
I will be direct about my bias here: a large part of why this blog exists is that writing these posts is how I find out what I actually think. The published article is a by-product. The reflection is the point.
6. Running an experiment and writing up the result
Yes, and this is learning in its most rigorous form.
You form a hypothesis, you construct a situation that could disprove it, you observe what actually happens, and you record it. That is the scientific method, scaled down to fit a working week. Building a proof of concept is this. Benchmarking two approaches instead of arguing about them is this. Spiking an unfamiliar library for a day to find out whether it survives contact with your actual use case is this.
What makes it powerful is the write-up. An experiment you ran and did not record is an experiment you will run again in eighteen months, having forgotten the result. The report is what turns a one-off finding into something you and everyone around you can build on.
Much of what I have documented on this blog, including the home data centre work, the proof-of-concept blueprint, and the platform decisions, is exactly this. Run it, find out, write it down.
7. Getting something out of a failure
Yes. And if the definition allows only one of the items on this list, it should probably be this one.
Failure is the most information-dense event available to you. Success tells you that something you did worked, without specifying what. You might have been right, or you might have been lucky, and the two feel identical from the inside. Failure tells you precisely where your model of the world was wrong. It hands you the exact coordinates.
It is also, obviously, the least pleasant way to learn anything, which is why so many people take the information and throw it away in favour of an explanation that protects them: the requirements were unclear, the deadline was impossible, the client changed their mind. Sometimes all of that is true. It is also, consistently, the version of events with nothing in it you can use.
I said in a previous post that the failure was never making the mistake. The failure is handing the mistake to someone else with somebody else’s name stapled to it. The same logic applies here. Extracting the lesson is what converts a cost into an investment. Refuse to extract it and you simply paid full price for nothing.
8. Teaching something in order to tighten your own understanding
Yes, and it might be the most underrated item on this list.
Teaching exposes exactly where your understanding is load-bearing and where it is decorative. You can hold a comfortable, confident, entirely hollow model of a topic for years and never notice, because nothing ever stress-tests it. Then somebody asks a simple question, but why does it work that way?, and you discover the floor is not there.
This is why explaining something to a colleague so often clarifies it for you more than for them. It is why writing documentation exposes design flaws you had looked straight past a hundred times. The act of making something transmissible forces it to become coherent.
It is also, not coincidentally, the founding logic of Skill-Wanderer. I did not start building courses because I had finished learning. I build them because it is one of the sharpest learning instruments I have found, and the fact that it helps other people at the same time is the best trade available anywhere.
And That List Is Nowhere Near Complete
Eight cases, eight yeses. And I could keep going for quite a while.
Debugging somebody else’s code is learning. Reading a codebase you did not write is learning. Losing an argument to someone who turned out to be right is learning, and that is an underrated one. Travelling is learning. Changing industries is learning. Being managed badly and understanding, viscerally, what not to do to your own team later is learning. Watching a competitor succeed at something you dismissed is learning.
Learning is still learning, and there is never a shortage of ways to do it.
That is the real conclusion from running the list, and it is not a rhetorical flourish. If the only mode you accept is the structured course, then learning is scarce, expensive and time-boxed, and it competes with your job for hours you do not have. If you accept the full definition, then learning is ambient. It is available in nearly every hour of your working life, including the hours you are already being paid for.
The difference between those two people is not intelligence, budget, or free time. It is whether they notice.
So, Is Learning the Most Important Skill?
Here is where I have landed, and I want to state it precisely rather than comfortably.
I do not think learning is the most important skill. I think that phrasing is the reason the answer sounds weak.
Calling it “the most important skill” puts it in the same category as AI, data, and domain knowledge, as though it were a fourth competitor on the same shelf and we are ranking them. But it is not on that shelf. It is the thing that puts things on the shelf.
AI skill, data skill and domain skill are all outputs. Learning is the process that produces them. Asking whether learning beats AI skill is a bit like asking whether the factory beats the product. The comparison is not close, it is malformed.
So my actual answer is this: learning is not the most important skill; it is the only one that generates the others. Every specific capability you value is something you learned, and every specific capability you will need in five years is something you have not learned yet.
A few consequences follow from that, and they are worth being explicit about.
The half-life of specifics is shortening. This is not nostalgia, it is observable. Skills that used to stay valuable for a decade now stay valuable for a few years, and some of the AI-tooling specifics have a shelf life measured in months. The faster the specifics decay, the more of your total value sits in the process that replaces them. In a slow-moving field, what you know dominates. In a fast-moving one, how quickly you can know something new dominates. We are decisively in the second kind of field.
It compounds, and compounding is not intuitive. Every domain you learn makes the next one faster, because you start recognising shapes: this is the same consistency problem I saw in logistics, this is the same approval workflow with different nouns. Ten years in, it is not that you know ten years of facts. It is that you have a library of patterns, and new material keeps landing in slots you already built. That is why a genuinely experienced engineer can pick up an unfamiliar domain alarmingly fast, and it is not because they are cleverer.
And here is the honest caveat, because I do not want to sell this cleanly. Learning on its own is not sufficient, and it is possible to use it as a very sophisticated way of avoiding work. I have met people, and I have been this person, who read constantly, take every course, follow every release note, and ship nothing. Input feels productive. It is measurable, it is comfortable, and it never fails in public.
But the definition itself rules that out, which I find quite satisfying. Look at it again: acquiring knowledge, skills, behaviours, values and attitudes. Skills and behaviours cannot be acquired by intake alone. You cannot read your way into a behaviour. If nothing about what you do has changed, then by the definition’s own terms the learning did not fully happen. You collected material about learning without completing it.
So the claim is not “consume more.” It is closer to this: learning is a loop of intake, application, failure, and reflection, and the loop is what makes you valuable, not any single position you occupy inside it.
What I Actually Changed
Conclusions that do not change behaviour are just opinions with better paragraphs, so let me be concrete about what came out of this for me.
I stopped waiting for the structured version. The reflex used to be: I do not understand X well enough, I should find a course on it. Sometimes a course genuinely is the right instrument, particularly when a field is mature, well-taught, and has an order that matters. But quite often the better move is to build the smallest possible thing with it and find out where it hurts. The course would have taken eight hours and taught me the general case. The experiment takes two and teaches me my case.
I started writing things down that nobody asked for. Most of what I learn now gets written somewhere, even when there is no audience. Sometimes it becomes a post. More often it stays a note. The point is the conversion step. I have lost too many hard-won lessons to the assumption that something that painful would obviously be memorable.
I treat failures as billable. When something goes wrong now, my first question is not whose fault it was. It is: what did I just pay for, and did I collect it? The cost is already sunk. The only remaining variable is whether I take delivery of the lesson.
I schedule it. Following Gates’ logic, not his stack of papers. Learning does not fit into leftover time, because leftover time does not exist. It fits into time you defended on purpose.
And I teach. Which is the whole reason Skill-Wanderer exists in the form it does. Every course I build forces me to find the place where my own understanding stops being real. It is the most reliably uncomfortable, most reliably useful thing I do.
Where That Leaves the Argument
We never settled it. Four people walked out of that room with the same four opinions they walked in with, which is a fairly ordinary outcome for an argument conducted over an undefined word.
But I think I know now what I would say if we ran it again.
I would not argue that learning beats AI, or data, or domain knowledge. That was never the right frame. I would ask the question that would have saved us the whole evening:
What do you mean by learning?
Because if you mean courses and certificates, then no, it is not the most important thing. It is one narrow supply line among several, and I understand entirely why you would rank it below a concrete technical skill.
But if you mean the full thing, meaning experience, study and instruction; knowledge, skills, behaviours, values and attitudes; lifelong, with no completion date, then it is not competing with the other three at all. It is what produced them. It is the same mechanism that got us from a lightning-struck tree to a data centre, and it has not changed shape once in the entire interval.
The technology on your CV will be replaced. It was replaced before you got here and it will be replaced after you leave.
The thing that lets you replace it is the only line on there that never expires.
So let me put the question to you, the same way it was put to me, with the definition attached this time so we are actually arguing about the same thing:
Do you think learning is the most important skill? And more importantly, what do you mean by learning?
I genuinely want to know. My side of the argument is above; I would like to hear yours.
Ready to Join the Journey?
If our mission to provide honest, accessible, and free education resonates with you, here’s how you can be part of it:
- 🌐 Visit our platform: skill-wanderer.com
- 📚 Start learning: dojo.skill-wanderer.com
- 📝 Read more: wanderings.skill-wanderer.com
Keep wandering, and keep learning. See you next time.
