Advice on influencing from below?
Posted by testeraway@reddit | ExperiencedDevs | View on Reddit | 14 comments
Hoping for some advice on how to effectively navigate something that I haven't experienced before. Not necessarily technical advice, more so the best way to deal with the politics at play.
I'm currently dealing with a massive PR that introduces multiple concepts all at once. About a hundred files, introducing an ORM, various entities, validation, and this is all within a new application with a somewhat complex structure. This application has been created for us by higher level engineers. I've been trying to review the latest additions for days, and I'd argue it's a bit over-engineered. It also implemented work for a separate task, which I had been working on for a week or so.
A huge issue is that this new application isn't even functional when trying to run it locally. The new additions get us even farther away from a functional development experience. Some issues are related to misplaced files, implementing outdated dependencies, and severely verbose documentation. In a perfect world, our manager would step in and say something, but they wouldn't know what they were looking at.
In the past, I'd raise these issues in ways that proved to not be beneficial to me. Part of me questions if I should say anything at all. I realize there's the possibility that I may be in the wrong and can't keep up.
What is the best way to handle this? I'm looking to learn how a leader would go about this.
Routine_Internal_771@reddit
There has to be an exceptional reason why you're reviewing a PR which doesn't build.
Doubly so if it takes days to review.
Or
Clyde_Frag@reddit
Blows my mind the amount of threads about large PR size that could be fixed with this advice. You can have AI split the PR for you.
SnooCapers4506@reddit
Sounds like an AI was already used for that mess lol
testeraway@reddit (OP)
Correct, I don’t believe an AI solution is the answer. It was the cause.
testeraway@reddit (OP)
Fair question. I've been in and out of this context for a month or so. Priorities shifting. Now that I'm back at it, I'm trying to push things forward. I'm trying to help fix these things to try and make some kind of progress.
I'm a little lost in my career right now honestly. I've definitely done what you have suggested in the past, but I've noticed that the highly regarded engineers just jump in and do it themselves vs give constructive feedback. Maybe this is too big of a change for to start trying something different though.
abrahamguo@reddit
OK. The most important thing, when bringing issues to those above you, is to clearly separate unrelated issues. Right now, it kind of seems like your post flows randomly between three unrelated issues:
Each of those should be addressed separately, and possibly at separate times, depending on your judgement. Here are a couple further points about each of the three separate issues:
Issue 1:
(A) Are you familiar with all parts of the requirements/functionality that is being introduced within this PR? If not, you need to get familiar with that first.
(B) If you are familiar with all parts of the requirements/functionality, then were you involved in any of the technical architecture/planning before this feature was written?
(C) If you do want to suggest some changes to the PR, I find it's helpful to start suggesting some small simplifications/changes first. If the other engineers are receptive to those, you can let those spiral into bigger simplifications/changes. While doing this, make sure you're keeping all factors in mind, such as easiest future maintenance, readability, and project timelines.
Issue 2:
This one is pretty straightforward. I'd approach it in an upfront but completely non-judgemental way: "Hey, I saw that engineer X wrote this feature that I had been working on; is there anything that I can do in the future so that I don't accidentally end up wasting time on a feature that someone else builds?"
Issue 3:
Check with your lead developer; if they're open to it, then simply spend a little bit of time each story improving the local development a little bit. If possible, when doing story X, make a change to that part of the app to allow you to test story X locally. Do the same thing when you do story Y.
Don't stop all forward progress to work on this; just do a little bit at a time. Also, if you have a non-technical manager, I wouldn't bother them about this; they aren't qualified to give you advice on the technical side of things. Just fit in little improvements over time here and there!
testeraway@reddit (OP)
Hey thank you, this is helpful. To answer your questions:
Yes, I understand the architecture and what the overall intention is with this new project. The implementation isn't quite nailing it though in my opinion. I was not involved in the architecture choices or planning, and I believe this path was chosen by one engineer that is agnostic to our team. They started to review this PR as well, but they are known for not being responsive. It's been roughly a month since it was opened and they left comments on it.
For the second issue, I actually did already make it known that work was duplicated. Unfortunately, this is nothing new and I know it won't improve with existing leadership.
We do not have a lead engineer anymore. The person who created this large PR is probably seen as the lead right now, though they aren't on paper.
Part of the reason I've taken this on is because nobody else is. I may have gone way too deep with it though.
SnooCapers4506@reddit
Is it a usual practice at your org to have such big changes in one PR thats open for a month? In my opinion a couple of hours, maybe up to a day should be the goal.
testeraway@reddit (OP)
It’s a big issue that has a number of causes. When priorities change mid project, the PRs in flight normally stay open longer while the high priority project is completed. Sometimes people just don’t do reviews, which I’ve tried to fix in the past. So it’s not entirely normal, but it’s happened before. Only a couple people can effectively do code reviews right now anyway, which is another problem.
Naibas@reddit
It's normal to have large PRs during the early development on a new project. No concern there.
That's a fair argument. The follow up question is: was there a technical desgin before work began? If so, then it's a matter of if the implementation diverges from what was agreed on. If not, the problem lies there.
That's a red flag in 2026 when tools like docker exist.
In a more perfect world, there would be systems in place to prevent half these issues. Will elabore more below.
So, you make some valid points. I would argue based on the inforamtion I have that your intuition is mostly correct.
My advice to you is action speaks far louder than words.
What that means for you in this situation (this is what I would do):
To be clear, I'm not suggesting either of you are doing something wrong. The problem I'm seeing here is a failure to communicate on several levels, and a failure to have stable software from the start as a non-functional requirement.
Good luck!
testeraway@reddit (OP)
I agree about new projects and big PRs, I'm not surprised there. I think the difference is that there's some complexity in how everything works together. On top of that, it was mentioned a lot of it was AI generated, which explains some of the issues I've seen.
I also think you're right about it mostly being a communication issue. This has been an issue for a very long time now.
I should be more clear with development. It's set up in a way to run everything via Docker, or a hybrid solution. Hybrid meaning Docker running containers for message queues, database, cache, etc., and the main application running locally. Neither seem to function with the new changes, and some of it didn't prior. It's just kind of a mess right now from what I can tell.
Thank you for your input! I could go on, but based on your comments I'm realizing I've taken all these actions in the past. I think I'm just really burnt out.
Naibas@reddit
If nothing is functional and is impacting your project, then request changes: project doesn't pass CI. Move on to something in backlog and bring up this blocker everyday in standup.
Respectfully, if you've taken these steps in the past, then there was a failure to codify them in the team's process. This is the job. Build systems and processes that work.
Burnout is generally caused by an imbalance between workload and impact. You need to look inward to figure out how to correct that imbalance. No amount of advice will be able to answer that for you.
testeraway@reddit (OP)
Yes definitely true. For a long time I tried to get things to change by proposing new ideas, add new processes, etc. Gave up after I saw things aren’t getting fixed after a number of years of the same issues. Correcting the imbalance requires finding a new job, which is tough right now.
tossed_@reddit
Raise it in the open. Do you have a regular meeting with your team where you discuss ongoing work? Mention “I have been reviewing the changes so far…” and start listing some of the issues you want to see resolved before you continue reviewing. Put emphasis on the qualitative issues you’ve found – obviously the thing has to work, if it doesn’t then it’s not even ready for review yet. The other qualitative issues seem quite egregious to me, you have a new application and people are introducing outdated dependencies? Why? This change is gigantic on its own merits, yet unrelated work was stuffed into the same change? Why? Keep questioning the approach and decisions and you will discover if they are justified or not. This goes doubly if the author did nothing to try to make things easier for the reviewer – no self-review, poor PR notes, badly specified requirements and acceptance criteria, etc. If contributors want less friction when trying to ship, they need to lubricate the process themselves.
Obviously it’s not going to endear you to the author to openly point out everything wrong with their changes, but if you don’t raise it openly then you risk accepting sole responsibility for blocking progress here. That’s not the case – the other developer is blocking progress by shipping what looks like low quality work. A senior is distinguished from juniors by the standard of care and responsibility they take in their work. Raising qualitative issues in large incoming changes and demanding greater care and attention is exactly what a senior developer should do.
Now if you have a good rapport with the author, you could go about this in private. But it is easy to be simply ignored if nobody else knows about your objections. If you trust the developer will take your concerns seriously, you can bring it to them directly, but otherwise there is nothing wrong taking a good opportunity to remind the team of their duty to minimize the size of changes and to put greater attention to the quality of their work – it might help with the cultural issues that led you to this moment in the first place. Leadership by example is key here – show care for the work when others do not.