How do developers learn new technologies?
How does an ASP.NET business developer learn to develop an iPhone application How do they become proficient in node.js, mongodb, or other emerging technologies How do they become acquainted with Linux or nginx?
Those are pretty unrelated to their day to day work, so instead ask how do they learn webGL How do they become acquainted with the FileAPI IndexedDB LocalStorage? CSS 3 Microsoft Azure or Amazon’s AWS?
How do they learn Github or Mercurial or regular expressions or dependency injection if those aren’t specifically what you’re already using in their team?
Sadly, most simply don’t, instead evolving their knowledge-set only within the confines of the tasks and education windows allocated for them.
You will implement localStorage functionality for Webkit based browsers in 6 to 8 weeks. Allocate a two-week training block.
Their ability to learn dictated by their management and the firm that they work for, their career path essentially placed outside of their control. This yields many technology casualties when the product they work on veers off of the lucrative path, their knowledge stagnant and increasingly irrelevant.
While many simply have little interest in this field outside of the nine to five — the technicians of our industry, which is fine if that’s what they are looking for — for many others the knowledge malaise is courtesy of the “we own you” clause in many employment contracts. The clause that claims ownership over all creations during the tenure of employment: That iPhone app you thought up, or the innovative new social media site you have considered pursuing, the claim goes, isn’t worth your time because we’ll simply take it from you.
This has a profound chilling effect on self-direction. It achieves little yet costs plenty.
It extinguishes the quest for the tech lottery ticket. It precludes building that elusive killer website or viral mobile app that has led many to endless hours of learning and, essentially, training.
“So what?” you might say. Why do you care if your workforce only knows specifically what they work on today?
Because what they work on today won’t be what they work on tomorrow. Or maybe it will be what they’re working on tomorrow, only because no one in the team has the skillset or the knowledge to introduce or advocate beneficial alternative approaches. Patterns and practices degrade, with little or no external influence or enhancement.
Hammer, meet nail. If it isn’t a nail, pretend it is. This is how products and teams go to die.
This post is of course drawn from the observations of teams I’ve worked with over the years. That Borland Delphi team that stuck with exactly the same technology stack they’d used for a decade, until the stagnation grew so rank that essentially the entire team was upended, replaced with new turf that would start the same process yet again. The VB ASP shop that started with such innovation and progress, only to enter the channel of little variance, yielding the same outcome. In both case the result was terribly detrimental to both sides of the equation.
Never sit still. Never let someone else dictate your skillset or knowledge. Never dictate the skillset or knowledge of others. Always be learning.
And don’t take away that lottery ticket that motivates so much experimentation and learning. The paranoid concern is far outweighed by the knowledge benefit your team gains.