Have you ever had a client say something like, “I love that idea, but can you write it in Ruby?”

Your gut drops, and your blood pressure rises. Outside of hearing the Ruby referenced all the time, you know little about it. And you’re supposed to be the tech expert in the room! At the same time, you’ve always wanted to learn Ruby and you’ve got a vague sense that, yes, you could indeed write it in Ruby. So you say “Yes!”

Now what? You’ve done a Google search or two and are on to looking for tips on how to learn new technologies quick. Look no further!

First, don’t worry about not being an expert. Technology moves too fast for us to keep up with each shiny new thing. Instead, get comfortable knowing a little bit about everything so you can use your gut to guide you during those initial (and often unexpected) discussions, and then follow up afterwards with well-informed, organized plans and communication.

After learning several new technologies, I decided to put a little structure to this process of becoming well-informed. Here are the seven steps that I’ve found to be useful guides.

1. Identify & articulate a real problem to solve

Using a real-world problem helps frame and focus your learning.

It’s easier to learn a new technology by digging in, so if you don’t have an immediate problem you need to solve for a project, invent one. If your problem is big, split it up into smaller parts to make the lessons more specific (and less intimidating).

Each technology builds upon concepts of other technologies so try to subdivide it along clear functional lines. For example, let’s say the problem is to add group notifications to a mobile app that doesn’t have push notifications. You could split that big problem into three small problems that build on each other:

  1. adding push notifications for individuals
  2. adding grouping functionality
  3. lastly adding push notifications for groups

Start by learning what you need to know to achieve the smaller pieces, then learn what you need to put it all together.

2. Create a roadmap

Creating a knowledge roadmap will help narrow your focus so, once you’ve started, you can keep your eyes on what you need to learn (not all the stuff you could learn).

Write down a list, a flow diagram, or even a full project plan that outlines the information you think you need to know to use the technology like a pro. This is your roadmap which you’ll use to guide yourself through the learning process.

As you learn more, you’ll refine this document, but having a rough structure in place right from the start allows you to be very clear about your priorities with yourself and others. Be honest with yourself about what you know and what you don’t. Skipping a topic you think you need isn’t taking a shortcut (it’s taking a detour).

Sometimes you don’t even know where to start with your roadmap. The Internet’s got you covered; there are a ton of roadmaps out there. Find one that fits your career. Here are just a few examples:

These roadmaps can guide you through building your knowledge base and help you clarify what you’re missing. They should also reveal additional time requirements you need to share with your client or project manager in order to accomplish project goals with the new technology.

3. Start with concepts, not a deep dive

Finding a domain expert and asking them for a short overview of the technology is one of the fastest ways to conquer the initial “I know nothing” hurdle. This conversation will help you discover the main concepts and terminology of the technology. And, perhaps, refine your roadmap.

Start looking for high-level overview documentation. Don’t forget to search for videos as well as online tutorials, examples, or books. Document the major concepts and mark what you know and what you’ll need to learn on your roadmap. If there are vocabulary terms that you don’t recognize write them down and start creating definitions.

Pay special attention to terms that have one meaning in one technology and a slightly different meaning in your new technology so slight differences don’t trip you up. But on the other side of the coin, look for distinct terms that have similar meanings in different technologies. This helps you build off of previous knowledge. For example, a widget in one library might be called a component in another.  Knowing that they’re different words for the same concept allows you to make a few judicious assumptions about how they interact with the rest of the technology.

Make note of excellent examples or resources that are too detailed, you’ll likely come back to them later. Look for tools and environments that others use to develop in the technology, and gather that information, too.

As you start to get a feel for the technology, your roadmap will start to look less like a sketch and more like a task list.

4. Leverage other people’s interest, and energy

Finding somebody who also has a vested interest in learning the technology can be just the help you need. Together you can make progress, reduce the amount of headbanging (or just do it in unison), and generally feel like you’re not going at it alone. Additionally, you’ll get the following benefits.

  • Technology inevitably gets complicated and you may find yourself stuck. Explaining what you’ve done and how you’re approaching the problem is a great way to free yourself.  If your partner isn’t around you can try the rubber ducky method.
  • You can foster a little friendly competition to push you to learn faster.
  • If the project needs it, one of you can do a deep dive on a specific aspect of the technology while the others continue to learn broad concepts.

5. Get your hands dirty and make a mess

Learning the ins and outs of the technology goes faster when you code fearlessly, build prototypes, and make mistakes.

You’ve given yourself a solid foundation. Now it’s time to start playing around. Set up a sandbox environment where you can make a mess and not have to worry about breaking anything.

Copy and paste examples you found during the discovery phase into your sandbox. Aim to get stuff working, not pretty. Avoid optimizations, refactoring, or sticky points like code formatting or architectural decisions. You’re making a proof of concept, and most likely, you’ll want to start fresh once you’ve proven that things do work.

Sometimes clients want to see prototypes as validation that you’re making progress. This is a risky situation, you’ll be tempted to let them think their product is farther along than it is. Make sure you’re honest with your client about the state of your prototype so they understand that you still have a long way to go before you’d be willing to ship anything.

6. Now, go deep

After you’ve mastered the concepts and experimented a bit, you can deepen your knowledge of the technology through edits and iteration. And finally, you can start turning your prototype into something you’d be willing to ship.

Go back through your code and find places where you made poor assumptions or bad architectural decisions. Start researching those concepts deeper. Bounce ideas off your team or study buddy. Now for the hard part.

Show your cohorts your code.

Give them the context they need to help you evaluate it. Make sure they understand you’re new to the technology, and that this is a first attempt. Highlight where you’ve done something that you’re not quite sure about or where you feel like you were fighting the technology. Explaining your code will give you new perspective on it which should help you improve it.

More than likely, you’ve come to this technology with preconceived notions about how it works. Now is the time to break those ideas and reevaluate your understanding. Be vulnerable about your code. Accept feedback and suggestions.

Make improvements and iterate on this step in the process. You’ll know when you’re close to the finish line when people don’t have any comments to make other than “Looks good,” “Makes sense,” or “Ah, that’s how that works.”

7. Teach Early, Teach Often

By this stage you should have an idea of how the technology works. But no doubt you’ve still got questions or areas you haven’t explored. That’s OK. Don’t let that stop you from teaching others. You’re going to get more out of teaching than you expect because your knowledge is going to become bulletproof (or you’ll at least start to see where your weaknesses are).

Every time you explain how you solved the client’s problem in the technology, you’ll affirm your decisions. And every person who asks you a question about it will help you broaden and solidify your knowledge. One great way to teach others is to prepare using the Feynman Technique. There are plenty of articles and videos to be found on this technique, but the gist if it is:

  1. Write the concept’s name down.
  2. Add an explanation of the concept in simple language. If you get stuck, work through examples and do more research until you can explain the whole concept.
  3. Identify areas where you fooled yourself with your explanation. Go back to your research material and examples to improve your understanding.
  4. Perform editorial passes to remove technical and complex terminology.

Using this technique you’ll find the places where you need to research a bit more before you start teaching people about the technology.

Not only is teaching going to solidify your knowledge, it’s an excellent way to jumpstart other people’s knowledge, too! Start teaching peers or writing articles for your blog (like this!). When you feel really confident, graduate to presenting at conferences or user groups.

BONUS: Now, Embrace Continuous Change

The more you embrace the change that defines the technology industry, the more comfortable you’ll become learning new things. Soon you’ll be grabbing every chance you get to learn something new. Make sure you set expectations with people who are depending on you and they’ll come to depend on you to take on that crazy new thing your client wants. Repeat these steps and keep following your roadmap.