In my 20+ years as a software engineer, I’ve constantly been asked or expected to learn complex things. In his book Deep Work, when talking about the knowledge economy, author Cal Newport writes, “If you can’t learn, you can’t thrive.” New languages and platforms are launched, projects get new requirements, libraries and frameworks release new versions ⁠— in software, the only constant is change. A friend who was recently starting a new role asked “Got any tips to help me learn this new landscape quickly?” When I sent him some very rough thoughts he said they were “gold” and encouraged me to publish them for the world to see ⁠— I hope others can find them even a little bit useful.

Disclaimer ⁠— I’m a breadth first, experiential learner. I try stuff and when it doesn’t work, I try something else, moving on to the next step as soon as it ‘works.’ This helps me create an ever clearer mental model with each iteration. This works for me, but I recognize there are many learning styles, and it may not work for you wholesale.

Define your goals

• Break whatever you’re trying to learn down into use cases. Start with bite sized chunks that take a few minutes and build on them incrementally. “Learning python” is too broad. Installing python, printing hello world, installing and using a dependency, reading from a file, etc. are more well-defined, and it’s easier to know when you’re done, therefore helping to reinforce progress.
  
  
• Consider how much you need to learn to accomplish each. Bucketing things into "need to know more" and "skip the details for now" can be helpful. For instance, I don't know how python dependency management works, but I can rely on it working and make progress without that knowledge.
  
  
• Start by just trying stuff. You might be scared that you’ll screw something up, but in my experience computers are pretty hard to break. Use the mental models that you already have to guess at how it might work. If it doesn’t, then you can respond to error messages.
  
  
• Take breaks. If you’re in the groove and cruising, by all means ⁠— keep in the flow. But if you’re finding that you’re losing steam, moving sideways, or retreading old ground, give your brain a rest. If you defined your goals in small increments, you should be able to walk away feeling like you made some progress and give your brain time to process what you’ve learned. 

Read the full manual (RTFM), but don’t try to internalize it all

• Get the gist. If you’re learning something with published documentation, read the intro, the first and last paragraph of each section/chapter, and the first sentence of every paragraph, along with any provided code samples. If you find yourself confused, back up a bit and go deeper as necessary.
  
  
• Heed the callouts. Callouts and tips can be really helpful. They’re often provided in spots where it’s easy to make mistakes.
  
  
• Create a ‘read later’ list. I’ll often find myself curious about how a related part of the system works, but unless it is something I need to know to accomplish the use case I’m focused on, I defer that. I keep a reading list in my todo app, but there are lots of solutions out there. 
  
  
• Use ‘getting started’ guides.This is my exception to the “just skim it” rule. Getting started guides are usually aimed at folks just beginning their learning journey and are designed to give you just enough information to accomplish a single use case. Don’t skim them ⁠— read the whole thing and follow along with the provided examples. Check GitHub for boilerplate projects.
  
  
• There’s more than just docs. Videos, podcasts, and livestreams can each be a valuable way to convey information, if they exist. Experiment with different media and find what works for you. Work your way up to watching / listening at 2x speed, but slow down for the interesting parts.

Learn to dig (a little bit) deeper

So you’ve trusted your instinct and just started, but you immediately run into an obstacle. Maybe it is command not found, NullPointerException, or a 404 on a web page. How can you get more information out of the system?

• CLI help. Most Command Line Interfaces (CLIs) will return some content for help, --help, or -h. There might be clues about the arguments and their order that could be useful. 
  
  
• Dive into the logs. Most systems will log some output, either to standard output on the console or somewhere on disk. Reading the logs can be like reading a story of what the system is trying to do.
  
  
• Crank up the verbosity. If you’ve read the logs and aren’t sure where things are going sideways, try increasing the verbosity of the output/logs. You can often find helpful clues and new areas to investigate that will help get you closer to the problem.
  
  
• Search for error messages. Others may have run into the same issue, and you might find a lead on a Q&A site, like Stack Overflow, discussion or support forums, or open issues in GitHub. Make sure you quote the error message and try removing parts that are specific to your use case vs more general.
  
  
• Read the Source Code. If you have access to the source code of the system, reading it can help you understand how the system expects to treat your use case. Don’t try to understand every line, but use class and method names as signals for the system’s nouns and verbs. For internal tools that don’t have good logging, docs, or help, this may be the only option. Not sure if the code is open source? Try searching for the library in your language’s package manager (npmjs.org for Node.js, pypy.org for python, etc) or try “GitHub {programming language} {package name}” in your favorite search engine.

Tip: Give yourself a timebox to avoid turning your investigation into a never-ending spelunking excursion. Decrease the size of your timebox as you gain comfort with the system. If you’re brand new to something, give yourself a few hours. If you’ve been living in the system for months, dial that down to 15 minutes.

Don’t be afraid to ask for help

• Documentation (see RTFM)
• FAQs
• Community forums
• Chat history
• Search

• What are you trying to accomplish?
• What behavior were you expecting, what did you observe?
• What have you tried?
• What’s your execution context? (OS, versions, plugins, etc)
• Here’s an (older) example from real life: https://github.com/Kong/kong/issues/1186 

Reflect on the process

• Summarize and share what you’ve learned - that’s a good habit for all knowledge workers
• Where did you spend time that didn’t help you get closer to your goal?
• What would have made it easier for you to learn again?
• Docs clarifications? Interface changes?
• Can you fix them (internal or open source) or suggest changes to make it easier for future learners?

Summary

Learning is an iterative process. Start by defining your goals, and break them down into bite-sized chunks. Get some context by reading whatever docs are available, but don’t try to digest them in one bite. Don’t be scared to try to get more information out of the system. Ask for help when you’ve exhausted your budget, but be very clear about what you’re asking. Create feedback loops to improve your learning process and that of future learners. 

Now go and learn something new!

Interested in working with a team that's just as invested in your learning and growth as you are? Check out our open positions and apply.