Join the DZone community and get the full member experience.Join For Free
10 Road Signs to watch out for in your Agile journey. Download the whitepaper. Brought to you in partnership with Jile.
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.
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.
Published at DZone with permission of Henrik Warne , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.