Given the constant change in the software industry, learning new technologies is one of the most important skills for a developer. More often than not there are no ideal circumstances in which you start off with a three day training course conducted by an expert and afterwards do pair programming with proficient colleagues. The following is a draft for a survival strategy when you find yourself working in completely unfamiliar technology stack without much hand-holding, e.g. editing React code as Java developer.
Progressive advancement
Knowledge acquisition isn't a linear process. However, the difficulty of the learning activities should be adjusted to the current competency level in order to make it a pleasant experience.
Novice
The journey always begins in the "Novice" stage. This phase is all about understanding the context and doing the first baby steps.
Understand the tools philosophy
Who created it? Why did it get started? What problems does it solve?
Explore ecosystem
Who is using it? Where are the money flows? What sources of information are available? How does it compare to its alternatives?
Define learning goals
What are you trying to achieve? What sub-skills are required and what are their interdependencies? Which areas are out of scope?
Getting started
Set up an environment where you can do experiments (e.g. by writing a "Hello, World!" program).
Beginner
In the next stage you need to get an understanding of the basics (e.g. conditionals, loops, and statements for programming languages).
Training course
Request to attend a training course. If this this is not possible try find a good video tutorial.
Buy a book
Get an overview over all available books. Buy one from an experienced author and where a lot of attention was put into the didactic preparation of the subject.
Skim the book to know what you don't know and then be able to read the relevant sections when they become relevant.
Playground project
Before diving into an enterprise project, explore the technology with a non-trivial example project like a TODO app. Even better would be to create an internal productivity tool.
Intermediary
Now that you are familiar with the basics you can start to work on a real-world project. Be aware that learning at this stage requires relatively high effort.
Experiments
With the help of the playground project created in the Beginner stage new sub-skills can be explored without the burden of the complexities of the production system.
Documentation
Document snippets of lessons learned in an internal wiki or another knowledge management tool. This will help to reduce the time required for recollection.
Reading
Read the book aquired in the previous stage from cover to cover when there is some slack time. Also consider the application of other reading techniques.
Advanced
After being able to get work done the skill should be mastered so that it can be applied effortlessly.
Teach others
Teaching is one of the best learning techniques as you will notice what you do not know yet when you try to explain it.
This could be done by conducting internal training courses or mentoring colleagues. Other forms of teaching might be writing blog posts or recording screencasts.
Discussion
Finally, analyse the pros and cons of the technology. Then attend conferences and meetups to discuss them.
Probably you'll find a cool new technology there and can start the process again.
References
- Dreyfus Model of Skill Acquisition -- Stuart E. Dreyful, Hubert L. Dreyfus #paper
- Soft Skills: The software developer's life manual -- John Sonmez #book
- Exercises for Programmers -- Brian P. Hogan #book
- Making Badass Developers -- Kathy Sierra #talk
Feedback
Where do you see the strength and weaknesses of this learning model? Is it inherently flawed because workshops and pair programming are absolutely required in the beginning? If not, how can it be optimized so that the learning can take place to 99% on company time?
Top comments (13)
Amazing advice all around. This part is super not obvious for newbies. 👏👏👏
There's a similar process in chess. One must look at his opponent's move and figure out why he did it and what his plan is.
Great write-up! A lot of devs tend to try and dive into the deep end too quickly imho! (myself included, of course)
I feel like it's usually easy enough to dive deep when you are absolutely certain you need to use this right now. If there is any uncertainty about how and when to use it, I think that's where the fall off occurs in the deep dive.
I think we can forget how useful a shallow dive can be. I took a deliberate, but shallow, dive into Erlang and it was lovely. I may never write a line of Erlang, but I feel like I got a lot of quick gains on a lot of interesting concepts in software just by diving in a bit.
Sounds like you got a lot of exposure to Erlang, and got a fresh perspective from diving in...which is fantastic! Reminds me of when I bought a book on Ruby on Rails at a time when all I had done professionally was ColdFusion. I didn't realized how limited I was until I saw such a different way of doing things.
However, I do think it's important to cover your bases if you are interested in deeply learning a subject. I spent years writing JavaScript before I really grokked closures. I'm not sorry about that path, but I could have spared myself some mysteries if I had followed a more "Progressive Advancement" type path.
Shallow dive, this is the approach I took most of the time for new technology. Just spent 1 or 2 hours at most, try to get to a point where you can relate it to existing concept you already know. Then I considered it as done.
Yes, perfect rhythm.
One quick and sure way to be good with a technology is to use it a lot and not just reading or watching video tutorials about it. I wasted too much time before getting that.
1) Start reading about something [X] that you want to understand
2) When you encounter a term [Y] that you don't understand, go to step 1 for [Y]
3) Stop when you understand [X]
The best part of this method is that it still works for reaaally poorly documented topics.
You need all of that + 20000 hours ( 10 years ) of practice to make yourself worthy of your time.
I'd actually even say the stuff under the "Advanced" heading would be applicable at all stages. Maybe not dead novice - you need to know something - but even in the learning process, trying to explain it to a willing audience helps you to understand it better. (Of course, they also have to be an understanding audience that knows you're learning it too.)
Another interesting idea is that of "Just in Time" learning:
youtu.be/zKyv-IGvgGE?t=34m18s
However, this is not applicable in all situations. When a little change needs to be made in a complex application it might be necessary to understand a number of concepts first.
Maybe the "progressive advancement" concept can be dropped when all developers understand how to write clean code and thus the system becomes so easy to modify that everybody with a bit of aptitude can evolve it.
But maybe it can never be dropped because it is just a new name for the fundamental learning concept. E.g. nobody would expect a high school student to complete assignments on the level of a M.Sc. student and "just pick it up on the fly". It takes time to develop a mental model of the thing we are trying to learn. There are interdependencies between certain knowledge areas and it takes time to fill those gaps.