You can't bruteforce learning
Hey!
Welcome back to another week of musings. It was a great week in the Bay. It was mostly sunny, with a few moments of rain here and there. But overall, it was an enjoyable experience.
I hope you had some restoration time!
Was this forwarded to you? You can subscribe here!
Learning to learn, or understanding how you learn best, is an essential skill as a staff+ engineer.
Even if you think you're all over the place, your mind might follow a sequence you're unaware of. Instead, attempt to get a more intentional approach to learning.
It happens to me often. I need to dive into a new codebase or domain, and I need to quickly assess, create a general picture, and determine where to dig deeper for more information.
These are some tips I've used over time to help me.
Don't try to take it all in
When I started my career and had to switch teams or help with guest development in another team, I thought I could manage the entire codebase simultaneously.
That has only worked for me after seeing several codebases and having a better grasp of pattern recognition in how people work around the company. After a while, you've seen most of the application archetypes.
Now, I take a more intentional approach. I will run the tests and check for different "levels" of testing, unit, integration, end-to-end (E2E), etc. At a higher level of abstraction, it's easier to understand the intention of the overall codebase.
Do you know what you're trying to solve?
One reason I was trying to take it all in was that I was also not clear on what I was trying to solve.
It's OK if you're curious about a new domain or what another team does in their codebase. But generally, it's best to have a goal in mind of what you want to learn or what you want to solve.
Having this goal in mind will help you narrow down where to start or what to look for. For example, some time ago, I wanted to see why the latency of a service had degraded on a particular endpoint.
Instead of trying to go through the whole repository, I searched for the piece of code that handled the requests and, from there, dug deeper into what caught my attention that could be at fault. Once I had an idea of how the endpoint worked, I went one level deeper into what the next level of code did.
Don't solve and understand
When learning a new domain or codebase, as in the last example, I try to explicitly avoid "solving" problems as I go through the new area.
Trying to solve problems simultaneously as learning might create the idea that you're getting closer to the solution, but you don't have enough context to be sure if that's the right solution or even the right problem to solve.
Also, you're spending more energy learning and trying to solve problems, which might cause you to miss an important detail.
Timebox learning
When talking about energy spent, I first thought I could spend hours or days diving deep into a domain or codebase.
But generally, you don't have much energy to focus so intently on a codebase or domain. I like to timebox my learning time. I would have a goal: "I want to understand the contract between consumer and product for the next 2 hours."
Manage your energy
Sometimes I'm not in the "mood," or have the right energy to learn a new language, but I might have the focus to give into reading a new API contract, do a code review, or helping with a design document.
Sometimes, we might be on a time crunch, and managing our mood might not be possible. In general, I find more favorable outcomes when working on it.
When I can't manage my energy, I need to turn around something quickly. Then, I resort to timeboxing or making smaller increments of learning.
Conclusion
Take learning seriously! It's an essential skill for success at any company, but understanding how you learn will also help you greatly in any area of your life.
Your turn!
Let me know how you learn or approach learning new things at work or in your personal life. You can tell me by replying to this email!
Happy coding!
Things I discovered in the past week
- Transitioning Discord’s Engineering Team to Cloud Development Environments: I've been researching cloud dev environments lately, and this was one of the most recent articles on that topic.
- Jumping into an existing codebase this podcast episode was one of the things that triggered this newsletter issue. I liked the suggestions being presented.
website | twitter | github | linkedin | mastodon | among others