Being smart by itself doesn’t get you very far in life. After all, when companies hire for senior or executive positions, they often care more about how much relevant experience people have over how smart candidates are. If I’m a company looking to hire someone to build a payments platform, I’m going to choose someone who has successfully done it before rather than a new grad who’s smart and eager to learn.
At the end of the day, companies care about results. Skills and experience that can deliver results are the currency of the intelligence economy. Skills to acquire more skills (metaskills) doesn’t do squat until you gain those value-delivering skills, which requires a lot of relevant experience that isn’t just sitting around like shoe boxes in a clearance aisle. Companies don’t like waiting 3 – 4 years with the hope that someday you’ll be in that position to contribute.
The sad thing for young adults like me is that there seems to be no shortcut to experience. There is no substitutable skill that can replace relevant experience. It feels like when your manager says you have to work 4 years at a company to become a senior engineer, you have to wait patiently at your desk for 4 years like a good doggy waiting for a treat. Contrarily, she’s also not saying if you sit at your desk for 4 years, you’ll be promoted into that coveted position. “4 years” is a crude metric for saying you need to acquire the skills and knowledge that the experience of working 4 years in industry would confer you. Could we cut down the number of years working as a junior engineer somehow? Yes! Probably.
There are a few inefficiencies I’ve identified in experienced people that I think, when optimized, can cut down the amount of time required to become more senior. See, the issue with most experienced people is that the percentage of experience that ends up shaping their skills or informing their knowledge is very minimal. If I had to guess, it’s probably less than 20%, most likely below 10%, and definitely under 50%. For one, not every experience contributes to an experience’s person’s Pool of Valuable Experience. Not all previous work experiences contributes to someone’s marketable skill set. Sometimes very senior people work on things that don’t contribute to their skill set, and sometimes people spend months to years in a career dead ends. Similarly all the manual labor and grunt work don’t make people better at their jobs, and we spend more time on those activities than we would like to admit.
Secondly, people forget most of the experiences they’re exposed to. People have poor memories, and their memories decays in an exponential fashion. For example, one study cites that people forget over 50% of material presented within an hour, and over 77 percent over six days. 1 Most people aren’t proactive about which experiences they want to remember, and the underlying mechanisms of memory ends up only haphazardly retaining random knowledge.
Third, most people don’t apply personal productivity and meta-learning to skill acquisition, making them inefficient learners.
Let’s start with the most important factor — relevant experience. Unfortunately, most junior employees don’t get to control this variable in any large margin. Most junior employees have work assigned to them. Even if given the choice, these people can’t even identify which experiences are relevant to their growth. It’s a common fallacy to believe X, Y, and Z are relevant skills to becoming senior, when in fact it’s A, B, C.
For example, it’s common for new grad engineers to believe that being technically competent is the core component to being an engineering manager. Many junior engineers strive to be a master of their craft in hopes of acquiring that experience to become an engineering manager. But as they gain more experience and learn more about the role, they realize that even though technical experience will get you closer to being an engineering manager, what ends up being more relevant are people skills, coordination skills, and prioritization skills.
Do you know what skills are needed to be 3 career moves ahead of where you are now? What observations and assumptions makes you believe that? It’s probably the most important question you can answer right now if you want to cut down the amount of toil you do.
Once you know what skills are important for you to learn, you will have a much easier time identifying experiences that contribute or don’t contribute to those skills. At this stage you should both be proactive and opportunistic about spending as much of your work time acquiring these experiences. Mention the skills you want to develop to you manager, and ask if you could work on a value-delivering project that will feed you the relevant experience. Integrating relevant experience into your work is probably the highest yield thing you can do, since if you’re not in that position, you’re effectively spending 40 hours a week for a paycheck. Wouldn’t you want to get something more out of those 40 hours besides a paycheck? Wouldn’t it be great if you got 40 hours worth of salary AND 40 hours worth of experience? That’s 40 hours of time you save by not having to gain those experiences outside of work.
But I’m being a bit idealistic, it’s not always an option for all entry-level employees to have these opportunities, but you still need to seek them elsewhere. I recommend taking classes outside of work, either online or in a real classroom. Classes are more structured than other autodidactic projects and require very little upfront cost to get started. I also recommend finding any way to commit yourself to attending these classes, even if you have to pay money for it.
Another approach would be to design your own project. This is a bit more difficult, but much more flexible in response to your learning needs. Want to learn how to build a payment processing system? Design a project to try to build parts of it on your own time.
People generally have horrible memories, but human memory can be mitigated or solved. One tried and true way to overcome this is through the spacing effect. Spacing effect studies have reliably demonstrated that repeated exposures of information near the horizon of “forgetting” reinforces the memory of that information, beating uniforming spacing information and stimuli treatment. So if you can review the things you learned in your work, you acquire a stronger memory footprint of those lessons. Here’s a video that compares information retrieval practices by simulating the forgetting curve 2
I’ve had a hard time making spaced-repetition flashcards with the stuff I learned at work, so I had to design a separate system. I would consistently take notes of what I learned throughout my work. If I have a hard-earned lesson, I make sure to jot it down, along with any contextual information surrounding the situation. In my line of engineering work, I would take screenshots of error messages I see and write down resolutions to those error messages.
At the end of the week, I would write a weekly review, actively trying to recall what issues I ran into during the week and how I resolved them. The review at the end of the week helps solidify some of the understanding I have around certain issues. I sometimes write quarterly reviews and reflections and reread my notes.
Another important benefit of taking notes is that unlike human memory, notes don’t decay or die. They are effectively permanent. We can also utilize a remarkable trait of the human brain to effectively connect our brain into this persistent data store — our exceptional capacity to recognize things.
Humans are remarkable at recognizing things. A study consisting of participants being shown 10,000 random pictures over 5 days, participants scored an 83% success rate when presented images they have and haven’t seen. Similar studies with 1,000 random pictures elicited a 93% success rate. 3 Often when we encounter a familiar problem, we recognize we’ve solved it before without knowing all the details. If we have old notes available, we can look up the information in the notes without ever having to keep it in our heads. That’s why it’s important to take notes. I often forget very hard earned lessons, and it pains me that I spent 20+ hours figuring out a solution and then forgetting that experience by not taking notes. I would then have to commit a 5+ hour expenditure to rediscover that lesson. Had I spent 5 minutes writing down what I did, or what the crux of the insight was, I would have saved those 5 hours of toil.
Your knowledge and skillset doesn’t have to live inside your 3 pound brain. It can be in your notebook, where you can openly access it. It can be in your social or professional network, living in other people’s brains that you have access to (networking is important!). Amassing and retaining knowledge in a strategic way is the second most important thing you can do.
An experience is like a lemon. When we reflect on our experiences, we are figuratively squeezing the lemon for juice, and that juice are the skills and lessons we learn. The more we squeeze, the more juice we get, but only up to a certain point with diminishing returns. The better we get at squeezing, the more effectively we can extract juice from lemons.
When life hands people lemons, people don’t bother squeezing. They let all these lemons go to waste, and then complain how they don’t have enough lemons to make lemonade. Squeeze the lemons!
Let’s Squeeze Some Lemons
Let’s talk about the concrete logistics of squeezing lemons. I suggest people spend at least 10% of their time reviewing and reflecting. I timebox some time every week to reflect on some problems I’ve encountered. I review all the issues that sucked up a large portion of my time, and I reflect what strategies worked and what didn’t. I try to pick up methodologies that my coworkers teach me. I try to generalize the lessons as much as I can to other domain.
For example, if I had an experience in which I fixed a software bug by reading the memory layout of data instead of print statements, I might spend some time pondering some questions like:
- What were the strategies that I’ve tried before this? Why did it take me so long to use this strategy? Should I have done this first?
- Are there other places in I should be reading the memory layout instead of printing things
- Why was this strategy the one that resolved my issue? I wasn’t having any luck by print debugging, because by the time the print call was reached, all these side effects occurred. Maybe I could reason about the code more effectively by working an abstraction layer deeper, or higher.
If you have a hard time reflecting on these experiences, just print out a post-mortem template, and try to answer all the questions. That’s always a great start to a reflection.
Googled example for convenience: https://gist.github.com/juliandunn/52b4fbde451628e0fe48
During the reflection exercise, I usually come up with some questions that solicit some research. Maybe I realize I’ve been using a tool all week from a StackOverflow answer, and that makes me realize that there’s a high upside for understanding all the ways to use that tool. Maybe I’m getting lost thinking about how to solve a particular type of problem, so I look up similar results or examples on hacker news. Perhaps I have tiny slivers of knowledge scattered across a domain, and I look for some books or material to explain the foundational understanding that ties all the knowledge together.
Getting better at squeezing lemons
You passively get better at reflecting the more you do it, but you can also proactively build this skill by learning more about meta learning (Coursera has a course!). Also strong empirical evidence suggests that developing skills in critical thinking and having a strong mathematics foundation in at least high school-level mathematics also passively help learning. Some articles on this website also add more mental tooling for thinking about problems and solutions.
I’ll conclude by recounting how often I hear my peers working at companies who promote engineers mostly based on how much time they’ve been at the company. Phrasing around those reflections usually comes in the form of “if I stay another year, I’ll be promoted to an L4 engineer” or “my manager said they couldn’t promoted me because I haven’t been working here long enough.” I would be resentful to hear that compensation and titles at a company are determined by people’s tenure at the company. Working at such a company would be an exercise of learned helplessness — if my increased contributions and productivity to the company don’t confer me better compensation or titles, why should I care about whether or not I grow?
Fortunately I see enough counterexamples in which people assumed the roles the wanted despite the “seniority by senility” culture. I’ve heard stories of new grads becoming managers before their one year at a company, bootcamp grads who become senior engineers within 6 months of joining, salary bumps for employees in companies that claim to follow strict promotion cycles. These people were so good that they defy the timeframe people assume it takes employees to reach that level of competency. Because of these models, I am hopeful that people can proactively work towards the role they want to be in, without having to wait around for the position to come to them.
- Gwern has an amazing long-form article written on the studies of spaced repetition here.