From Abstraction to Understanding
Over the past year I’ve been learning how to code. I didn’t start with a grand plan, but just wanted to explore something new. I took a deep dive into Python and picked up the Django framework that makes it easier to build websites and applications.
Coming from a philosophy background, I noticed that my approach to the learning process was anchored in the conceptual foundation I had acquired during years of philosophical training.
I saw myself comparing concepts in Python to philosophical structures found in Plato, Aristotle, Leibniz, and other philosophers.
Here’s a simple example. When you’re defining a concept or a model in Python/Django, you’re essentially constructing the idea from scratch.
Let’s say you want to build a second-hand car dealership website. To do that, you’ll have to define the concept of a car. You will therefore add attributes of the car: brand, year, mileage, price.
This is not the actual Ferrari car you have to sell. It’s an abstraction of all the cars. A Ferrari and a Kia are, abstractly speaking, cars. Each, however, has different attributes.
By defining the car, you know that on this website you won’t be adding planes too. Planes are a different class. They are not cars.
To make it easier to build things in code, defining the concept, class, and attributes is essential for it to work properly.
Let’s apply this to our concepts of justice, beauty, love, health, and the good. Could we define them? What are their attributes? How do they apply in different contexts?
To say that a diet is good is different from saying that a doctor is good or that an actor is good.
Beneath each statement is a concept we seem to intuitively grasp. When we say that an actor is good, we’re trying to articulate the idea that the actor seems to play their role well.
What does it mean, then, to play a role well? How do we know that they’re excelling at their role?
To evaluate that an actor is good, a diet is healthy, etc., we have to have some sort of benchmark.
We are making a judgement based on a definition or an idea we have in mind of what that goodness looks like. Even if the criteria is subjective, we at least have a set of requirements that a subject should fulfill to be worthy of our ‘good’ stamp.
Let’s pause here for a second. Several things triggered these thoughts. Before I continue, there are different nodes I want to connect, so it might be good to lay them out first. Here are some of the questions that came to mind and how it all started.
When Knowing Isn’t Enough
After several months of tutorials, courses, conversations, documentation, and back-and-forths with GPT, and building several websites and applications for personal use, I finally found myself last week thinking: I feel like I know Python and Django now.
What does it mean to know a coding language? I asked myself. What does it mean to know?
I don’t know Python the same way a senior developer who’s been doing this for ages does. I know Python in reference to a few months earlier when I knew absolutely nothing — and in reference to whether I’d be able to read code and learn on my own.
I started thinking about the following. I have some knowledge of Python. The senior developer knows Python far more than I do. Still, this kind of knowledge feels internal, personal.
We acquire knowledge internally, then externalize it by building, solving problems, and creating with others.
This is where expertise comes in. That interaction adds to our experience. It’s how we build expertise.
Knowledge, Expertise, and More
Consider a company of three. A movie streaming startup. There’s the intern, the programmer who knows his programming languages well, and the senior developer and architect who designs the system and guides the product’s roadmap.
The company runs into a problem. Uncertainty increases. Customers churn. Tastes shift. New technology disrupts. A new competitor enters the market, faster, smarter, cheaper.
What should the company do? The senior architect recommends a course of action. The team follows. It doesn’t work. The company goes bust.
The senior software architect knows his programming languages. He’s an expert. He has 20 years of experience in the market. Internally, he has achieved a level of mastery comparable to none.
Yet, in an external context, working under the assumption that he knows what the best course of action is, it turns out his plan fails. Does that mean he doesn’t know?
Not really. It just means that when applying his knowledge and expertise within this particular context, he may not have had all the information needed to make a good decision.
What exactly happened then? He was operating under uncertainty and taking risks. As a result, while he is an expert in his field, there’s a lot more to it in the external world governed by uncertainty, where it becomes difficult to know with certainty which way to go.
He’s an expert, yes, but within one dimension. He’s an expert insofar as he’s internalized the knowledge, absorbed it, had experience, applied this knowledge to create things.
Still, under complexity, that knowledge needs to be accompanied by something else.
Knowledge is layered. It takes different shapes and forms. It manifests differently across domains. The more complex the context, the harder it becomes to point out where that knowledge is.
I think we often fail to take that into consideration.
These ideas led me to dig further into the concept of knowledge and what it actually means to know something — and how we can transmit this knowledge to others.
Knowledge implies that there are some forms, concepts, and definitions that one ought to learn to get involved in a certain domain.
To learn Python, you need to understand what a function is, loops, classes, if logic, and so on. You can pick these up in a variety of ways.
This is where pedagogy comes in. Some prefer to get their hands dirty. Others start with theory. Some go for a balance.
It doesn’t matter much. Sooner or later, you’ll form an understanding of these fundamental concepts that lets you grasp the language and build with it.
Having these concepts and abstract forms allows us to transmit knowledge to others. It can take different formats: apprenticeships, theoretical courses, internships, etc.
Without some foundation or structure, could we say someone is ready to build on their own? And I’m not talking about theory vs experience here.
I’m talking about the underlying threshold, theoretical or practical, that enables us to recognize when someone is able to act independently because they have sufficient knowledge to practice the subject matter.
In other words, without a stable form or basic structure, it’s almost impossible to know whether someone knows, and is good. There’s an implicit fixed structure within any subject matter, and that structure allows us to develop a body of knowledge.
These forms may not be fixed. They might not be ideal. The world changes. Still, there always seems to be some fixed form, even if it’s governed by a dynamic process and flux over time.
Where is all this going? So far we’ve established a difference between internal knowledge, which includes a mix of theoretical and practical experience. This kind of knowledge often passes from teachers to students.
We also saw that internalized knowledge, when externalized into expertise, doesn’t always manifest as knowledge. To know is to be — to some extent — certain of the basic forms.
The real world is complex, often governed by uncertainty, and it calls for a different approach. So positioning ourselves as experts doesn’t automatically mean we know what the best course of action is.
It just means that, based on our assumptions, this is what we think should be done. Understanding that distinction might help us engage in more constructive debates instead of unnecessary heated arguments.
Knowledge, in Layers
Something still bugged me. I started thinking. We assume someone knows because they have a degree. Or experience. Or because they followed a certain path.
I think this makes things all the more confusing. Because not all knowledge is the same.
For example, there’s:
- Theoretical or abstract knowledge: math, logic, philosophy. Internal reasoning, deduction, coherence, often without observation.
- Scientific or factual knowledge: what can be tested, measured, observed. Water boils at 100°C. Smoking increases cancer risk. Certain diets are linked to better health.
- Technical knowledge: practical skills: writing Python code, driving, riding a bike. Learned through repetition and doing.
- Transformative or internalized knowledge: the kind that changes how you see and engage with the world. Not just knowing what’s good, living it, embodying it.
These are not ranked, just different.
We often blur the lines. We assume technical skill implies understanding. Or that theoretical knowledge leads to wise action. That doesn’t always follow.
To know that water boils at 100 degrees or that a diet is healthy is not the same as internalizing that information and building habits around it.
The same applies to technical knowledge. You might learn how to drive, but it takes time before that knowledge becomes second nature, something you move with, not just think through.
I’m not saying that anything goes. I’m also not saying there’s only one right way. This is an attempt to think about what we mean when we say we know something. Maybe the first step is to realize that knowing doesn’t always look the way we think it does.