The other day someone reached out to me with a question I get somewhat regularly, but I never really thought to write down my answer much. The question was, “How do you come up to speed quickly on new languages and technology?”
Quick for me is productively contributing code in less than 48 hours.
I focus my strategy on three major components – Small practice projects, pattern recognition, and test-driven-development.
Small Practice Projects
I recommend that developers have a few small projects that they don’t mind rebuilding over and over again. The idea is that these projects are something you know intuitively how to solve, so what you’re focusing on is expressing your solution with new technology.
For front-end folk, I recommend looking at a todo application and using TodoMVC as a helpful reference if you get stuck. For generic problems, I recommend a vending machine. I’m also guilty of building DES encryption.
Now, your specific project may vary from mine, but the qualities of a good side project are:
- You can complete it in a few hours to a day
- You can think of more than two different ways to solve it
That’s basically it. You want it small enough to complete within a day so you can repeat building it multiple times and learn. You don’t want to get stuck on the same thing for a week. You’ll also be doing this on the job, so you’re using these projects to get back to the job, so we need something short and to-the-point.
You want to have multiple ways to build it because that means there is enough complexity or flexibility to it where you can try different things. “Fizzbuzz” doesn’t fit that since it’s too obvious, and doing it multiple ways is contrived. A vending machine offers various ways to handle money, inventory, and so on. That flexibility allows you to re-purpose the project in new environments.
So now you have a practice project or two, you rebuild it several times. Each time you pick a topic to learn and rebuild. I usually start with the language. Then I may add some aspect of a framework. Then I may add other integrations like to databases.
This all costs me a few hours to a day or two, and by the time I’m done, I can contribute code to a working codebase, though I’ll be slow and shaky at it.
Pattern Recognition
It’s hard to learn everything about any one aspect of development. It’s much easier to leverage the part of our brain that recognizes patterns. Say you’re familiar with Angular, and you want to learn React. Explicitly identify the angular equivalents of what you’re learning. Do the same for concepts like data passing, rendering, and the like.
Once you can identify patterns, you can focus you learning on how they are different. Very often, those differences wind up diminishing over time. My first pass working may be very like the other patterns, but it will work, and I’ll spend time cleaning it up and making it idiomatic after instead of getting stuck up-front.
Test-Driven Development
Ever get a cryptic error or stack trace, then spend minutes to hours trying to google what it means and what to do about it?
One reason for this is that you don’t know how your tools and technology communicate with you. The more comfortable you get with how those things communicate, the quicker you get back to things.
When you leverage test-driven development, you start with a failing test. That failing test will be the first of a lengthy dialog of your systems telling you how things don’t work and what you should do. By the time you work through a small project using TDD, you’ll be very familiar with a lot of the ways your tools are trying to tell you how things need to work.
But, What About Tutorials?
Ok, so when you’re working through one of these projects, you’re going to hit hundreds of problems. Now when you look at a tutorial, you’re trying to learn something specific instead of a vast amount of things. That focused learning helps get you moving quicker and leverage what you already know.
This approach helps keep you from feeling like you can never read or watch enough to keep up. This whole time you’re writing real code and getting hands-on learning.
images courtesy of Unsplash
I write a newsletter every week on career and consulting advice, and recently published my first ever book with everything a developer needs to know to get a job and negotiate successfully.
Top comments (0)