Source originale du contenu
I hear this question quite a bit lately. Our industry feels like it’s expanding exponentially with new techniques and technologies. People feel overwhelmed and unsure how to ingest it all.
I’ve found that I have 3 phases to my learning process:
- Reading
- Building
- Writing
Reading — Superficial Learning
I read a lot. I’ll click on links from Hacker News, Facebook, and Twitter. I’ll read about new techniques and new technologies and integrate those learnings into what I already know.
This is very superficial. With this knowledge, I can refer back to things if somebody asks about how to solve a particular problem. I couldn’t necessarily apply the approach myself yet but I have enough to know that a solution exists. That in itself can be quite useful.
Building — Application and Expansion
From there, when I want to learn more about a given thing, I build something with it. Most recently, I wanted to learn about web beacons and took the time to make a beacon to see how it worked. I do this frequently. I’ll build small one-page apps to test out a concept. The exercise may take me anywhere from an hour to a week to build.
Building something expands my knowledge on a topic and now I can speak more authoritatively on the pros and cons of why and when you’d want to use such a technique or technology.
Writing — Explore the Edges
The last step is to write about it. This could be a blog post, a book, or a conference talk. When I write about a topic, I explore the edges of what I know, the edges outside of what I needed to initially implement the idea.
For example, it’s one thing to know that web beacons exist. It’s another thing to know how to implement them. It’s another thing to know the range and other limitations that exist.
In writing a blog post about all:initial
, I forced myself to test in every browser and discovered how inconsistent the implementation was.
Reading, Building, Writing, Repeat
It’s not necessary to go through this process for everything. You can stay at the superficial level for many things and only dive deeper when you need to, like implementing an idea on a client project.
Likewise, you don’t need to write about everything you work on. Writing is, for me, how I learn a topic more intimately. Not everything needs to be learned that deeply.
As your career develops, you’ll gain a sense of what things to explore sooner rather than later, or not to explore at all.
I have a list of things I’d like to explore—like progressive web apps, service workers, and web components—and when I do, I’ll go through this same process again and again.