3

I am a junior developer in my team. I joined this team last year and it is my first job. Our working hours are from 10 to 7.

When I share some PR(1) with them. They take good time a to have look at them. Most of the time, on the last day of the sprint(2), when time like (5-6 pm) they are like - "this should work like this, this is wrong" etc. I do not have any problem being told where my code is wrong, but I do have the problem with the timing.

On last day of sprint, during few last working hours of the day, being told "this is wrong, that is wrong, correct this" is terrifying. I, so, many times wanted to ask them, "What were you doing earlier, sleeping?"

And if there is a story(3), of which I do not have any idea how should that work, if I ask more 4-5 questions .... he is like "You leave it. I will do this" instead of explaining me anything. This is so rude and irritating.

Because they are my seniors I am terrified of bring this topic during retro or in front of managers. How should I deal with this ?


1) PR = "Pull Request". Where a developer asks peers or seniors to review their work.

2) Sprint = Work is arranged to fit into a known short period of time, called a sprint, usually of 1 or 2 weeks duration. The team should ideally only commit to as much work as can be achieved within that sprint.

3) Items of work are presented as user "stories" which will typically contain only a small amount of functionality. E.g. "As a business user, Given that I have selected a date range, then the report should only include invoices for that period".

6
  • 3
    What do you think they would do over something like this? Fire you? Berate you? What actual harm could come of telling your seniors that their timeliness is causing you issues. Perhaps there are reasons you don't know. They might tell you those things. More concerning to me is that you won't bring it into a retro. You should definitely inform your manager of that. Retro is supposed to be a safe space. – Joel Etherton Apr 27 '20 at 18:11
  • Since you are talking sprints I guess you are doing Scrum. Is a code review part of your definition of done? If so, why is it done at the end of the sprint? Does the ticket stay "in progress" until then? – nvoigt Apr 28 '20 at 5:26
  • 1
    You could consider asking them if they could have a look at your pull requests, that's what I do that when it's important. – Clockwork Apr 28 '20 at 9:13
  • Is there an agreed definition of done? Do user stories each have clear testable given when then acceptance criteria? – ChrisFNZ Apr 28 '20 at 9:55
  • You are right not to address behavior of others in a retrospective. It could end up with them getting defensive and trigger a "blame storm" which puts you in a much more vulnerable position. It's far better to approach these people individually (not in a formal meeting) in a low-pressure context and try to assess what they need and tell them what you need. – teego1967 Apr 28 '20 at 12:20
8

Because they are my seniors i am terrified of bring this topic during retro or in front of managers. how should i deal with this ?

You should not be terrified. In fact, the Retrospective is exactly the place to bring these things up from previous sprints. However, you should also bring it up professionally. A phrasing that comes to mind:

Last sprint, I was given feedback on my progress and code only until the last day of the sprint, and only a few hours before the end of the sprint. This gave me little to no time to complete the changes requested.

Keep it simple and stick to facts. Also, no need to point fingers or mention specific coworkers unless prompted. Your manager or scrum master should now be aware of the situation and be able to handle it.

Now, regarding short-tempered coworkers that lack patience and teaching skills, there is few things you can do to change them. You can, however, decide if you get offended or not by their blunt response (I suggest you don't).

Alternatively, you should by now know which coworker is more patient or kinder towards you. This is also a great opportunity to improve your self-sufficient and googling/researching skills: try to google and think possible solutions before asking coworkers.

Perhaps you are not doing this and that may be why they are reluctant to help or answer all your questions. If you show them that you put some effort before asking them (like, exposing the possible solutions or aspects you researched) you will surely get better feedback (heh, even on the whole SE network we encourage users to put some effort into their questions, and those who don't usually get not so good reception).

Finally, I'd say that as you are a Junior you still have things to learn, and each day you will be more and more self-sufficient (or at least you should if you practice your skills), so it's ok that you ask if you put some effort before doing so.

1

Clarifying your doubts / reviewing your code at the end of the working hours might be just a sign that they are overwhelmed and that happens a lot. On the other hand, that can't hinder you from getting the job done, so the only way out is having a candid talk to them. If that fails, that's were the management comes in.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .