5 years in and you’re stuck?
What mistake is excusable if you’re a new dev, but inexcusable if you’re five years into the profession?
Not being able to reason about a new-to-you codebase. Up to a point, this holds almost regardless of how big a pile of spaghetti it is.
As a new dev, either fresh out of school or working your first professional job after self teaching and maybe working on your own projects, you come into a new codebase and it is nothing like your well structured learning examples. It doesn’t make sense. So you ask your colleagues a lot of questions.
You have someone walk through the code with you, or explain where to look for things. Sometimes they’ll even sketch out a solution for you.
“Hey, I’m working on TICKET-123. Where does the thingamabob method get called?”
And then you do it again on the next program or service. No biggie, you’re new to this whole world of real-life hairy, spaghettified, idiomatic (some other idiot’s idiom) code.
But after a while, you know the codebase inside out. You’re a rock star. You deserve more money, and management doesn’t see that/can’t afford it/has a standard pay rise process and so you move on to another company.
Whole new codebase, whole new bowl of spaghetti, whole new set of idioms. Or if you’re lucky, it’s not a bowl of spaghetti; it’s legit, well structured, well tested code. But the first thing you do is ask someone to walk you through it, explain things to you.
And if that’s six months into your career, maybe that’s still okay.
But by five years in, you should have learned enough about recognising patterns, about tooling, about how to figure out what new-to-you code does, that what you’re seeking from peers is not an explanation, but a confirmation. “Hey, I’m working on TICKET-123, the one about the bug in the thing with the whatsit. Just checking, the whosamabob looks like it needs the whatsit to send an int. That would be coming from an API call… right? would that be us, or one of our vendors making that call?”
Now, don’t get it twisted; questions are always a good thing. Always. But five years into making and maintaining software, you should be able to figure out what new code does without having the explanation handed to you on a plate with pre-buttered buns on the side. Even if you’re at a new company. Even if their docs are shithouse to existentially challenged.
The calibre of your questions should be different, and the point in the investigation in which you ask should be different.
After five years, you shouldn’t be saying “Oh, I’ve never seen this code before. Don’t know where to start. Little help?”
After five years, it should be “Oh, I’ve never seen this code before. Gimme a minute. I got this.”
You may say that sometimes it’s not efficient to spend the time digging, and therefore disagree with the thesis of this answer. I want to clarify (or reiterate, since it’s in the first line of the answer): the mistake isn’t asking for help with a new codebase; it’s not building the ability to not have to.
If you get through five years of professional programming and your first inclination to a new codebase is that you need the answers given to you, you’ve made a mistake somewhere in your skills development. Relying on the answers being given to you, to the exclusion of the ability to find out for yourself is the inexcusable bit.