Why aren’t you doing better?
In my years of mentoring other engineers, I’ve noticed a pattern that often arises as they reach the cusp of “Senior Engineer” status. In general, these are folks that…
Make regular contributions to their respective teams
Aren’t receiving any clear, negative feedback from their direct manager
Achieve good (or great!) ratings in their formal performance review cycles
And yet…
These same people tell me that they’re not moving fast enough…or their designs and solutions are not good enough…or just generally that they ought to be doing better.
It’s clear that these concerns are a burden. It nags at them and causes them to doubt the positive feedback that they do receive. Some individuals have even told me that it causes them to doubt whether they’re even suited for a long career as a software engineer.
This feeling can also be incredibly isolating. Because their self evaluations are so out of step with the feedback they receive, they may start to doubt whether they can trust the folks who are providing them. This can make it daunting to challenge the feedback, which can set off a negative spiral.
It’s a scary place to be.
But don’t worry: if you feel this way—or if you’ve ever felt this way—I wrote this post just for you.
Why do things suddenly feel so bad?
First off, there’s one thing that I want you to hear loud and clear: it’s normal to feel this way. I know that doesn’t make it feel better, but you’re not alone, and that’s important.
If I had to take a wild guess, I’d say that there was a point in your career—probably quite recently—when it felt like you were growing by leaps and bounds. Every week—maybe even every day—you were learning something new and putting it into practice, and it was exciting.
And then one day…it just sort of stopped. Not in the sense that you can no longer do those things you learned—you can—but it doesn’t feel like you’re getting better. Something’s off.
What happened?
My very short answer is that you’ve hit the second inflection point on the learning curve for a lot of the skills that you use day to day.
A lot of skills follow predictable patterns of growth, like this one that I grabbed from the Wikipedia page on learning curves and shamelessly annotated:
If I were to tell a story about that curve, it would be this:
After an initial period of struggling, folks will enter a period of rapid improvement. After a period of growth, skill acquisition will dramatically slow, and further progress becomes significantly more effortful.
It turns out that for a lot of skills used in software engineering, the rapid improvement phase can last for a few years…in other words, about the length of time that it takes to get from the beginning of your first engineering job to the cusp of being a Senior Engineer.
That’s why you feel like you just hit a wall. You’re trying harder and harder, but you’re not seeing the results that you’re used to. It’s not you: it’s just the nature of the skills you’re practicing.
Or at least, that’s a big part of it…but there’s another factor that might also be in play.
Software engineering involves many different skills, and I sometimes lump them into two broad categories: “doing” and “appreciating”.
“Doing” skills are easy to list: writing code, designing interfaces, building tests and test plans, and planning database migrations are all things that you can learn to do.
“Appreciating” skills tend to be a little more nebulous: inferring the intent of an original author, finding the highest point of leverage for a change, evaluating the appropriateness of a proposed design, and even developing a nagging sense that there’s a bug you haven’t yet spotted are all skills that activate our capacity to appreciate quality in the software engineering artifacts that we encounter.
The second category comprises what we might call one’s “taste” as an engineer. And while it’s hard to do things well without having taste, it’s quite possible to have good taste without any other ability, as anyone who has struggled to learn to play an instrument, make a short film, or write a novel can tell you!
This is an important distinction because I’ve observed that a lot of folks hit the second inflection point for “doing” skills much earlier than they hit it for “appreciating” skills. So even though it might suddenly get harder to improve at building things, your taste keeps getting better and better.
On a really bad day, it might even feel like you’re getting worse because the gap between your skills and your expectations of yourself is growing.
Now there’s a recipe for misery.
At the same time, your more experienced peers have learned to expect to see slower growth rates, and their feedback for you will typically have this expectation baked into it. If this isn’t called out and clearly explained—and it usually isn’t—it can feel an awful lot like gaslighting.
So that’s why everything suddenly feels so bad.
As an industry—and even speaking for myself in particular—we’re not great at preparing junior folks for this inflection point, and I know that this failure causes needless worry—and even burnout—for incredibly talented and promising engineers. I’m sorry for my part in that.
But what do I do about it?
Ira Glass, the host of This American Life—and a master of his own craft—talks about this exact feeling. He speaks about it with more eloquence than I could hope to, so go watch him talk about it . (YouTube link, 5 minutes 20 seconds)
The short version is this: keep putting in the work, even—especially—when you’re not satisfied with your own progress. If you do, your taste will guide you in the right direction.
That said, there may be some additional, specific things you can do to nudge yourself along a bit faster.
One idea is to find some specific role models—who exemplify the ways in which you aspire to excellence—and emulate them closely. When I was hitting this stage in my career, my boss suggested two such role models for me—Ed and Bradley—who each had about 10 years more than me, and he told me to “be more like” them by studying their code, modeling my own code after theirs, diligently seeking their feedback, and trying to anticipate what design elements they would regard as most important.
Their enormous lead on me meant that I continued learning from them for years, and it did accelerate my growth considerably. Later, I also started taking long term ownership of systems that they had initially designed, and this taught me even more about the long term implications of their values and choices—both good and bad.
Another idea is to capitalize on the freedom that comes with being your own harshest critic: when there’s no one telling you how you need to improve, you get to choose how you want to improve, and you can invest effort in growth however you like.
This is where the role of taste comes especially in to play: once you’ve decided for yourself which elements of your work are most dissatisfying to you, focus on those. When asking for code review and other feedback, bring them up. Chase down exemplars of the skills you want to master and schedule some pairing sessions with them—then deeply interrogate their approach and choices to understand them better.
Will this feeling go away?
No? Yes? Maybe? I don’t know.
It also depends on which element of the feeling we’re talking about. If we’re talking about the fear that you’re secretly failing at your job and no one is telling you about it, then yes, that feeling often goes away—and you can often banish it more quickly by naming this feeling with people that you trust and asking for their bluntest feedback.
But the rest of the feeling? The nagging sense that you ought to be able to be better at the things you’re trying to do? You might be able to chase it away for a while by chasing after some new skills and climbing some new learning curves, but it’ll be back, sooner or later.
On the other hand: now that you understand where your discontent is coming from, would you really want it to go away?
Certainly, there are some folks who get crushed by this feeling, and it causes them to burn out and leave the field. And there are others who manage to get by with burying the feeling or keeping it at arms’ length. These folks may have solid careers in software engineering, but they never seem to quite reach the apex of what they might be capable of. Certainly, this feeling isn’t doing these folks any favors, and I’d change that if I could.
But if you’re the sort of person who reads to the end of a document like this, I have a feeling that you don’t fit into either of those camps. And for you, there may be another option: using the discontent as a guide and inspiration.
I have learned to love the periods during which I have a deep discontent with my own work because these are the times that so often produce the most unique outcomes within my career. It’s not a stretch to say that I’ve reached my current position through chasing discontent and letting it propel me into new opportunities.
You can do that too, if you want it.
You’ve got this.