Can't meet deadlines because dev team puts me through the gauntlet before my work can be accepted

Question

I started a new job about 2 months ago. I've been given a large amount of work and little to no guidance about the inner working of a very complex web app that is also tied to multiple IoT devices that have multiple hardware and software layers I am unfamiliar with. Aside from the usual issues of the company not managing scope well and me having to push back, I am being subjected to a "chip on their shoulder" code review of my work before it is accepted as done.

Now, I have many years of experience taking feedback from code review but these guys are relentless. They call out opinion based things like variable names, putting something in an existing module or creating a new one or force me to add additional scope of functionality that isn't in the original acceptance criteria before they will "sign off" on the merge.

Instead of being small iterative changes, pull requests drag on for weeks as scope creep sets in and bully devs keep finding new and nit-pikier problems with the code in their echo-chamber. This is causing me to make little if any forward progress on tickets and is making me look bad in the eyes of my team and manager.

I talked with my manager about this and she was very defensive of their existing process and said that I needed the buyin of the other developers before I could merge anything in.

Is there anything I'm doing wrong or is this just a crappy team with bad management?

Answer 1

You have to enter the system first to change it. If your way is not accepted, or even fairly evaluated, then that's the way it's gonna be. In time you'll establish your authority, stop being the new guy, and have your opinion heard more.

Your manager said you need the buy-in of other developers, which means you have to be accepted by the pack. It it what it is.

Now for some practical advice: Do they not like your variable names? Big deal, change them. Yes it's petty, but it keeps them off your back, and you don't have much political capital at the moment. Or if you want to mess with them, put in a ducky.

The one I'd be worried about is the scope creep. Do the other devs have the authority to expand the scope? In any case, every time this happens inform your manager by email (make sure to include links or IDs or whatever your CR system uses). The point here is to get a paper trail which explains your delays.

Answer 2

Disclaimer: I am a software engineer, I do code reviews, and I am nitpicky like this. This is why.

Without knowing precisely the issues you're having, a lot of these comments make sense to me from a code review perspective. Good, expressive variable names are important to code readability. If I have a variable called x, you have no idea what it does. If I have a variable called myApiResponse, that tells you:

1) It is an object.
2) It is a response from an API
3) The API is (probably) called MyApi

These are good things to know when reading and following code flow and are important for code maintenance. If your variable names are being called out, it's probably because they don't contribute to code readability and are going to cause problems in the future with maintenance. These things matter.

Likewise, putting things where they are supposed to go is important. Let's say you have a large application, a part of which is processing orders from your customers. So you have a CustomerService, which handles customer data, and you have OrderService, which processes orders. Let's say you need a customer's credit card information (for whatever reason you're storing that in your dataset). But you put your method to access that information in your OrderService, because "after all", the order service needs it. But then, you have another service, let's say your customer service dashboard, which also needs customer credit card information. But the person building the customer service dashboard doesn't know that order service implemented this function already, so they check CustomerService (where it should be expected) and don't see it and they go ahead and implement it. Now you have 2 implementations of the same code that have to be maintained. Suddenly you've doubled the code maintenance load of your feature to get customer credit card info, which you could have avoided if you'd just put the functionality in the right place where it belonged.

These are important things and they need to get called out in code review so they can be fixed before the code is merged, because if they don't you'll have lots of problems later.

Remember: The code review process is your friend. There is a reason code reviews are done, and there is a reason why code reviews are gatekeepers to merge your code, because nobody wants to deal with bad code. So do what the reviewers tell you to do and don't complain.

One note about scope creep: Push back hard on this. If what is being asked is not in the ticket, your response should be that the work for the ticket has been scoped and pointed (assuming you're using Agile/Scrum) and shouldn't be modified. If they insist on modifying it, say that the ticket will have to be re-estimated and it may throw off the scrum plans for the team, and mention this to your scrum leader and your manager. Adding stuff to tickets that wasn't originally estimated is very bad and shouldn't be done at all.

Answer 3

Whatever the reasons behind this process (and they could be many and valid) there is an unavoidable delay between you writing the code and it being accepted. You can't do much in the short or medium term to change this.

If you have some input into your deadlines then adjust your estimates accordingly. If anyone questions this just point out that it takes longer for your changes to be signed off as you are still learning the team's coding style.

If you don't have any input into the deadlines then talk to who sets your work or deadlines and explain the above to them. They should have the sense to schedule a bit of elbow room to mitigate any sign-off delays.

You haven't worked at the company long and are still learning a new team's process and standards (and how they manage requirements and scope). Some delays in getting code sign off is normal to begin with. You should find that this is lessened as you get some experience with the team and they get some experience with you and your coding style.

Answer 4

Code review criteria and development standards should be documented and thus repeatable by anyone with the same outcome. Ask for the documented development standards and adhere to these during development.

If they bring it something that isn't a documented standard for the company, recommend they have it added to the documented standard.

Regarding the scope creep, the time required to adhere to standards should be incorporated into your estimates -- if it's not, it's an issue with your estimation process. Always document anything that increases the development scope after your estimations have been incorporated into the schedule.