This article describes my strategy for learning new technology, refined over the decade or so that I’ve been working in tech. As with any advice based on one developer’s experience, you may find that it’s obvious or that it doesn’t apply to you, but I hope it’s useful as a guide, a checklist, or even just a starting point for reflecting on your own learning process.
When I talk about learning a technology, I mean something pretty concrete. I would apply this approach to:
- programming languages
- data stores
- libraries and frameworks
- tools (git, Docker, Regex, etc.)
- platforms (Linux, AWS Lambda, Google AppEngine etc.)
I wouldn’t apply it to:
- methodologies (TDD, agile, effective writing, etc.)
- high-level concepts (parsing, ML, IoT, serverless, etc.)
- low-level details (virtual memory, garbage collection, etc.)
A 3-Part Strategy for Learning New Technology
Here’s an overview of my strategy: when I’ve got a new technology to learn, I think about going through three broad phases:
- Consuming documentation
- A learning project
- Application
Phase 1: Consuming documentation
My first stop when approaching any new technology is documentation, especially intro docs or tutorials. I do love a technology that comes with good documentation! This phase might also include courses, blog posts, or other third party material.
Beyond actually learning the technology, in this phase I’m looking for:
- Points of comparison: Is this technology similar to something I already know?
- Unique features: What are the ways this technology is different or surprising? Where might I apply it instead of something I already know?
- Integration points: What kind of projects could I use this technology for? Will it let me leverage things I already know, or does it require me to discard my usual toolbox?
The objective is obviously not to learn everything there is to know, but to create connections to my existing knowledge so that I can start using the technology and find my way to answers in the future.
Some examples of great material for this phase:
Phase 2: A learning project
Once I read the introductory documentation, I try a little project using the new technology. I aim for something small but not trivial. I want something where I can safely apply the skills I’ve just (supposedly) learned but also something that will challenge me and expose any gaps in my understanding.
Note that this isn’t learning on the job or building tools to scratch your own itch (though those are important skills in their own right). It’s a project that’s conceived, planned, and executed with learning as a primary goal.
I try to find a project that:
- Highlights the new technology: I won’t learn much about a new database if I’m struggling to get my front-end code just right. If I want to try out that auto-documentation feature, I should make something that I’d want to document.
- Is just beyond what’s comfortable: Getting frustrated with advanced features isn’t productive, but neither is retreading material from the tutorial.
- Doesn’t have too much instrumental value: If I set out to build something, I might overlook a new technology’s failings if I want the thing badly enough.
- I can put some polish on: The point is to learn a technology well; it’s good to have some time to polish, review, or get feedback.
- Above all, I want a project that’s small: A tight scope helps me keep focus and leaves me free to fail fast if the project isn’t working.
The objective is to discover all the things that the new technology’s documentation didn’t address:
- How difficult is it to install/build/operate?
- Can I integrate it with my existing tools (languages, editors, source control, packaging and deployment, etc.)?
- Does it still feel elegant and useful when I’m using it on an original problem (and not a carefully chosen example)?
- Did I actually learn it well enough to turn an idea into a reality?
- Am I confident that I’m using this tool correctly? Idiomatically? Sustainably?
My experience has been that these kinds of questions aren’t always addressed very well in documentation or are addressed more with hype than with facts. If, after putting in a genuine effort, I can’t get a new technology to work for me, it’s an indication that the tech might be immature. Alternatively, my understanding might be flawed or the technology might not be a good fit for what I’m after.
Some examples of projects that I’ve done in this space:
I also find it helpful to write up a little experience report when I’m finished. This helps me capture and clarify my impressions of the new technology and have something to share with others.
Phase 3: Application
Once I’ve done my learning project, I’ve hopefully got a good sense of where a new technology fits and whether or not I want to keep working with it. At this point, it stops being a target for deliberate learning. If I’m trying to further develop my expertise, I look for:
- Opportunities to use it professionally: Perhaps I have a work project where the new tech is a good fit or is already a going concern.
- Side projects: This can be bigger and more instrumental than a learning project while still being a safe place to experiment.
- Complementary technologies: Sometimes it might be appropriate to start this process over with a related technology. (For example, you might learn Elixir then Phoenix, or Rust then WASM).
Naturally, I’m always looking for opportunities to go deep on a technology (heck, I’m still learning things about Python after nearly 10 years!) but I’ve found that further expertise comes much easier with study and experience than it does from studying alone.
This post was contributed by Nat Knight, one of the principal developers who supports our clients and projects at Robots & Pencils.
