Retooling

Tech moves fast, there’s no question. New languages, frameworks, ecosystems–it all develops at breakneck pace. It is simply impossible to keep up with all the things. Most of the technologists I know find something to deep-dive into, but also try to keep a pulse on what the broader community is doing.

To make it a career, it’s almost required to find a groove and rock it for a long time. Time spent and code written (and tested and debugged and refactored) is what allows [deep context](http://www.linkedin.com/pulse/hard-thing-software-development-jesse-watson/), which is what defines an effective developer. But as it goes, the tech landscape changes, clients (internal or external) require new shiny things, previously developed deep-context is no longer relevant, and the meaning of life is lost forever! (Too dramatic? Maybe it’s just me? I digress…)

When it’s time to retool, do not lose heart! You did it once (or twice, or thrice), you can get back to being (and feeling) productive.

Firstly, reflect on your previous paths of learning. What were the milestones along the way? What people or events were pivotal? What positions did you hold on previous projects? Your path was likely different from mine; my reflections produced this list.

## start small
Find a project and try to make a change. Any change. A trivial change. Change or inject some text somewhere, move a visual element, etc. This forces you to figure the basics of the environment, get the app running, and find your way to source files. These are not trivial steps, especially if it’s an entirely new stack. It will get you

## shorten the feedback loop
I’ve made the most progress in the shortest time when I’ve had a short feedback loop. When I can make a change and quickly see how it affects the app, I can iterate on that understanding and deepen my context. This is highly dependent on the app, but things like unit tests or refreshing a web page generally produce quick results. Push yourself to get into a state where you can iterate.

## quality control
Participating in QA/QC, formally or informally, allows you to learn the system’s intended behaviors, but also its quirks and tendencies. This gives you insight on what can be improved, and ideas for little things to tweak (see _start small_).

## gamify learning
If it’s a new language, small succinct problems are great for learning. It drives you into the fundamentals of the syntax, forces you to setup a working environment, and gives you quick wins. [Project Euler](http://projecteuler.net/) is one of my favorite venues for this.

## get oriented
After syntax, the next most common question is, "How is this general problem managed in this ecosystem?" Sure, I can rewrite the wheel using core language constructs, but there’s likely an `npm install` for that.

In my experience, this orientation is most helpful when coming from an in-person interaction, especially from a person who knows your previous experience and can help bridge from your old world to the new one.

## ask for help
Forums, mailing groups, Stack Overflow–there are endless resources. Find a place where you’re comfortable asking newbie questions. Also, try to answer others’ questions — teaching is one of the most effective ways to learn.

## read, watch, learn
As you gain familiarity with the basics, keep growing by following the experts in that space. Blogs, YouTube, conferences, meetups, etc. See what problems they’re thinking about and solving. This is the stuff that takes you beyond "catching up" and into the realm of deep context.

Until Elon Musk completes his [Neuralink](http://techcrunch.com/2017/03/27/elon-musks-neuralink-wants-to-boost-the-brain-to-keep-up-with-ai/) project, it requires slow, tedious effort to achieve expertise in a new space. But it is doable, and it is worth it on the other side.