Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
Hazarth73891yYes and yes
Rule of thumb, you stop being a junior after 3 years
But really It's all about your attitude. I've seen fresh juniors being able to carry a lot of responsibility and helping others without second thought and I've seen "seniors" making the dumbest mistakes and being completely full of themselves...
The main point is how much experience in the field you are, but some juniors learn fast and some current seniors learn super slow... So really that 3 year estimate can fluctuate anywhere from a year to never xD
Crost41891yJunior - needs hand holding
Mid - can work independently but needs guidance
Senior - provides guidance
Both juniors and seniors might struggle with horrid codebases.
The difference is: for a junior dev people worry for the dev "How well will they do?"
with senior devs people worry for the code: "How badly will the dev complain about this code?"
with a junior dev the question is: "was the code too advanced for them" and with a senior dev it's "was the code too advanced and should be simplified"...
With senior devs if there's a problem the code is blamed rather than the dev.
A small bit of this relates to self image. If you'd look new job today - would you be OK with a "junior dev" position?
(In my mind there are at least 3 levels. junior, senior and an unspecified mid level just called "developer")
Many devs underestimate themselves and think of themselves as junior long after experienced colleagues rate them as being beyond junior.
But if you'd still accept a junior position you're probably not senior yet. You might be in that mid level. Part of being a senior dev imo is having lived through a few imposter syndrome episodes and having some confidence in knowing your level. (Which is important to avoid feeling crushed if you feel you're doing poorly in your first senior position)
You can stop any time you like
it's mostly about experience but maybe a rule of thumb can be derived from learning:
junior: is learning new stuff to be able to do their job.
mid-level: is learning new stuff to get better at their job.
senior: is learning new stuff to tech it to their teammates.
code ninja: is learning new stuff because learning is literally fun.
Inxentas8081yI will forever be a mid at max because I'm a decent dev but a terrible teacher.
Contemplating the sorites paradox aboard the Ship of Theseus
PAKA7491yYou stop being a junior when your company wants to start upselling you as senior instead of mid to the client.
jeeper5888346dDo you think about the long term consequences of maintaining the code you write? Do you use truly coherent and readable variable names? Do you consider the time/space optimization of your code when appropriate? Do you understand your code well enough that if someone made a case for throwing it all out you could defend it?
Juniors often can’t answer yes to all these questions or they think they can but their answers are not robust to follow ups. There is a difference but it is not much in coding ability, given good enough instructions we can all code pretty good stuff in most cases. it’s much more in terms of looking at the vague level of instructions we get and turning that into good code, rather than just some code that does the job. Sometimes that’s more code using oop concepts, sometimes it’s less code using procedural or functional concepts.
Midnight-shcode4895345din one of my jobs, only the senior (and team lead for 3 juniors, 4 when i came in) was writing and extending our internal framework with data access and processing functions that juniors needed and then used. i became de-facto second senior in the team a week after i started working there, when i extended the framework with some data access and processing functions i needed for one of the "easy intro" tasks, because the team lead forgot to make them before giving me the task. when he realized i did that, at first he was terrified and then happy when he found out they were written in the right place and exactly how he would have written them. shortly after he was delegating some of his framework extending tasks to me and some of people's questions about the system and its inner workings.
it's about the attitude plus (hopefully) the demonstrated skill.