Congrats! You've settled in at your first job. You've made it past the initial wave of impostor syndrome and have some idea of what you're doing and what you're good at. You might've even received a promotion or two. You're no longer wildly floundering every day and are able to at least flounder in the right direction. You might even be on your second or third job at this point. You actually feel like a real engineer now.
Now what?
It's common to feel a sensation of plateauing after an initial few years of hypergrowth. This is only natural: Growth comes from new information, and the supply of novelty provided by a job quickly dries up as the years pass by. Up to this point, simply engaging with your job was enough to provide steady improvement; now, you must actively seek new information to keep growing.
Before proceeding, I want to clarify one thing: being happy with where you are is perfectly fine. You might feel entirely comfortable with plateauing, and that doesn't make you any less of a person. If you're content and have job security, congrats - you've won. It's not worth it to burn yourself out trying to level up if you're not motivated to do so.
Develop an Eye for Quality
When trying to grow as an engineer, the very first step one must take is to develop an eye for quality. Strive to be able to recognize quality in any domain, even if you're unable to produce it yourself.
Why is this so important? Simply put, you can't get better if you don't know what better is. If you simply accumulate more information without filtering that information for quality, you're wasting your time.
Developing an eye for quality begins with active thinking. Analyze new information in both top-down and bottom-up manners. Aim to go beyond identifying if something is good and instead examine why it's good.
- Top-down: Is this consistent with other things I know to be good? How does this information fit into my existing mental model of quality? Can I think of alternatives that'd be better?
- Bottom-up: What makes this good? What's the rationale behind this line of thinking or approach? Is the premise of sound logic?
Building a mental model of quality isn't trivial. Below are strategies I've personally found to be effective. The ability to recognize quality is both a prerequisite and an outcome of these strategies. Aim to form a self-reinforcing cycle with a positive feedback loop.
Build an Information Stream
Don't underestimate passive learning. Digesting a well-written article every morning results in a cumulative knowledge gain that adds up over the years. Think of it as a quick mental workout.
Build a stream of content that's of higher quality than your current knowledge. Prune it over time to keep quality high. You don't want to internalize bad principles or ideas, and you don't want to take bad advice from people not worth listening to.
Don't overcurate your content stream for specific topics. Directed learning is good for focused growth, but too much direction cuts off new information whose existence you weren't aware of. Some degree of variance is good to avoid overfitting.
As always, engage critically with content. Don't blindly accept arguments. Understand why the author thinks the way they do, and always try to grasp the context behind the writing. Mortimer J. Adler's "How to Read a Book" was a common recommendation when I was in grad school, where the vast majority of one's work is reading.
Optimize for information retention and retrieval. Taking notes and writing summaries helps with digesting information and has value even if you never revisit the notes ever again. If you have a bad memory like me, leverage bookmarks and other tools to build a searchable knowledge base.
Find what medium works for you. I have a hard time maintaining attention with videos or podcasts, so my content stream is 100% textual and consists of newsletters, blogs, and aggregators. Yours will likely be different. Everyone absorbs content differently.
Active learning is great but requires a higher level of commitment. Finding uninterrupted time to follow a prescribed curriculum can be hard as a full-time worker. If your workplace offers learning time and/or credits, take advantage of it. If passive learning is a steady trickle, active learning is a firehose to the face.
Find a Mentor (Ideally Multiple)
An experienced mentor you can trust can act as a calibrator for your developing mental model of quality. It goes without saying that prospective mentors should themselves have a refined model of quality.
It can also be helpful to have mentors both inside and outside your workplace. For the one inside, get advice on your career goals, project goals, and work-specific tasks. For the one outside, talk about more general engineering topics, and get a detached view of your current work situation.
Use your mentors to unblock yourself. Don't fall into the trap of stunting your own growth out of fear of bothering others. Have regular meetings with them, and solicit feedback frequently. A similar trap is not asking questions because you feel you should be past that stage. If you don't ask for help, your mentors might assume you're doing fine, only to be disappointed when your work is subpar.
Don't blindly trust your mentors. Analyze their advice actively and critically, even when you've established their eye for quality. Try to identify any biases they might have, and use those as a lens through which you interpret their advice. Find the path of reasoning they took to arrive at their conclusion; learning to reason about classes of problems is far more valuable than any individual answer.
Find well-balanced mentors. If you can't, find multiple mentors with a diversity of opinion. "Spiky" mentors offer quality advice but only within a very narrow domain. This can result in your model of quality becoming overindexed in this domain. If your only mentor is an engineering supremacist who hates managers, you'll become an engineering supremacist who hates managers.
There isn't necessarily an ideal personality type for mentors. However, we can converge on it via process of elimination. Avoid the following personalities like the plague:
- Hot-takers and hand-wavers: Surface-level thinkers whose models of quality overuse heuristics and aren't built on critical reasoning. They might seem knowledgeable due to being able to quickly form an opinion on anything; however, these opinions generally lack substance. They often care a bit too much about their Twitter follower count.
- Cargo-culters and gold-platers: People whose model of quality overindexes on social proof and/or the latest and greatest tools and tech. They might seem like bleeding-edge technologists, but remember that the role of an engineer is to produce value, not shiny code.
- Mules: Contrarians who are overly confident in their models of quality and view disagreement as flaws in other people's models rather than a potential flaw in their own. People who are right more often than they're wrong may start drinking their own Kool-Aid and miss the point when they start becoming wrong more often than they're right.
- Architecture astronauts and purity zealots: People whose models of quality operate at the wrong level of abstraction. Architecture astronauts are too high, while purity zealots are too low. They may be valuable and productive experts in their domain, but having such narrow blinders isn't conducive to good mentorship.
Push Your Boundaries
The easiest way to learn quickly is to push your boundaries by working on things just outside your level of expertise. This will force you to make decisions you aren't used to making and to practice recognizing quality.
Be aware of your gaps, and constantly reevaluate yourself. A helpful exercise is to develop a framework of engineering skills and evaluate yourself based on this framework. A sample breakdown that isn't necessarily exhaustive might include:
- Coding skill; pure programming ability
- Domain modeling; system design; architecture
- Ecosystem familiarity; knowledge of tools and libraries
- Interpersonal interaction (building consensus, effective teamwork, etc.)
- Project management (managing tasks, scoping, how to ship, etc.)
If working in a new domain, familiarize yourself with the high-level topics in this domain. Roadmaps like roadmap.sh can be a good starting point. Be aware of what you don't know; by knowing what's out there, you're more equipped to unblock yourself when a problem arises. Your toolbox may be empty, but you should know what tools you can acquire.
Practice your model by forming opinions. The act of judging if a certain thing is good or bad forces you to distill your model into rules and apply these rules to concrete things. Don't take mental shortcuts; ensure your logic is sound and you're not making tenuous leaps of logic. Being able to reason about quality shields you from cargo culting. Validate your opinions with more experienced people. Don't blindly take their advice; figure out why they do things a certain way and if it's good or bad.
Don't become overly reliant on asking specific questions (either to peers or on Stack Overflow). This will build fragmented islands of competence that might not ever become an integrated knowledge base. Additionally, solutions devoid of context bias your model of quality toward pattern matching rather than first principles. Read the docs to develop a foundation; then build knowledge on top of that.
Pace yourself. Continually working in an unfamiliar domain is stressful and risks burnout: You'll naturally be slower and may feel pressure to overwork to maintain your pace. One strategy is to alternate between growth tasks and competence tasks. This can prevent impostor syndrome while reminding yourself how productive you can be in this new area once you level up.
Minimize Feedback Loops
Growth occurs in a feedback loop of information encounter, synthesis, and application. The tighter this loop, the faster learning occurs. There are many operational tasks that lengthen feedback loops; identify them, and cull them.
Don't be bottlenecked by decision paralysis
Accept that you'll build things wrong many times. Bias toward quick feedback loops of iteration and evaluation, so you can pivot quickly without too much sunk cost. Identify what makes a minimally evaluatable product: enough work that lets you decide if you've made the correct decisions.
Don't be bottlenecked by brainless, repetitive tasks
Learn keyboard shortcuts for your tools instead of reaching for the mouse. Add aliases to your shell for repetitive commands and tools for repetitive workflows. Aim to operate at the speed of thought; execution should be aggressively optimized and automated.
Don't be bottlenecked by typing speed
If you're young, there's no reason not to have a best-case WPM lower than 60 or so (ideally, 80-100+). There's the idea that typing speed doesn't matter because one thinks far more than they type. I find this logic ridiculous: There will always be rote tasks where the only limiting factor is your typing speed. Additionally, being a master of keyboard shortcuts isn't an alternative; you can and should do both.
Don't be bottlenecked by code review
Segment your work into logical and understandable chunks. Craft your PRs to be as readable and as reviewable as possible. Respond to feedback promptly.
Don't be bottlenecked by your memory
Learn to document and take good notes. Every minute you spend relearning something you've learned in the past is a waste of time. Similarly, every minute you spend confirming some decision you forgot is a waste of both your time and someone else's time.
Shape Your Environment
You can't build a model of quality without a sufficiently large body of positive and negative signals. For most people, their source of signal will be their workplace. This is subject to diminishing returns; after three to five years, you've probably hit an inflection point of signal versus time. At this point, it can be worth seeking a role change. This can come from vertical movement (promotion), horizontal movement (role or team change), or changing jobs.
Roles can be incredibly different with just a few parameter tweaks. Some examples:
- Small team versus big team
- Public versus private company
- Tech stack (both components of and what part you work on)
- Cultural values
- Processes, patterns, and norms
It's worth experiencing a diversity of these parameters early in your career. The faster you can collect information, the faster you can build a good model of quality.
Your new role should have some overlap with your old role. You don't want to return to the floundering stage, but you want enough novelty to spur new growth.
Some environments aren't suitable for learning and growth. You may be pushed to stay in your lane because there's too much pressure to ship for you to temporarily lower your productivity to learn. Try to shape your environment by explicitly asking for different types of tasks; if this is denied, it can be worth changing jobs if your goal is to optimize for self-growth.
It All Comes Back to Identifying Quality
Identifying quality is the common thread tying each of these principles together.
Information streams provide new data to feed into your model of quality. A good mentor can direct your budding model, pruning and shaping it during its critical period like a bonsai artist. Pushing boundaries lets you put your model to the test. Minimizing feedback loops makes the information encounter-synthesis-model update loop as tight as possible. Shaping your environment ensures a constant inflow of new ideas and practices. And having a more robust model of quality makes you better at doing each of these things.
A parting thought: Is this article you're reading right now quality? I'm self-aware enough to know that I myself have many biases, even if I'm unable to pinpoint them. My anecdotal experience has an outsize impact on my priors, which can lead me to dramatically different conclusions compared to others. Where are the tenuous leaps of logic in this article? Where are my biases showing? I'd love to hear from you in the responses below.
Top comments (2)
Thank you for posting this article. I think one of the major challenges for me is the "paralysis" issue. Fear "that you will build things wrong many times", which holds me back from touching a technology in the first place.
Also, what outlet do you go to in order to find mentors? I have been poking around Discord this past month or so.
Hi James, thanks for the response.
Regarding mentors, I generally start my search at the workplace. I try to identify the people I can learn from as early on as possible, and build relationships with them. A second outlet for me is my local tech community. Finally, I think of a lot of the writers I follow as mentors in a way (though they have no idea I exist)! At the end of the day, engaging with a wider network of engineers is the first step.
(While I'm somewhat active in online-only dev communities like Discord, I haven't tried finding mentors there. I feel it's too hard to get a read on people without deep conversation, or being able to pore over a corpus of their work.)