Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
I feel a junior is more mid level when they are actively completing tasks of decent caliber with little assistance - even seniors need help at times.
I'm not talking "fix this bug, correct this typo" work.
You should be able to deliver a project / feature or feature set by yourself and have it production ready and tested both manually and with units prior to any QA getting their hands on it, reduce their workload some as they can be a great asset plus you can review your own implementation and make some judgement calls to correct something before it goes to the wild.
You should be familiar with the current platform/project enough that you are already considering best approaches to your problems, key word is considering - you are still subject to making wrong decisions, but it's the thought that counts. 😅 -
@C0D4 I see, sounds right up my alley. I do tons of unit testing and e2e testing, it's actually been a major focus as we pilot our e2e suite. Im currently guiding some less tech savvy people on it so we can get more support behind development.
By this standard I feel I'm pretty close to mid level. I doubt I could carry an entire feature beginning to end by myself, features for us tend to take an entire sprint with multiple devs (being >20 user stories), but I could easily discuss and complete a feature alongside other devs
And as far as thinking ahead goes that's what I aim for, though sometimes there's some architecture I'm not exposed to in my codebase that's part of another subtean with requirements that aren't intuitive and shift how we plan new architecture -
@C0D4 i only use tickets as an informal measure because I'm not quite sure how else to explain my contributions. My work in one Sprint might range from a text update in one feature to a complete remodel in another. It really just comes down to what the business Leaders prioritize. Deliverables are,well... Completing the tickets I pick up 😂
-
Our company has a unwritten rule: make sure a junior is capable to be a mid after 1 year from the employment day.
How do we measure whether junior is ready to be a mid? Easy. Simply put, an overlooking dev has to evaluate whether the jr is capable to work in his role alone, w/o anyone supervising him at all.This means, that jr must be capable to understand client's complaints/needs/requests, ask for clarifications if anything is unclear, come up w/ solutions to relatively simple problems, implement them in a manner that complies with project's patterns, codestyle, etc., using good programming practices, properly covers his code w/ automated tests. Perform deployments, monitoring and bugfixes. All this - by himself, w/o anyone overlooking, w/o anyone ready to pull the break lever on him. -
@Crazed architecture decisions, well I would leave that to a senior if you don't have working knowledge or is held by another team.
Mind you it never hurts to get some insight on their inner workings, saves everyone some time as you already know how things in another system are working.
It's been a few years since I haven't had to deal with e2e feature level deliverables - down side to being full stack at times, you become responsible for the entire thing 😅
I'd suggest keep pushing and finely tune your skills where needed to be able to reach a story level item rather then tasks - if that makes sense? -
@netikras only thing I'm a little cloudy on there is deployments, simply because the majority of our project I don't interact with. We're divided into UI and API and the API is kind of the beast here, but I'm a UI person.
Otherwise I do most of that, with the automation tests being new so that's an effort by everyone -
@Crazed Look, make yourself a favour and ask your manager, which criteria do you have to meet to leave Junior's seat behind you.
That's exactly what I did. And I got my answers. My manager liked my enthusiasm and attitude [the very fact that I'm looking forward to grow]. I believe it might bode well for you too.
After all all companies have their own qualification matrices.
Related Rants
This had to be posted!
At what point do you say a junior dev is no longer a junior? What metrics do you use? Like scope of knowledge, impact on team / code decisions, years experience, management skills, etc.?
I feel I'm qualified as a mid level developer now despite only being a junior for a little over a year. I had tons of internships in college and was kind of placed in a role where growing fast was required.
I broke a sweat for most of that ~1 year I worked as a junior and my contributions to my project aren't insignificant
I don't say that to toot my own horn here, I really do want to ground myself in reality. But I don't know if my standards are too low or my organizations standards are too high. FWIW, other devs on my team have commented privately / informally that the junior title isn't super fitting.
I'm still pretty dependent on my boss but that's more for final say of things. He'll often have some input to my work but I'll also be involved with design discussion and take up a large chunk of work without question. On light sprints I'm knocking out 20+ taskhours of work, going closer to 30/40 when things pick up. Not uncommon to kill 10 user stories in a sprint.
I don't know, what do you guys think?
question
career development
mid level
junior