Does developer knowledge really only last five years?
We’re determined to investigate the claim that developer knowledge has a half life of approximately five years. That means in order to stay technically current, we need to adopt a lifelong learning philosophy.
Developer knowledge, without any concentrated efforts to upskill, has its life span. While this statement is true, it isn’t necessarily surprising to most. Instead it’s the timeframe in which your current knowledge becomes less relevant that is so bewildering.
Philippe Kruchten, a professor of software engineering at the University of British Columbia, came up with the five-year hypothesis on a whim, after deciding to flick through a few older issues of IEEE Software Magazine, produced by the world’s largest professional association dedicated to advancements in technology. What he deduced was that a number of ideas, tools and techniques no longer hold relevance today (or in 2008, when his paper was published).
His conclusions were delivered together with a plan that involved a standard of professional development. Before his turn in academia, Kruchten’s ‘hands on’ career in software engineering had spanned thirty years, seeing him work as a practitioner and manager. Before we wax lyrical on Kruchten’s timeframe and suggestions for improvement, we should take a moment to define what ‘developer knowledge’ actually is.
Dimensions of knowledge
There has been a lot of debate around the half life of knowledge and what properties make up a developer’s learnings. Henrik Warne recently outlined the three dimensions of IT knowledge:
- Programming: Languages, paradigms, techniques, tools. Core concepts that quite often translate from one language to another, regardless of syntax.
- Domain: What you know about the environment in which the program is used. This area can sometimes be overlooked, but Warne underlines the contribution a developer can have to a business if they understand the particulars of the sector.
- Codebase: Particular to the workplace. You eventually become familiar with the code once you’ve worked with it for a prolonged period. Specifically, historical information is picked up, so you’re aware of the precarious areas, as well as the processes employed in the workplace around the code.
Defining developer knowledge in this way, Warne insists that a programmer is most valuable when they are knowledgable in all three dimensions. While coding experience is crucial, a developer’s knowledge isn’t completely ruled by it, which is where the debate gets interesting.
Because code isn’t the only kind of knowledge you need as a developer, does that mean that all knowledge you possess in the context of your profession has the suggested five year half life?
No way says Warne, who stands behind the idea that while a change in job means learning a new codebase, the knowledge you have in the programming and domain dimensions will still be useful:
Knowing several programming languages will give you reference points for how things are done differently (even if the fundamentals are the same).
The fundamental point that both Kruchten and Warne highlight is the importance of professional development and continual growth. Because there is so much innovation in the industry, there is always something new to learn and upskilling should be considered as integral to remaining current in the industry.
A term that Kruchten used to describe constant and sustainable upskilling was Continuing Professional Development (CPD). This kind of program is certainly not new and in some professions is a very big deal; for example, all registered health practitioners in Australia must undertake CPD by law, with physicians, surgeons, the whole she-bang required to prove that they are partaking in CPD programs in order to meet work, industry and organisational requirements.
Of course, this comparison isn’t perfect, but with technology accelerating at such a rate and the industry being involved in projects that can have monumental impact, a standard must surely be set. If you’re an IEEE Certified Software Development Professional, then you’ll already be aware of the mandatory practice of CPD, which is demonstrated by taking classes, reading books and attending conferences or seminars.
To be marketable, programmers have to be adaptable and open minded. That means staying technically current and investing in a lifelong learning strategy. With new programming languages constantly being developed, on top of massive changes being implemented to existing frameworks (hello, Angular 2.0), keeping up in the industry means getting your ass into gear in terms of new learnings and skills.
Kruchten believes we have “an ethical duty to keep up to speed with advances in our field”, which sheds new light on the debate. Are under-skilled programmers ethically responsible for their own development? The question is still being answered.
As one commenter on Programmers Stack Exchange so eloquently declared: “fundamental programming principles and techniques are eternal”. What do you think?