Hi, I'm Gregory Brown.
My goal is to help software developers get better at what they do, whether they've been at it for five weeks or fifty years.
(he/him)
As a junior developer, you're going to have quite a bit of uncertainty around any work that involves learning something you haven't done before. So if you're working with a team that is expecting time estimates or velocity measurements on your work in a serious way, it's a sign that they've got some learning to do about how to effectively manage junior dev workloads.
That said, some level of predictability is good for everyone on the team. So even if the "Full ticket" may have a lot of unknowns to it, you can probably identify parts of each ticket that can be done in a known time window, whether that's a couple hours, a day, a couple days, or a week.
By focusing on those sub-tasks and then raising a red flag if you get stuck on something, or by asking for help breaking down the rest of the ticket into smaller slices once you've finished all the parts you know how to do, you'll be able to keep things flowing and keep lines of communication open, which is what ticket tracking is all about, in spirit anyway.
It can also be a good practice as soon as you're considering working on a ticket to list out your unknowns, and then spend a very short amount of time (relative to the size of the ticket) exploring those unknowns. For example: "I've never worked with SomeLibrary before, let me see if I can at least get a few sample programs working with it" -- Then you can come back with questions and concerns before you get too deep into work.
I wasn't sure when you said you felt pressure if you meant there is external pressure from the team, or if it's more of an internal sense of "I should be doing better."
If it's the former, it's more complicated. But if it's the latter, I would say, three months is a very short time even if you're learning a lot. Give yourself permission to feel like a beginner at least for a few years! And then just look to improve where you can. (Which you seem to already be doing)
Thank you so much! This is incredibly helpful! I think being a newbie makes me doubt where the standards of a junior dev should be at. Obviously I aim to just trying my best and learn as much as possible. I know there are a ton of things to be learned and is a journey rather than a competition. But not being aware of how much is expected of me as a junior dev in my workplace has definitely being on my mind. It's nice to know what other devs out there think about this.
This gives me more confidence to raise the issue of expectations at work. Something to chat about with my colleagues, for sure. Thank you again :)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
As a junior developer, you're going to have quite a bit of uncertainty around any work that involves learning something you haven't done before. So if you're working with a team that is expecting time estimates or velocity measurements on your work in a serious way, it's a sign that they've got some learning to do about how to effectively manage junior dev workloads.
That said, some level of predictability is good for everyone on the team. So even if the "Full ticket" may have a lot of unknowns to it, you can probably identify parts of each ticket that can be done in a known time window, whether that's a couple hours, a day, a couple days, or a week.
By focusing on those sub-tasks and then raising a red flag if you get stuck on something, or by asking for help breaking down the rest of the ticket into smaller slices once you've finished all the parts you know how to do, you'll be able to keep things flowing and keep lines of communication open, which is what ticket tracking is all about, in spirit anyway.
It can also be a good practice as soon as you're considering working on a ticket to list out your unknowns, and then spend a very short amount of time (relative to the size of the ticket) exploring those unknowns. For example: "I've never worked with SomeLibrary before, let me see if I can at least get a few sample programs working with it" -- Then you can come back with questions and concerns before you get too deep into work.
I wasn't sure when you said you felt pressure if you meant there is external pressure from the team, or if it's more of an internal sense of "I should be doing better."
If it's the former, it's more complicated. But if it's the latter, I would say, three months is a very short time even if you're learning a lot. Give yourself permission to feel like a beginner at least for a few years! And then just look to improve where you can. (Which you seem to already be doing)
Thank you so much! This is incredibly helpful! I think being a newbie makes me doubt where the standards of a junior dev should be at. Obviously I aim to just trying my best and learn as much as possible. I know there are a ton of things to be learned and is a journey rather than a competition. But not being aware of how much is expected of me as a junior dev in my workplace has definitely being on my mind. It's nice to know what other devs out there think about this.
This gives me more confidence to raise the issue of expectations at work. Something to chat about with my colleagues, for sure. Thank you again :)