Walk into any engineering community online and you’ll quickly find yourself surrounded by old-time gunslingers shooting well-meaning advice at you: "Stop writing classes like that.", "Don't over-abstract", "Stop putting business logic in your controllers." and on and on. Just search the keyword "stop" on this site and you'll see what I'm talking about.
The advice is usually correct. Technically. But it feels a lot like a virtuoso guitarist watching a beginner strum their first G chord and saying, "Actually, you’re holding that completely wrong. Also your timing is off, your pick angle is inefficient, and you're muting half the strings." That's not helpful to anyone.
The truth is, every single one of those senior engineers wrote code that would make them cringe today. They shipped bugs. They nested callbacks eight levels deep. They used global variables without batting an eyelash. But they also learned a lot of valuable lessons first-hand.
Of course they don't want others to make these same mistakes but unfortunately that's not how this works. You can't tell a baby to get up and start walking and "learn from you". Good engineering requires balancing an overwhelming amount of variables, each of which needs to be mastered separately.
The 10,000 hour rule
It's tempting to think there's a shortcut—a book, a bootcamp, or a YouTube video that will transform your engineering skills overnight. But as Peter Norvig, director of research at Google, pointed out in his classic essay Teach Yourself Programming in Ten Years, expertise isn't a weekend project. He warns against the "Teach Yourself (X Language) in 24 Hours" books by noting that while you might pick up superficial syntax in a day, writing meaningful programs, debugging in the wild, and grokking an ecosystem takes deliberate practice over a decade.
Norvig draws on research from psychologists like Anders Ericsson, who popularized the "10,000-hour rule": mastery in fields like chess, music, or programming demands about 10 years of focused effort—roughly 10 to 20 hours a week of pushing your limits, getting feedback, and iterating on errors. Even geniuses like Mozart who was a musical prodigy at age 4, took 13 more years before he began to produce world-class music. The Beatles? A solid decade of small-club gigs before Sgt. Pepper's.
The 10,000-hour figure isn’t magic (Ericsson himself later clarified it’s an average, not a universal law), but the core insight stands: real skill is built in the muscles and intuition, not dogma. You don’t truly understand why eight levels of nested callbacks are painful until you’ve personally lived through the day when the innermost one throws and you spend six hours unraveling the stack in your head. You don’t feel the cost of an over-abstracted "service layer" until you're the one onboarding a new teammate number seven who can’t find where the actual business rule lives. These lessons have to hurt a little, or they don’t stick.
That's why the well-meaning "stop doing X" comments so often bounce off. The junior isn't being stubborn, they just lack the scar tissue required to feel the warning signs yet. Telling them "don’t prematurely optimize your code" is like telling a teenager "don’t fall in love with someone who's bad for you." The advice is correct, but it’s useless until life supplies the missing context.
In programming terms, this means your first few thousand hours will be messy. You'll write inefficient loops, ignore edge cases, and probably invent your own wheel. But that's the point: those cringe-worthy commits are your deliberate practice. The solution? Do it anyway. Build large projects, read other people's code, refine. Rinse, repeat. Books help, but nothing beats building something that breaks—and fixing it yourself.
Imitate the greats
One of the fastest ways to compress those 10,000 hours is to stand on the shoulders of past giants. Every painter in art school spends months copying the old masters stroke-for-stroke before they’re allowed to "express themselves." Musicians transcribe solos note-for-note. Writers literally re-type entire novels by their heroes.
Programmers almost never do this, and it’s mind-boggling.
You will learn more in one week of carefully re-implementing a well-written open-source project than you will in six months of reading blog posts titled "10 Clean Code Principles You’re Probably Breaking."
Pick something small but legendary. If you need ideas check out this Github repo. Not because you're going to ship your own Redis tomorrow, but because the act of re-creating it forces you to confront thousands of tiny decisions that the original authors already solved elegantly. And more importantly, you'll have a benchmark against which you can compare your work to.
But what about AI?
OK, elephant in the room. You’re being told from every corner that AI is the new 10,000-hour cheat code. "Just describe the feature, and let Cursor/Claude/Grok spit out the code." And on the surface it sounds good: The CRUD API that used to take days to build, now can be done in twenty minutes.
But here’s the quiet part nobody wants to say out loud: AI is an extremely powerful painkiller, not a cure.
It removes the immediate sting of "how the heck do I do this?", but it also numbs the very feedback loop that builds real skill. When the model writes a 400-line "service" that technically works, you feel productive. You get the dopamine hit of green tests and a merged PR. But you didn’t actually grow the muscle that recognizes why that 400-line file is a maintenance nightmare waiting to happen.
There’s no lasting satisfaction in vibe coding. You're not going to remember that time Claude wrote you a perfect pagination helper six months from now. You will remember the weekend you fixed a race condition that drove you crazy for days. That pain lodged itself in your long-term memory along with the solution, and now your intuition quietly steers you away from foot-guns.
None of this means you should swear off AI. I use it every day. It’s an incredible pair-programming intern: fast, tireless, and full of ideas. But treat it like one. Review every line. Ask it "why did you do it this way?" and make it explain. When it suggests something that feels off, dig in—that discomfort is the scar tissue forming.
Your path to "Senior" status
The senior engineer leaving the comment "Can we make this function pure, with no side effects?" isn’t lying. In five years you’ll probably agree with them completely, and you might even leave the exact same comment on someone else's PR. That’s not hypocrisy, that’s growth.
You’re just doing what every great engineer before you did: writing the bad code that's required before you can write the good code.
One day—probably years from now—you’ll open a pull request from some junior who's proudly over-abstracted the login flow into seventeen interfaces and a strategy factory. You'll feel that familiar urge to write "stop doing it like that."
And if you took anything at all from this article, you’ll pause, smile, and write instead: "Let's get on a call. I want to share some ideas with you".
Top comments (0)