You can keep reading here or jump to my blog to get the full experience, including the wonderful pink, blue and white palette.
My professional career started under the wings of two exceptional people: Ania and Marcin. They taught me something that stayed with me ever since.
I picture three elements of doing something: the WHY, the HOW, and the WHAT. We start with a goal, we rely on strategies and tactics, and execute.
During my internship, my mentors kept insisting on the WHY. I'm glad they entrusted me with figuring out the HOW and the WHAT. Because it's the WHY where I needed guidance.
They gifted me with an unfair advantage: extrapolating permanent knowledge from temporary knowledge.
Temporary Knowledge
Temporary knowledge expires. There's a long list of frameworks and technologies that were popular just a few years ago and are already long forgotten.
Recently, I've read the following:
Because of the temporary nature of the knowledge capital, computer programmers quickly reach a stage in their career when their old knowledge capital becomes worthless at the same rate as they acquire new knowledge capital. Their total knowledge capital is no longer increasing, so neither does their salary increase. They have reached the dead end plateau of their career, and it happens after less than ten years in the field.
To which somebody replied with:
One difference I've seen from young developers and more mature developers is that more mature developers tend to have a better understanding of how users will operate and will help mitigate issues before they arise. They have wisdom and that certainly isn't "temporary knowledge capital".
As a developer, I wish the latter was true. However, I cannot help but think there's some merit to the first take. I posit both opinions are valid through the proper lens, and we better be aware of it. Let me explain.
The WHATs of anything are bound to its context and lifecycle. For example, the syntax for records in Haskell is relevant only to Haskell code. However, the HOWs and the WHYs are part of the nature of software to a more significant extent. They can be transferred to other languages.
Don't get me wrong, temporary knowledge is essential. It's a bit like shallow and deep work. Our jobs entail both. We need the WHATs, in other words, the concrete implementations, to perform a task. At the same time, we should be contemplating the HOWs and WHYs behind them.
One can write code without critical or creative thinking, but it doesn't mean they should do it. Copy-paste from StackOverflow, anybody?
The problem is, by disregarding practices and principles, we are condemned to start from scratch and re-learn at every context switch.
I fear not the man who has practiced 10,000 kicks once, but I fear the man who has practiced one kick 10,000 times.
–Bruce Lee
Permanent Knowledge
Permanent knowledge does not expire because it's not bound to the current context. But it has a price. Given the higher level of generalization, it's often more challenging to acquire. It's a bit like in code, its easier to start with a concretion and, later, extract the abstraction.
Thus, one way to develop permanent knowledge would be laddering up from temporary knowledge. Instead of throwing arrays at problems, understand HOW to use them, most importantly, understand WHY. Syntax changes from language to language, but an array's nature is the same across the board. Hell, you could follow the abstraction to math, then it would apply to everything, not only software.
Recently, I started working on a legacy project that is over-engineered with all sorts of technologies. What saved me was transferring knowledge:
- Haskell -> RxJs
- Redux -> NgRx
- Elm -> TypeScript
It's not knowing Haskell, Redux, and Elm that enabled me to thrive in this project. It's the fact that I understand the principles behind those technologies. They are just an incarnation of category theory, reactive functional programming, and strongly-typed functional programming.
At the end of the day, we need a concrete implementation (temporary knowledge). But we cannot do a good job if we are not guided by permanent knowledge. I can easily search the details of an algorithm on a tree if I know it exists. If I don't, I'm going to re-invent the wheel, and possibly screw it up.
I feel I should close this post with a joke. Something about a JavaScript developer trying to convince a Ruby developer that the data structure they need is an object, not a hash. But I fear it would reflect the reality of the silos created by temporary knowledge around us.
Get the latest content via email from me personally. Reply with your thoughts. Let's learn from each other. Subscribe to my PinkLetter!
Top comments (2)
This is a great posts, thanks for sharing!
I think big reason for the temporary knowledge silos is that it's simple to look up concrete details (online, in books, etc.), but the higher one climbs the abstraction ladder, the tougher it is to find the closest concept that matches the idea one has.
Sometimes the more abstract concepts don't even have a name and are expressed by referring to more concrete realizations of the concept (similar to how hash/object are more concrete ideas originating from same higher concept).
From my experience, I find that learning Haskell has been especially challenging due to how it uses far more abstract concepts for general problem solving than any other language I've used. It's tougher to understand what exactly I should look up to express my idea in code.
But at same time, being based in category theory, it makes it simpler to navigate the high abstractions due to it's formality. That's how unique yet useful tools like Hoogle can exist.
Thank you for the comment Valts!
I agree. In general, temporary knowledge is more accessible. I've been learning Polish for the last few years, and I burned myself time and again when I opened the grammar book too soon.
Haskell is mind-bending. Especially when coming from a background that wired one's brain according to a different paradigm. This was my experience. Luckily, I met people who encouraged me, and, to be honest, I had to work hard to internalize many concepts.
In my upcoming newsletter, I'm sharing a couple of links on the topic of permanent knowledge. Here they are, in case you feel like exploring more: