Your PR is too big!!

[La Petite Valse]

Not sure if this should be in technical but I'm getting to a point where I'm very frustrated with my scrum master & team lead.

I've been working on a load of changes that have taken weeks and a lot of hair torn out due to constantly moving goalposts, bad communication etc - but that's by the by - all part and parcel of being a contractor I guess but I do have a scrum master who has a very poor grasp on English and, more importantly, not a clue on what the work is supposed to entail, which doesn't help.

Bottom line is that I've raised a PR and I'm being told that the PR is too big and I have to break it down into smaller PRs. The thing I'm working on is a whole end to end flow with a new integration with an authentication service & it's an all or nothing change - The model we're using here is raise PR, approve PR and it goes straight to Prod so without some kind of feature switching strategy this is going to be impossible to do. Furthermore, I've modified a lot of existing code so unpicking everything to implement some kind of feature switching strategy now is going to be a nightmare and will probably introduce all kinds of new issues.

Everything's covered by extensive unit tests, e2e tests and the regression suite passes fine - but the whole argument is that the PR is too big to review and I find that a bit of a weak argument at this late stage. Should this have been mentioned right at the start e.g. in sprint planning because I'd have though it should have been? Have not been made aware of that requirement at any point until now. Not really sure what I'm going to do here - feel like walking but it's WFH and a good day rate....

[northernladuk]

feel like walking but it's WFH and a good day rate....

Just the same next gig, and the one after that etc etc. Market is bouyant and unless you're doubting your skills there will be another gig out there so just go. Might need to grow some to make the leap but it's gonna have to happen eventually. Everyone always lists stuff like flexibility, quality of life, pick and chose gigs etc as the benefits of being a contractor but never do it. Many seem as miserable and stuck as perms are.

Leave, get a great new gig and look back at how awful this one was and ask why you stayed that long.

[La Petite Valse]

Just the same next gig, and the one after that etc etc. Market is bouyant and unless you're doubting your skills there will be another gig out there so just go. Might need to grow some to make the leap but it's gonna have to happen eventually. Everyone always lists stuff like flexibility, quality of life, pick and chose gigs etc as the benefits of being a contractor but never do it. Many seem as miserable and stuck as perms are.

Leave, get a great new gig and look back at how awful this one was and ask why you stayed that long.

I'm conscientious about what I do so being constantly blocked by the back end team's constant screw ups, among other things, makes me look bad because I don't look productive and I don't think anyone has any visibility on the performance of the team as a whole. They're just going to see a contractor who isn't delivering, whatever the reason.

Then again, this seems to be one of those gigs where none of the permies seem to be doing anything (esp my scrum master) so the temptation is to take my foot off the gas and see where that leads me. Trying do do my job well just seems to result in a load of stress.

[cannon999]

There is no such thing as a PR that's too big. That's just a lazy excuse of people who don't like doing proper code reviews. I have reviewed some big PRs in the past. Unless your PR contains 1 commit the reviewer should be able to go through the commits, run the code etc etc.

[rocktronAMP]

Not sure if this should be in technical but I'm getting to a point where I'm very frustrated with my scrum master & team lead.

I've been working on a load of changes that have taken weeks and a lot of hair torn out due to constantly moving goalposts, bad communication etc - but that's by the by - all part and parcel of being a contractor I guess but I do have a scrum master who has a very poor grasp on English and, more importantly, not a clue on what the work is supposed to entail, which doesn't help.

Bottom line is that I've raised a PR and I'm being told that the PR is too big and I have to break it down into smaller PRs. The thing I'm working on is a whole end to end flow with a new integration with an authentication service & it's an all or nothing change - The model we're using here is raise PR, approve PR and it goes straight to Prod so without some kind of feature switching strategy this is going to be impossible to do. Furthermore, I've modified a lot of existing code so unpicking everything to implement some kind of feature switching strategy now is going to be a nightmare and will probably introduce all kinds of new issues.

Everything's covered by extensive unit tests, e2e tests and the regression suite passes fine - but the whole argument is that the PR is too big to review and I find that a bit of a weak argument at this late stage. Should this have been mentioned right at the start e.g. in sprint planning because I'd have though it should have been? Have not been made aware of that requirement at any point until now. Not really sure what I'm going to do here - feel like walking but it's WFH and a good day rate....

[S]I don't understand this from human organisation and business process point of view. Well as a tech leader, myself, and not a team lead, should you operate like a Masterchef at the freaking "the pass" then? Who is calling the shots in your team? Is it you, the team lead or somebody else that is the ultimate decision maker?[S]

I misunderstood your post.

You don't have the power at all, at least politically as a coal-face worker.

In my opinion, the tech reviewers should know the extend of the task. For example if you refactor the core classes of the application with breaking compilation changes, and those affected classes have loads of dependencies then it stands to reason that there will large changes to a codebase. So a PR is to be critised as a too big is nonsense.

Consultant answer: depends if you walk or not. Family, food on the table, time on the bench, reputation damage with client / agent are all worth considering. In rare circumstances you might be able to grin-and-bear it and potentially move dev teams (in the old on-site days, when you could get acquainted with the other team working on the sexy project in the next open office), it is a tough decision that you face now and when the culture is so toxic and harmful, then I saw in another forum thread, how important mental health is for everyone here.

[Paralytic]

I've been working on a load of changes that have taken weeks

Why do you have a Scrum Master? You're not doing doing agile if you want to commit weeks of work in a single PR.

You need to be able to split your work into smaller pieces to allow more incremental PRs, or challenge your Product Owner if the user stories you've been provided with do not allow you to do so. You're right you should have mentioned that at sprint planning. If it now means you have to split your work down into smaller PRs and build in feature flags, then that is what you have to do.

Alternatively, speak to your lead designer/solution engineer, as it sounds like the work you're doing should follow more of an architecture migration strategy, and perhaps agile is not the best approach for that (so many companies think "do agile, deliver faster").

Are other people working on the same codebase that you're making some major changes to? If so, i can see what the PR is being rejected.

[_V_]

I like the phrase doing agile.

What you doing? I'm doing agile. Ah okay, carry on.

As the PR, if it's one giant commit where you changed hundreds of files, moved then, renamed them, and also added lots of new features, then yeah, you need to learn to be nice to your team mates.

[Paralytic]

I like the phrase doing agile.

What you doing? I'm doing agile. Ah okay, carry on.

I know, it's especially liked by management. We're not delivering fast enough, let's tell the team to do agile.

[northernladuk]

I know, it's especially liked by management. We're not delivering fast enough, let's tell the team to do JFDI.

FTFY