What is the half-life of programmer knowledge? It is quite common with claims that the half-life is something like 5 years. In other words, half of what you know about programming will be obsolete in 5 years. A similar sentiment is: “Programming sucks, because what you knew a few years ago is useless now”.
At first, this seems plausible. After all, there is a steady stream of new programming languages and technologies coming out. However, I think it is wrong. Programming knowledge is much more long-lived than some people realize.
Syntax is not the Hard Part
Take learning a new programming language. To non-programmers, learning Python when you know Java can sound like learning French when you already know English. But of course it is nothing at all like that. Yes, there is new syntax to learn, but that is just a surface difficulty. All the core concepts are the same.
To write a program in a any language, you use fundamentals like types, data structures and logic. If you have learnt about booleans, integers, floats and strings, they are likely used in the new language as well. The same goes for data structures like lists, sets, dictionaries and trees. And the logic you use will be arithmetic operations, if-statements, loops, function calls etc.
Furthermore, key skills like which algorithm to use, how to decompose problems, and naming of variables and functions are directly usable in a new languages. This is generic programming knowledge that transfers easily between languages. To borrow the terminology from “No Silver Bullet“: language syntax is accidental knowledge, but how to program is essential knowledge.
The same goes for libraries and tools. Even if you don’t know exactly how regular expressions are used in a new language, you know that there is most likely support for them. Finding the details on how to use them is not the difficult part – is is how to use them that is the valuable knowledge. Same thing with tools like IDEs – you may not know the details, but you know what you can expect them to do.
So learning a new language is not a big deal. But if you change jobs, there may still be a lot to learn. I think about it as knowledge in 3 dimensions.
Knowledge in 3 Dimensions
Programming. This is programming languages, paradigms, techniques and tools. Like I wrote above, there are many core concepts that are the same, even if the details (like syntax) varies.
Domain. This what you know about the environment in which the program is used. For example, if you work in telecommunications, it is the knowledge of how the various protocols work, how an SMS is processed, how billing and monitoring is done etc. The longer you work in a certain sector, the more you learn about it, and the more valuable your contributions can be.
Codebase. This is specific to a company. When you have worked for a long time, you know your way around the code. You know where things are done, which parts are tricky and unintuitive, and the history of why something is done a certain way.
Keep Learning
As a programmer, you are most valuable when you are knowledgable in all three dimensions. If you change jobs, it is inevitable that you will know nothing about the new codebase initially – you simply have to dig in and learn.
However, what you learn about programming and the domain will be useful even if you switch jobs. Knowing several programming languages will give you reference points for how things are done differently (even if the fundamentals are the same). It is also good to read books on software development in general, like Code Complete, Clean Code and The Pragmatic Programmer.
Finally, I think part of what makes software development interesting and exciting is that there is always something to learn. You will never get bored. So keep learning. Most of what you learn will make you a better developer, even as there are new programming languages coming out every year.
Henrik Warne's blog 
I have never understood this “my experience will be obsolete in x years” attitude. It makes me wonder if some people are writing code on autopilot. The reason why I think this way is that the most important things that I have learned during my career have got nothing to do with writing code (although I have learned these things when I was coding).
Actually, I used to think that the most important thing of software development is writing code. However, after I got some experience under my belt, I realized that writing code is the easiest part of my job. I realized that my job has three steps:
1) Understand what the customer’s problem is.
2) Figure out what kind of code should I write and how should I structure my code so that it it easy to use, read, and maintain.
3) Write the code.
The experience that I get from steps one and two will never be obsolete because it isn’t tied to a specific programming language. Also, I have learned that a project doesn’t fail when I am writing code. It fails because of the mistakes that are made in steps one and two. That is why I think that even though the ability to write code is a crucial part of our job, it is not the most important part of software development.
If this is true, how can our experience become obsolete because we have to use a different programming language?
Good points Petri!
I completely agree with your main point that experience can be long-lived and even transcend languages. I also think it’s telling that you picked two OO languages (Java and Python) when discussing knowledge transfer from one language to another. This breaks down a bit when the language is fundamentally different from the one you know, for example moving from Python to R or Java to Haskell. In some cases, previous experience can be a hinderance if you keep trying to solve problems in a familiar way, essentially fighting against the new language’s strengths.
Thanks Joel, excellent point!
Pingback: Baeldung Weekly Review 50
Very informative post for programmers. Practice always help a programmer to become the best . A good programmer must have three-dimension knowledge to serve his best.
I am fully agreed with u. I am trying to learn programming for almost 3 years and I think there is still a long way to go for me, now I understand there are lots of things to learn. Programming is like a sea, no one can tell, he/ she knows everything in the program. There are so many hard things to do, writing code is one of them, lots of people lost their mind for writing the code. The programmer must have the three-dimension knowledge to be the best .
Maybe I was born in the right year, but I’ve essentially managed an entire career (mid 20’s – 60) on the knowledge I pulled out of university and shortly thereafter (OO).
I’ve never been on the bleeding edge (financial software mostly), but outside of getting serious about concurrency in my 40’s, I’m still managing on 80’s concepts.
And to be honest, having a rock solid understanding of those 80’s concepts allows me to pick up most of what passes for new technology faster than many of my younger peers.
I’m beginning to see the end of the road (I’ve escaped having to learn all but a minimum of web and cloud technology), but it seems likely that there’ll be more than enough work with updated 80’s technology to keep me busy until my retirement at 75.