I had an interesting conversation the other day about expired knowledge. On the current project I’m working on, I’m realizing that there are a lot of gaps in my knowledge of WebForms. The other day, I told the person I was pairing with that this chaotic abstraction of the web is confusing to me.
But here’s the thing - my lack of knowledge of WebForms isn’t because I haven’t learned it yet. It’s because I didn’t really want to.
The Complex Page Life Cycle Revelation
I remember the first time I heard the term “complex page life cycle.” It had no meaning to me so I googled it to find out what it meant. Oh man… oh man… I remember reading through some MSDN docs about the sequence of events that fire as a page is constructed, and I thought to myself: “I’m not going to memorize this. This is crazy…”
That moment was a turning point for me. I realized I was looking at something that felt more like arcane ritual than software engineering.
The 5-10-20 Year Test
What is an advanced knowledge of WebForms going to mean to you in 5 years? How about 10 years? How about 20?
I have no idea what the future holds for me, but I do know that I want to be in software for quite a while. So I do my best to focus on knowledge of software development that won’t expire quickly. I would much rather spend my time studying the intricacies of programming paradigms rather than learning the intricacies of some framework that might be obsolete in a few years.
The Shiny Object Problem
It sucks when you’re doing a demo of your work to a person from business, and they’re more impressed by shiny things in the UI rather than how well tested and loosely coupled your design is.
It’s like training - if I’m rewarded for spending my time learning about the cool new AJAX controls, and shunned for spending time trying to understand what the Liskov Substitution Principle means, then what am I more likely to do?
This creates a perverse incentive structure where we optimize for immediate visual impact rather than long-term code quality and maintainability.
Framework Knowledge vs. Fundamental Knowledge
Don’t get me wrong - you need to know your tools well enough to be productive. But there’s a difference between:
Framework Knowledge (Expires Quickly):
- WebForms page life cycle events
- Specific AJAX control implementations
- Framework-specific configuration quirks
Fundamental Knowledge (Lasts Decades):
- Object-oriented design principles
- Testing strategies and practices
- Design patterns and when to apply them
- Understanding of web protocols and standards
The first type of knowledge has a shelf life. The second type compounds over time and transfers between technologies.
What’s Worth Your Time?
When I’m deciding what to learn, I ask myself:
- Will this knowledge be relevant in 5 years?
- Does this teach me something fundamental about software design?
- Am I learning principles or just memorizing APIs?
Framework-specific knowledge is necessary for day-to-day work, but it shouldn’t be where you invest your deep learning time.
My Learning Focus
What’s the moral to this story? Don’t feel bad, like I do, that you don’t know the intricacies of some specific technology. Strive to understand what it is you’re doing, and why you’re doing it that way.
My focus for this year is to study:
- Object-oriented programming - The principles that make code maintainable
- Test-driven development - How to design through testing
- Design patterns - Proven solutions to common problems
These are investments that will pay dividends regardless of what framework I’m using five years from now.
The Long Game
Every technology framework will eventually be replaced. But the fundamental principles of good software design are remarkably stable. SOLID principles were relevant 20 years ago and they’ll be relevant 20 years from now, even if we’re writing code for quantum computers or neural interfaces.
Choose your learning investments wisely. Learn frameworks well enough to be productive, but invest your deep study time in knowledge that appreciates rather than depreciates.