DeveloperDilemma #ImposterSyndrome #JuniorDevHelp
Hey fellow devs! 👋 Have you ever felt that wave of shame wash over you when you don’t finish all your tasks for a sprint? 🤦♂️ You’re not alone!
I recently started as a junior dev, and I often find myself not completing all my tickets before the sprint ends. It’s tough when I see my seniors having to pick up the slack or make corrections to my work. 😔
Here are a few tips I’ve found helpful in dealing with this situation:
- Communicate: Talk to your team about your struggles and ask for feedback. Transparency is key! 🗣️
- Time Management: Try breaking down tasks into smaller chunks and setting realistic deadlines. 🕒
- Self-compassion: Remember, everyone makes mistakes and has learning curves. Be kind to yourself! 💕
Let’s support each other in overcoming this hurdle and growing together as developers! Share your thoughts and experiences in the comments below. 🚀 #DevelopmentJourney #SupportiveCommunity
You’re brand new. Pad all your estimates a bit more and update timing as well. Assume you’re going to have to get reviews in place and see if you can attend or schedule office hours with a senior staffer so you can learn as to what you need to be doing better.
>The thing that strikes me, is that my company is busy to the point that PR’s are reviewed a day before release, while they were available for days to weeks. This causes me to have to rush things before the release to finish them in time and I am not able to.
PRs shouldn’t wait more than 2-3 days to be reviewed. What your company is doing is not good software engineering practice. There needs to be time to test PRs and resolve conflicts + fix any defects caused by PRs.
Depends on the management in your company. If you feel that they will listen to you, bring it up. If you have seen a lot of bugs after release, use that info and ask if it is possible to have rules where PRs should be reviewed in 3 working days max.
I have been consistently missing sprint deliverable for past 1.5 years at large tech company. Will update you when I get fired.
Hey I was like you too, stressing out i can’t finish my story for this sprint. Literally spend hours night trying to solve it, and roadblock after roadblock.
Things I learned early on.
Good team does not really care if your story needs to drag out to the next sprint. Is your story blocking others? If so, you’re a junior dev and you have the responsibility to speak out early on, and ask for help.
If not, its okay, split into small task, like subtask and bring it on standup, closed the subtask etc. At least shown you did XYZ but not quite close yet.
Basically early in the sprint, check for massive blockers, and get PR reviewed because well we junior engineers make mistakes and needs to pivot or we headed to the wrong direction.
So you’re in control and accountable of what you can do. Whether your teammate is not helpful or not, at least you bring it up to your manager and your manager can see at least you’re trying.
All the best!
Bring this up in your dailies, “I have x number of PRs that are waiting for reviews and are currently blocked.” Make it known that you have done all you can and now it’s on others to review.
Bring it up with your manager during your routine 1 on 1 meetings.
>The thing that strikes me, is that my company is busy to the point that PR’s are reviewed a day before release, while they were available for days to weeks.
Either the ticket was not urgent enough that it needed to be finished in the sprint, or your seniors are disorganized. Either way, not your fault.
Just remind your team that your PR needs to be reviewed at standup. Yes, I know you already told them yesterday. Tell them again today. Tell them again tomorrow. That is the limit of your responsibility.
Ya… estimates are just that. Estimates. In the Waterfall days we’d spend weeks or months planning and designing everything. I remember 200+ page specs. Even then our estimates were +-50%. With agile you skip all that planning with the understanding the estimates are worse. You learn through experience how accurate your estimates are and account for it. In general any new dev I take whatever estimate they give and double it. That usually gets things close. Over time make your estimates and measure how long things actually took and just that as a general multiplicative factor. My personal factor is about 2.2x.
Note, even then it’s still an estimate and missing shouldn’t be that big of a deal.
All. Sprints. Are. Estimates!
IMO, it’s perfectly fine to miss deliverables in why. It’s worth recalibrating why tickets took longer as estimated. And, with that information in hand, you can now better estimate down the road how long a similar ticket can take. It shouldn’t, ideally, ever feel like a punishment.
While the code review process can be improved at your company, tickets not being completed in a sprint is actually pretty common! At least where I’ve worked, YMMV. So your colleagues might be sincere when they say it’s not a problem.
I agree that it’s worth bringing up with a manager in a 1:1 so you can brainstorm ideas for improving team velocity in general, like setting expectations for the team for how quickly PRs should be reviewed.
Are you having problems completing the work or is it a sizing issue? External factors that cause you to miss shouldn’t make you feel guilty either.
Sounds like bad procedures. The best you can really do is finish your work super early so you can get the PR review ahead of time and then spend the remaining days before release fixing whatever is needed. But that’s obviously not healthy.
A great company or team will not look at your failure as your own, but as a whole. You should also be doing your part by voicing your concerns.
Whenever I get tickets that are not in my domain or that I do not have experience with, I always make it well known before hand. This sets the expectations. Somebody else with domain could do the ticket within 1 day, but for me it’ll be 3-5 days.
Bring it up with your manager in your next 1-on-1.
I was let go after 2 months in a job because of missing Sprint deliverables.