Expect everything to change...

Fleeting Knowledge - Language Specific

That would be a framework’s API and syntax. Knowing those nitty gritty details of Angular and its API is necessary to be productive in an Angular codebase, but it’s useless in any other codebase. I refer to this type of knowledge as the “how” as in, “How do I do X in Angular?”.

Enduring Knowledge

The more enduring kind of knowledge is the “why”. Why does Angular exist? Why does it have the features that it has? What problems is it trying to solve?
Frameworks like Angular may have a short lifespan, but the problems they tackle live on for much longer. Angular was built to tackle the problem of writing, maintaining, and iterating on complex web apps. Any knowledge that helps us approach this problem will be valuable for a long time. In fact, it’s not a huge stretch to swap “web apps” for “software”, and suddenly we’ve got a problem that’s going to last an entire career! That’s the kind of knowledge we want — the enduring kind.

Diving Deep

Asking “why” and getting to those enduring nuggets of knowledge isn’t always easy unfortunately. The context and motivation behind a particular feature is the kind of knowledge that’s harder to come by, but it’s well worth the effort. Let’s go through an example.

Say I google “Why should I use Angular”. I might run into reasons like this:

1. MVC and separation of concerns
2. Two-way data binding
3. Dependency Injection

If I don’t know what MVC and dependency injection are and why they’re good practices, then I’m simply left with more questions. Why would I want dependency injection? And why is separation of concerns useful?
So let’s keep digging (this is super simplified):

1. Angular uses dependency injection…
2. …and dependency injection is useful for writing unit tests
3. …and unit tests are useful for maintaining and iterating on software

Got it! Now I learned about dependency injection, which a generic design pattern that’ll be useful to me past Angular’s lifetime. This knowledge also helps me better understand how and when to use that Angular feature, and when I can ignore it. Practical knowledge for our Angular work today, and enduring design pattern knowledge for the future. Win-win!

In general, asking why is a recursive process, just like installing a software dependency. We have to follow all the recursive dependencies until they all resolve, otherwise we end up with broken software or in this case, incomplete understanding. We have to continually dig deeper until we hit a layer whose value we understand. Kids know this intuitively!

Your brain’s dependency tree

Here’s how I (simplistically) imagine the “Why Angular” knowledge dependency tree:

1. At the top level we have the most specialized and most fleeting solutions: frameworks like Angular.
2. One level deeper, we get into specific patterns that are common across different frameworks: DI, MVC, etc.
3. As we dive deeper, we get into more fundamental software engineering practices, and so on until we arrive at core problems in software engineering.

I love this visualization because it exposes the deeper level concepts for what they are: building blocks. Once we dive deep into a framework that uses MVC and learn what MVC is all about, then we’ll carry that understanding over to any other MVC framework we use in the future. It’s just like when a package manager installs a new package and finds one of the dependencies already installed — it can just reuse it.

Having more building blocks doesn’t just makes us faster learners, it’s also essential for innovating new solutions. Almost every new piece of software is inspired by many other ideas before it. One example is redux, which is inspired by Flux, CQRS, Event Sourcing, and probably more (perhaps Clojure atoms). We stand on the shoulders of giants not just by using the software they built, but by understanding the ideas they introduced.

Personal Reflection

When working on a project the path of least resistance can be copy, paste and ship. But isn’t the best idea for personal growth.

You can get more value from these projects by:

1. understanding the frameworks(Angular’s) decisions within the context of the problems it was solving
2. asking why and not being afraid of following the rabbit holes
3. understanding the motivations and tradeoffs behind the Angular features

We should learn frameworks not just to build stuff, but to learn new ideas because once a framework is out of use, the ideas are all that’s left. But when a framework doesn’t teach us anything new, I am reminded of Alan Perlis’s quote:

• “A language [or framework] that doesn’t affect the way you think about programming, is not worth knowing.”

Even if frameworks come and go, we can still learn the ideas behind them and become better engineers, as long as we dive deep enough.

my thanks to this great blog post:
https://hackernoon.com/how-ages-faster-than-why-712e25c9eb3b