As a junior developer with less than a year experience in coding. How long should it take me to complete full stack tickets at work?
e.g. a ticket has full features - graphql mutation, tests, frontend react modal, mutation, forms.
I have been in my first dev job for 3 months now but I still feel like I need guidance and I feel this pressure to deliver as fast as my colleagues with years of experience. A I missing something?
Top comments (5)
You shouldn't worry about it that you need more time. Only with a lot of experience you will learn better to estimate your work or to divide the tasks meaningfully. Every experienced developer knows this and will understand that you need more time.
It seems to me that you have to do many different tasks at the same time.
My advice, focus on one thing at a time.
So that you also have a sense of achievement, divide the individual tasks even more into subtasks. The best way is that they do not take more than 30-40 minutes per task. Maybe even less.
such techniques can help: en.wikipedia.org/wiki/Pomodoro_Tec...
You must not be afraid to ask questions!
Good experienced developers will take time to explain things to you if you ask.The best thing would be to ask someone to do code review with you on a regular basis. if you get a lot of criticism in the beginning, do not take it personally (as long as it is constructive). You can only learn from it
When you have learned something new, it's best to recap it later again and write it down.
Your superiors know how difficult it is at first. I'm sure you'll have puppy protection for e.g. a year.
Other people have same problems too, although these people have a lot of experience:
dataquest.io/blog/how-to-overcome-...
Wowsers. Thank you so much for the advise. I often get told I should aim for small tasks and this is a work in progress for sure.
Dividing a task by minutes up to maximum an hour seems super valuable. Will apply this for sure.
I keep forgetting how helpful code reviews can be. Will encourage myself and my colleagues to provide me with these as mush as possible.
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 :)
I am reading this over a year from when you originally posted, and wonder how you're doing now? :)