How do you handle more senior teammates who raise flags, but never propose solutions?
Posted by lIIllIIlllIIllIIl@reddit | ExperiencedDevs | View on Reddit | 119 comments
I've been a mid-level developer for the same company for about 4 years now.
A pattern I've seen a lot at my current workplace are developers (often senior level or staff) who voice concerns, which are often framed as low-stakes subjective preferences (i.e. "I'd prefer if we didn't do _X_"), but they never elaborate and never propose solutions on their own.
What is even more frustrating is that these overly cautious developers are often voicing their concerns about how others use the systems they (the cautious developers) have developed.
For example, I'm currently working with the developer who developed our company's design system. We have custom components that don't fit the design system, so we had to re-implement some components in the app's code that copy the visual style of the design system. The developer didn't like my approach. He didn't say why he didn't like it. He didn't suggest an alternative. He told me I was using the design system wrong, and it was my job to figure out an alternative. This is a known limitation of our design system. When I press him about it, he usually tells me to ask another more senior developer than him.
I feel frustrated because these developers seem to reap the social credits of appearing wise and cautious, but they never bear the downsides of being wrong because they never suggest anything. Upper management strangely loves them.
I suspect there's also a hierarchical element at play; they rarely question people above them, but they constantly use their rank to block people below them. This leads to awkward situations where they block me because someone else higher-positioned said something, but they are unable to explain the reasoning behind it, and proceed to ask me to ask them.
I don't know how common this is. It's currently my biggest motivation killer at work. I am actually in the process of changing jobs hoping to find a better team dynamic, but I'm afraid I'll face the same issue elsewhere.
So, did you ever experience this, and what did you do to improve the situation?
Squirrel_Uprising_26@reddit
For that design question system, I’d ask for examples or documentation that shows how to use it. It’s possible they don’t want to come off as assuming you don’t know how to use the design system, and after all, it is your job to do the work, and most of the work is/should be thinking, not typing. Then it also could be just one dev being difficult, or leadership with questionable judgement in who they promote/hire.
As a “senior” for some time, I’ve personally experienced working with some devs who consistently push out PRs with lots of design gaps that will cause real maintenance/on-call or functionality issues (not “could”, “will” - junior engineers often take having knowledge of how things work as extreme risk aversion). Once you’re a “mid level” dev, you should have the ability to either find a solution when such a thing is pointed out, defend the design choice in an objective way, or ask for help re-designing if unsure how to deal with it. If I spent the time to figure out solutions for every unnecessary problem on a PR like that, I’d be writing a whole new PR from scratch, typically with less code and entirely different patterns. If a dev makes almost every on of their PRs like this, especially without talking about design up front rather than every PR being a “creative masterpiece”, then it can become the senior’s job to both come up with a completely different design (re-do the work) AND convince the other dev why it’s better after they’ve spent so much time refining their very unique solution. That’s more work for the sr than if they’d just done the work from the start and isn’t good for either person. So this is something to check for; are you setting this kind of pattern/quality expectation of your work? If so, you could talk to your manager or seniors about how to improve. If not, it could just be bad coworkers.
Idiopathic_Sapien@reddit
I take their advice into consideration with the context that they are not solutions people.
Fidodo@reddit
What happens when you ask them what they suggest?
spambait-aspaaaragus@reddit
I believe OP
OllieOnHisBike@reddit
Simple, ask Why....
lIIllIIlllIIllIIl@reddit (OP)
I wish it was this simple, but a single why is rarely enough. I have to press them relentlessly to squeeze information out of them, and I usually have to write a few long paragraphs laying everything out for them to acknowledge my own concerns and trade-offs.
It's exhausting. I feel like I'm doing the entire mental work for them.
OllieOnHisBike@reddit
No one is going to read long paragraphed emails, in fact it alienates people, it's counterintuitive...
Brief (max 30 min) meeting face to face, and most importantly meeting minutes afterwards on what was agreed / explained.
juusorneim@reddit
And what if they refuse a meeting due to being "too busy" and instruct me to ask in written form? Then when asking in written form, the same scenario plays out as OP has described.
OllieOnHisBike@reddit
Go up a level, explain in an email to their manager you are not getting the information required, and importantly invite the manager to the next meeting.
If the manager is not interested either, start looking for new opportunities...
wipqozn@reddit
Escalating to the seniors manager is a good idea, but this isn't something I'd suggest OP do themselves. OP should escalate the issue to their manager, and then let their manager escalate it to the seniors manager.
OllieOnHisBike@reddit
I didn't suggest that...
wipqozn@reddit
You literally did though? Or am I misunderstanding what you meant by "an email to their manager"?
OllieOnHisBike@reddit
No one is to busy, even business critical developers can spare an hour a day at least.
Being a good developer has nothing to do with writing code, it's everything else which makes you a success, in this case communication.
wipqozn@reddit
There are plenty of companies which put unreasonable workloads on their employees, so I disagree that "no one is too busy" to spare an hour a day. Even in companies where that isn't true though, you need to remember there's likely more than just OP asking for the time of these senior developers. There could be 4 other people asking for a meeting with that developer the same day OP is, and if the senior says yes to all of them, they could spend over half their day on these impromptu meetings.
gibdimkoofchji@reddit
I’ve had good luck dumping coffee on their laptop and meeting them in the tech support area when they go pick up another
anubus72@reddit
really, nobody reads documents? What world do you live in?
t-tekin@reddit
(I was in debate clubs, something I learned)
Instead of defending your approach against their argument, turn the table towards their argument. You need to ask questions, not explain things.
“I’d prefer if we didn’t do X”
Response: “what problem are you trying to solve? And what would you rather do?”
You don’t need paragraphs, or explanation.
let them do the work. And if they can’t answer this question properly it was just a nit pick, move on.
MoreRespectForQA@reddit
It is, yeah, but that's what it's like being a developer. 80% of the job usually involves vaulting a series of hurdles which shouldnt be there.
The people who are relentless tend to succeed while the ones that go "i shouldnt have to do this shit" dont.
valence_engineer@reddit
It's more than that. And it's the single most important lesson I learned in my career. I am a cog. I am not the only cog not the most important cog by far. There are more important cogs. If I need to spend an hour to save a more important cog 10 minutes then from both a career and overall company efficiency perspective that is a win.
goatanuss@reddit
During your next review cycle or one on one with managers complain about lack of mentorship
ConquerQuestOnline@reddit
face to face communications (Probably over teams/slack call) is the right answer here.
Regal_Kiwi@reddit
This will only triggers a conversation that goes into circles about semantics, childhood trauma and epistemology.
ConquerQuestOnline@reddit
If it was one guy doing this, I'd say he sounds like a real jerk. If it's a team of senior devs, I'm inclined to believe there's something to it, and there's a communication gap.
Ask one to take some time with you and explain the reasoning behind their caution. This is kind of what I'd expect staff level engineers to be doing.
lIIllIIlllIIllIIl@reddit (OP)
I'd say there's about 3~4 developers like this, but they hold some of the highest ranks in the company.
Some of the recent staff developers we've hired are fine and perfectly what I'd expect from the role, they communicate clearly, they're not afraid of suggesting large changes they believe in, they do the work to get complex projects moving, etc.
It's really just the culture of staff developers in a specific section of the company that behaves like this.
valence_engineer@reddit
In other words the people with the least time and the most things to juggle. They have a hundred things occupying their time. You have a handful. So yes, it is your job to spend more time even if it'd be more efficient for them to spend more time. Because if they're spending that time on you then they're not spending it on other important things. If you need more help then get other more senior engineers but not top of the company senior to help you.
Pokeputin@reddit
Then how do they have time to review it often enough for OP's problem to be a pattern?
It takes literally few more seconds to explain at least why the problem they point out is a problem, so "no time" is not an excuse. And if this is a problem that keeps happening then they should formalize their standards by a guidelines doc, ADRs, trainings, code comments etc.
valence_engineer@reddit
If it'd only take a few second then OP could figure it out in a few minutes. It takes significantly longer to explain something to someone more junior in a way that the junior person understands rather than a way they just blindly follow. And OP doesn't seem like a blindly follow type of person which makes it take even longer. OP thinks it's a few seconds but even their own descriptions of when they got this information involve a lot of back and forth.
thedeuceisloose@reddit
All those “a few more seconds” add up over time especially if the organization is large. Additionally adds extra context overhead and switching.
ComplexBluebird2455@reddit
I would ask for some alternatives directly. It’s not always the job of the reviewer to provide a solution. But at a certain level of seniority, and if they built the system, I’d expect they could be a little more helpful. This also prevents miscommunication and many rounds of review
juusorneim@reddit
Why? Who's job is it?
Not providing any ideas or hints toward a better solution is confusing, inefficient with respect to time, and counter-productive. Do you not agree?
ComplexBluebird2455@reddit
Um, it’s still your job. I can recognize a bad pattern without understanding every detail of the system you’re working on to know a better solution.
But it sounds like you just want to argue since I wrote in my next sentence that the reviewer should try to provide a solution, especially if they know about the code already.
unflores@reddit
Yeah, it wouldn't be weird to see someone misusing rest to get a return with, this API call is misusing rest.
It is the job of the dev to come up with a solution. The reviewer is there to review the solution. If they can't tell you what you are doing wrong then they aren't reviewing properly. If you are misusing the design system, they should be able to give you in-depth reasoning for why and what the vision of the system is.
oupablo@reddit
Have they also been there forever? This can sometimes be explained by a "this is how it has always been" mentality which is REALLY problematic. A Staff should have no issue explaining why something is the way it is when blocking alternate approaches and if it's a common question, it should definitely be documented somewhere why it is the way it is.
jenkinsleroi@reddit
I've also seen overconfident junior devs who refuse to listen to feedback because they think they know how to do things the right way, or devs who need solutions handed to them on a silver platter.
I don't know if that's OP, or the culture might be one where junior devs have to sink or swim.
oupablo@reddit
For sure but it's up to the more senior person to explain WHY not to do it a certain way. You can't just say "no" with zero reasoning without expecting it breed resentment. Furthermore, that doesn't help either person. The junior won't grow in understanding and the senior will have to keep responding no to everything.
jenkinsleroi@reddit
At a certain point, it might be about baseline competence and standards though.
If I tell a mid or senior that we can't put service calls in the model, or that we can't use global variables, they should know what that means and know how to fix it without me solving it for them.
If someone wants to fight about things like that frequently, that's a problem.
VRT303@reddit
In this case not duplicating existing design seems pretty straightforward. A hell to maintain, easy to introduce big drifts.
I sometimes leave as such comments too ans expect the junior to think it over, come up with 1-2 ideas and talk me through them. If I just spoon-feed it then I could just do it myself.
Other times I know we have a deadline and leave a resigned comment to 'find a better way if you have enough time' because I'm deep in the next big 3 things coming up and I can live with it as is, even if it could grow in a piece of shit after a few interactions.
TechnicalBee3875@reddit
sounds like a classic case of gatekeeping
ConquerQuestOnline@reddit
Interesting, I never took it that way.
In my early career hubris, I often would push back, or raise it back up to them; looking back on many of the instances that stood out, I was wrong pretty much 100% of the time.
Code begins to rot as soon as it's written. It takes a huge effort to keep it maintained, especially when you have a team of any size starting to work on it. Drift happens, and without review it gets very messy very quickly.
Candid_Bad3551@reddit
4YOE. My team has a motto: "If you know how to do it, offer the solution otherwise this is the best we got"
I personally point out issues but say I have no solution or create a ticket to investigate in these cases. I do this a lot to Interns/Juniors to think about tradeoffs and be aware of them.
Id say in those places: If you do not have a better solution that is what we will have to use.
cobalt-jam88@reddit
In my experience this usually means one of two things: they genuinely don't know what the fix is but have enough pattern recognition to smell the problem, or they've learned that proposing solutions means owning them. Worth asking directly in the next review: 'if you were starting from scratch here, what direction would you go?' Because it forces the conversation out of critique mode and tells you pretty fast which situation you're in. If they still can't answer, that's useful information too.
KickAssWilson@reddit
First, if you're leaving anyway, then I wouldn't worry about this too much. But while you're there:
If they say "I'd prefer if we didn't do X", don't ask "Why?" - just ask what they would do instead.
> This leads to awkward situations where they block me because someone else higher-positioned said something, but they are unable to explain the reasoning behind it, and proceed to ask me to ask them.
Then be truthful - say, "I asked X about this, and they told me to come talk to you about it". It's the truth, and gets the point across that someone passed the buck.
Finally, when you're leaving, don't make a big deal about what's wrong with the place or who is doing what. It can do you no good, and it won't change anything anyway. I've never seen someone leave a place and have that place change based on comments. It'll only be used against you - either by people that find out what you say (and you might run into them later), but be remembered by an HR person who moves to another company (and you might run into them later too). Remember HR is there to protect the company, not the people working there.
Specific_Ocelot_4132@reddit
I don’t know, but you might enjoy this article in praise of the “No, but…” engineer: https://www.scottsmitelli.com/articles/no-but-engineer/
Unfortunately, some people only get the “no” part.
abandonplanetearth@reddit
I do this when I get tired of a developer underperforming.
You just "re-implemented" (copy pasted?) an entire component out of the design system, and now it will diverge and become a maintenance burden. I don't know all of the nuance of the situation that you are in, but I know that's not how a DS is supposed to be used.
I would guess that you are expected to know this, and to actually put in the effort to solving the issue.
When one of my developers does this low effort stuff that causes all sorts of long term issues, I call them "bombs". If I let you merge it, it's just a matter of time until it blows up in my face. I am not your personal bomb defuser. It is not my job to be the last like of defence bomb defuser. It is actually your job to create things that don't blow up.
There is some of my own frustration coming up in this response, but that's my 2 cents.
I always work with devs the first time this happens so that my expectation is clear. In this case I would say something like "Do not copy paste a component out of the DS, extend it this other way instead...". And I suspect your senior did, or it's documented somewhere, because it's a reasonable explanation for their behaviour.
Miserable_Heron_9007@reddit
I am one of those. I am paid for it. People call me to meetings to do exactly that: to say what I think about their solutions. Luckily, it's all good, or almost. But, sometimes, some senior in pre-sales come with simplified solutions and I say: who's going to be fired when that becomes undeliverable, or don't solve the problem, or breaks, etc? Then they say I don't want to sell, or solve problems, etc.
Anyway, I don't have time to build solutions, and what I can propose is high level. It's their responsibility to solve. Happily (because I'm old and tired) AI is taking my place.
sol_in_vic_tus@reddit
What job title is this and how did you get there? I am also one of these but people just get mad at me instead of paying me.
Miserable_Heron_9007@reddit
Consultant on a more than 10 years contract (though billed by the hour). They sell me internally and externally as anything (solutions architect, whatever engineer, tech lead, staff). I deliver on very few specific situations, and am invited to give opinions on things. They still think I'm valuable (or enjoyable to work with, or maybe it's the institutional knowledge).
chikamakaleyley@reddit
why does this get approved for development if it doesn't fit the design system? The design system is something that both create + engineering agree to, right?
chikamakaleyley@reddit
it's easy to misconstrue and push-back from those senior level and up, but in a lot of cases you might realize that they are right - they're trying to prevent new dependencies, they're making sure that you've thought about this deeply by grilling you, they've seen things fail, etc.
I used to be that younger dev, thinking everyone is just set in their own ways, why is it a struggle to even keep the code up to date, I wish I worked somewhere where they did things the modern way, etc.
brainhack3r@reddit
Stop energy...
They're all "no, because... " not "yes, and ..."
In improv you're taught never to say "no" because it stops creativity.
These people end up being brick walls.
Dry_Author8849@reddit
Have you considered you may be wrong?
Do you have in place guidelines for code style, etc.? Is the design system documentation in place? Are you sure you have followed it?
When there is documentation in place, you are expected to read it and follow it. If there is a guide on how components should be designed, programmed and implemented, then there is not too much to explain. Read it. If you have questions, ask.
And if you are below level, try to fit in and make yourself useful. Suggest to update documentation, ask for guidance before developing things in a not expected way.
There are two sides of the coin. Check your side too. It sounds you developed something on your own way and expect everyone to agree with you. Try to figure out what you have made wrong. Sometimes silence from the other party is a sign of being polite instead of pointing to your mistakes. A confronting attitude won't help.
You will find similar situations in other companies too.
Cheers!
Ok-Yogurt2360@reddit
Isn't x supposed to be/work/look like y? Or am i missing something?
The above sentence can do a lot. You lay bare your assumptions and they can correct you if needed. The average developer would go "no, no, no that would...." in their heads and see your beliefs and views as a potential danger. One that needs to be corrected
paagul@reddit
The senior design system dude on your team is absolutely right. You should never ever copy a ds component and modify 3% of it in-app, it’s the worst design system philosophy violation there is.
Contrary to popular belief, design systems don’t exist to speed up developer velocity by “build once use everywhere“ or some other corpo slogan. They exist to give a consistent and coherent ui/ux to the user, the code reusability is a happy side effect.
If you’ve built and maintained a ds that powers multiple apps worked on by many developers you have to be conservative or otherwise your ds looks like a disparate set of components reflecting the whims of the devs and designers at the time. The first reply to any ds modification (if it’s mateur and has a critical mass) should be no. If a need is real you’ll hear about it again from other designers guaranteed. Note that designers shouldn’t e giving you randomly modified components as well. If you’re using Figma these are called “detached components“ and you should ban their usage in Figma.
Imagine if every designer and dev starts doing what you’re doing, which is to treat the ds as a reference and starts putting their own spin on everything. Pretty soon your app will look incoherent and amateurish. You might think this is hyperbole but this is exactly how in-house design systems go to shit. Then you also have to think about these edge cases if you ever have to do a brand refresh or some other major ui overhaul because I guarantee you the copy pasted implementation will be very specific and will have random assumptions baked into it.
I could go on for hours about why adhoc da mods are a bad idea.
I don’t know why you ds lead didn’t explain this to you but he’s not in the wrong. May be you should demand an explanation in these situations, as curiosity. I find devs love sharing knowledge but they won’t offer it up voluntarily, it has to be asked for.
hw999@reddit
You fire them. They are lazy, and put up roadblocks to avoid work. This attitude quickly spreads to other developers and teams and will be a huge drain on velocity.
aaron1uk@reddit
Thanks for asking this, a problem I have
wutcnbrowndo4u@reddit
I don't think raising a concern without an alternative is bad at all: it's helpful to be able to provide a high-level perspective/nudge without having to dive deep and own the mental load of a solution. This does require the understanding on both sides that the owners may go another direction with it.
What is bad is vague suggestions like "I'd prefer if we didn't"
danieldoesnt@reddit
There's a case study about flow from a hospital ER in The DevOps Handbook that I think about often.
campbellm@reddit
"complaining without a solution is just whining/whinging"
yad76@reddit
I've learned how to push back on this sort of thing when it happens. Call them out, ask for clarification, throw time on their calendar, etc.. Use phrases like "let's pair up" and "let's discuss to reach consensus", particularly when your manager is around. Emphasize the amount of thought and work you've already put in. Phrase things so that you are seeking their help and trying to learn from them more than you are questioning them.
These are mostly people who got to where they are by throwing around big hand wavey statements with no merit and they will run and hide fast as soon as any light gets shined on them.
DoingItForEli@reddit
If they're the highest level developers at the company then they're likely some of the most overworked as well, and if a mid level developer happens to be deviating outside the norm because they didn't read the documentation or their solution demonstrates a lack of awareness of the overall architecture, imagine how frustrating it is for them to take time out of what they're doing to hold your hand through the proper solution.
I'm not saying that to knock you. I think this is a really valuable learning experience overall. And yes, for all we know the situation could be exactly as you described it or worse. People tend to write these sorts of post though in a way to get the reader to be as sympathetic as possible to their point of view.
So my advice is simple: Bring reciepts. Demonstrate you've read documentation, considered the architectural goals of the current design, explain why you need to deviate or enhance something. In that pursuit of "bringing reciepts" to make the most compelling argument possible, you MAY inadvertantly find the better solution THEY are alluding to.
serious-catzor@reddit
Someone needs to make a call to act or not act on things. Beyond that people can talk all they want.
Same with the "you are doing it wrong". Request a decision from someone whether to change it or not.
Make sure the person talking or demanding you changw it is present. Then you can request the clarification in case the decision is that you should do it. If he says its your job there and then without a reaction from the "shot caller" then either you are in the wrong or in the wrong place.
I prefer to lift things and expose them. And not because I like face to face or some other bullshit... because I hate doing it, it feels so bad and I start shaking even...but because going around wondering and playing cloak and daggers is so much worse.
Iz4e@reddit
So what happens if you just implement anyways? Like sometimes its better to ask for forgiveness than permission. You can simply ask, "Is this concern blocking, if not I am moving on." Or address as "I dont believe its X because of Y and Z.
kbielefe@reddit
I see this sometimes when developers start getting more complex assignments that stretch them a bit. Your questions stop being small enough to answer in my "interruption time" and I have to set aside a few hours to figure it out myself. That means it has to get prioritized together with everything else on my plate.
guiltys33ker@reddit
I've been in a team like this, it's likely because the seniors have figured out that they're being evaluated on technical maturity/their advisory skills and not their actual execution. As a Staff now who leans in the opposite direction, it looks GREAT if I can find a corner case/potential flaw in a juniors proposal and set them on the right path. To solve your problem, maybe directly ask the seniors in a non confrontational way what exactly their suggestion is? You might want to avoid calling them out in front of the team etc since that might result in an ego clash. At the end of the day I don't think they actually want to leave you hanging. They are doing their jobs, and are busy.
NoobPwnr@reddit
"Open to alternative solutions. Hoping to get this out by tomorrow. Happy to pair, thanks in advance."
WelshBluebird1@reddit
Why is it on the senior to provide the solution? Sometimes something is just wrong or will cause issues down the road. And a senior team members job is often to catch those early enough.
drnullpointer@reddit
I have a theory about this.
The theory is that some people are smart enough to notice problems but not smart enough to realize other people also notice the problems.
Some people think that if they complain about the issues, they are showing their experience and intelligence and are doing God's work to help the team.
The issue is that complaining without follow through is almost useless. I try to make sure if I complain about things, I am ready to do something about it. I also try to first figure out why exactly we are in this situation, because frequently there is a reason that I may not be aware of.
> I feel frustrated because these developers seem to reap the social credits of appearing wise and cautious, but they never bear the downsides of being wrong because they never suggest anything. Upper management strangely loves them.
Who said upper management is only composed of intelligent, experienced people?
ImportantSignal2098@reddit
An interesting aspect of the budget you're suggesting is that it can be easily gamed. I could simply add a bunch of bigger red flags to changes that already have red flags so that you exhaust your budget and are forced to accept some of them. And I'm not talking purely theoretically here, some people just manage to get lots of things wrong and if you approach this with a fixed budget of sorts you're not getting good outcomes. You can't always claim they're doing it unintentionally either - for example, does lack of motivation to understand the problem deeply before jumping to solutions count as intentional or not?
drnullpointer@reddit
When I mean "complaint budget" what I mean is "how much I can complain while still being able to make each of the complaints do something useful".
Complaining is important, but only as far as it is done to achieve a positive change.
ImportantSignal2098@reddit
I think you completely miss the meaning what I said. Where did I mention money?
This the the part that can be gamed as I described.
drnullpointer@reddit
You can't game a budget you set yourself for your own use.
ImportantSignal2098@reddit
Right. You missed it again. In that scenario the person gaming your budget is me, or another dev. Sorry, not sure why this is hard to grasp.
corny_horse@reddit
What they're suggesting is you have to be pragmatic and pick your battles. You can win some of them, but almost certainly not all of them - so you have to rank order the ones you pick so that you have a higher chance of success. The "budget" they're mentioning is really a rank ordering of relative success ratios and picking the ones you want to actually win and ignoring the ones you don't want to go to bat for.
A more compelx version of this "game" is when you internally coordinate with other engineers who feel like there are similarly studpid decisions going on and n number of you go to bat individually on the highest n problems individually and others support that engineer in their endeavor but aren't the most vocal about it.
ImportantSignal2098@reddit
I understand what they're suggesting, not sure what prompted you to reiterate on that. I'm saying "picking battles" can be gamed from the other side by creating battles artificially, and you should recognize that people game everything both consciously and subconsciously.
corny_horse@reddit
Whether people are acting or not acting in good faith doesn't change that prioritizing what you perceive as high-value complaints over low-value complaints is a reasonable and solid strategy.
ImportantSignal2098@reddit
Thinking of it as a specific "budget" is just one possible implementation of the idea that you just expressed - are you suggesting this is the only possible implementation? What else have you considered?
hfourm@reddit
On the flip side of the coin... why are you using a component outside its intended system/usage?
Does the design REALLY need it, or can it be iterated on to use the existing patterns/components?
Sounds like a reasonable position for the senior to take.
I agree the senior should offer more clarity on alternatives they see, however.
honestduane@reddit
Ask "Why?" And force them to explain it.
UK-sHaDoW@reddit
At my place we taught to raise concerns, and ask questions but specifically not come solutions for developers. This is so you can grow.
LBGW_experiment@reddit
I like to think of the scope of implementation guidance (not hard prescriptive "do x") needs to adjust based on the seniority of the recipient. Juniors need a bit more narrow guidance, but certain implementation details are left open for solution.
By leaving things wide open, it tends to cause juniors to spin their wheels more on lots of uncertainty, so even letting them know what is open for them to develop vs what they should follow, in my opinion, gives them better working directions without leaving them feeling afloat without a sail.
hiddenhare@reddit
Yeah, while reading the post I was like "this genuinely isn't your coworker's job!" It's normal for a workplace to end up relying on unwritten rules and conventions, and simply informing your coworkers of those rules is a useful contribution. It's useful for the whole team to express their subjective preferences early and often, but if everybody who states a preference is expected to write up a plan and enforce it on their coworkers, senior staff will learn to keep their mouths shut instead.
Being too eager to give advice stifles growth, it risks duplicating work or providing chaotic, conflicting instructions, and it risks replacing a junior employee's high-context decisions with a senior's half-baked decisions. When it's the right time for you to get advice from a more senior coworker, it's your job to reach out and ask them for it.
Usual_Ad_2177@reddit
Sometimes company culture is such that people of a certain level need to shit on the people below them.
The best way to get past this, in my opinion, is to get buy in from at least one of the 'nay-sayers' by asking them about your implementation plan before you start implementing anything. If there are multiple people doing this, then rotate who you are getting pseudo-approval from based on their expertise.
This way, when you complete the work and hit that moment when everyone would usually start circle-jerking about perceived deficiencies, you will have at least one shield-bearer to fend them off...because they have already put their approval into it.
These environments can suck to work in, but they are probably some of the best environments to grow your skills in. Make it a game where you try and predict their objections and find a solution that they can't complain about.
YesNoMaybe@reddit
Any decent org should have this as a requirement of the development process. "This is how I plan to implement this. Here are alternatives considered with reasons I didn't pick those."
stoopwafflestomper@reddit
This is solid advice. Basically ego stroke the devs. I had to do it at most companies I worked at. Not all devs are jerks, just majority of the ones I worked with.
delphinius81@reddit
Honestly this is a good idea even if you work with super supportive senior team members as well. Propose your plan to another dev, talk through the design questions - even if you know the answers. Get validation from the start. Then when it comes time for the PR you have someone that already understands why things were implemented the way they were.
It let's the pr be about implementation details instead of a system design review, which is too expensive to do at the pr stage.
Advanced_Seesaw_3007@reddit
I had an experience with this type of person. I always come back with:
* show me how to reproduce the red flag (the what)
* why you think it is a red flag
* how do you intend to fix it (or what's your alternative)
The reason for this approach is to figure out understanding of project requirements. One should be able to articulate the flags and all the related discussions around them. Another also is to highlight if the concern is within the scope/timeframe of the project. The last person that displayed this behavior was older than me and somehow even if I am the lead, he seems to assert authority on other junior developers and at times based on misplaced understanding of facts. Worst case that happened was the junior implemented a "fix" for a scenario based on false assumptions that ran for almost a month of fix. When the junior was rolled off the project, when I checked the workflow, it wasn't as discussed in the project plan/requirements and this other person just refused to admit he's wrong.
Aleks_Zemz_1111@reddit
You're dealing with defensive architecture. I’ve seen this on factory floors for decades. A senior operator who treats the machine like a shrine rather than a tool, almost like it's something mystical or alive. They raise flags without solutions because their goal isn't to solve the problem, it's to maintain their status as the high priest of the system. By being vague, they stay right without ever having to risk being wrong.
When a developer tells you something like, that's not how the system was intended, but can't provide a refactor path, they aren't being an engineer, they're being a gatekeeper. They are optimizing for their own job security (Vested Interest) at the expense of system throughput.
The reason management loves them is that they mistake caution for seniority.
If you're already leaving, use your remaining time to call it out as a technical problem. Stop asking them for permission and start asking for the standard operating procedure (SOP). If they can't provide an SOP for the edge case you've found, then the design system has failed.
And don't be naive, don't expect to find a better team dynamic elsewhere by luck. You'll find these people everywhere. The only fix is to move into a position where you own the architecture yourself. If you aren't the one defining the tokens, you're always going to be the one asking the Priest for a blessing.
Ahhmyface@reddit
I don't know, maybe its my own experience biasing me, but my gut instinct is that you're probably doing it wrong.
If you come up with some solution, and a more experienced developer took the time to look at it, noticed that it doesn't cover several important use cases, comes with numerous drawbacks, will be awkward to maintain, etc. Often this happens when the dev in question has a fundamental misunderstanding of the task, the domain, or the conventions of the design. As a mentor, my role is to correct this misunderstanding. You should be capable of understanding my feedback and looking at alternative approaches.
The feedback is clear. The senior person in this case does not want to take on the burden of re-implementing your application in a way that doesn't suck. I've wholesale rejected pull requests before because they are simply fundamentally incompatible with the direction the code needs to go, and going to make everyone's life worse.
Granted, if you are struggling to come up with a design that fits these requirements, then you absolutely are entitled to get on a call with me and we can work through a high level example how things are supposed to be done.
In other cases, it is political. When somebody asks me why we can't use Deepseek for our applications, I just tell them "its not approved" because I am not willing to go fight the security org for a month because you felt like experimenting.
throwaway_0x90@reddit
Hmm, actually I think this is normal for seniors to raise issues without giving you a solution on a silver platter.
Physical-Compote4594@reddit
I’m a lifelong engineer and I’m now a CTO who specializes in growing companies from small to not-small. A big part of my job is creating a healthy company culture. If what you are saying is accurate, it is not healthy.
If I see a pattern that looks like this, I take the senior developer aside and tell him or her that he or she is not allowed to publicly raise objections unless it is accompanied by an explanation and/or a potential solution. If I saw a whole group behaving like this, I would consider splitting up the group.
There are often good reasons for being cautious, but simply raising objections without providing a path forward is just obstructive.
UK-sHaDoW@reddit
If your senior developers are providing solutions constantly. You're juniors are not growing.
lIIllIIlllIIllIIl@reddit (OP)
I'm not junior tho. If I were, and if my issues where small things like "How do I do this very common thing?", I'd agree with you.
The problems I'm facing at work are usually related to how we designed our different systems, and how bad trade-offs in one subsystem incur debt in other subsystems. These are pernicious problems I expect senior/staff level developers to handle, since they can often cross multiple team boundaries. Being told in my PR that my code is is suboptimal and that I should look for alternatives does not feel very productive, especially when the root cause of the problem comes from another subsystem which I don't have real authority to change. I could come up with a grand plan on how to improve the different systems to fix the root problems, but without support from them, it's kind of pointless.
valence_engineer@reddit
Did you document all this in the PR or a document attached to the PR? Not the changes needed in other systems but the constraints under which your PR was made and the reasoning for those constraints? If it's a non-trivial PR did you write a quick design/proposal doc with those constraints to get feedback early?
Physical-Compote4594@reddit
Sure but that’s not what OP is describing.
Ok-Entertainer-1414@reddit
Thumbs up emoji react and then proceed as though nothing has been said. If it was actually important, they wouldn't be mysterious about it
donjulioanejo@reddit
Counterpoint to play the devil's advocate to what everyone else is saying:
Part of being higher level (i.e. Staff+) is judging and managing possible long-term risk and tech debt. If they see a problem with something, it's worth mentioning.
You can often see potential problems sitting in a design review meeting or presentation.
Worth flagging them now and evaluating tradeoffs.
Coming up with a solution takes more time. Someone who is probably seeing the proposed architecture for the first time isn't going to have answers in the first 5 minutes.
Storm_Surge@reddit
This is the classic accountability exploit in office politics. It goes something like this:
The primary counter to this is unfortunately a bit rude, but it's what Steve Jobs famously said: "NO BOZOS." If you hire a bozo, get him out immediately before this happens. Every project needs a person who is held accountable for its success too. That way if a bozo starts sandbagging it, someone steps in and ends it before it's too late. This is also less likely to happen when employees are shareholders because clown shit costs them money.
Oo__II__oO@reddit
The media is the message. By speaking, they are voicing concerns, but not committing to it. The answer is "get it in writing". Ask them to sum it up in an email so you can acknowledge their concerns, and circle back to understanding what they propose. You can even (politely) request where to find requirements or design documents that can guide you.
If the email goes unresponded, have a weekly reminder to send a follow up email, up to two times. If nothing happens after that, bring it up to your manager (that is their job, to manage people and situations), and say you will be moving forward due to lack of constructive feedback.
At some point I can guarantee the staff engineer will want to hold a meeting to respond to the email, thus shifting the record from written to verbal. It is important to keep notes in the meeting on any conversations, key points, and action items. Post-meeting, put all those in an email and respond to everyone in the meeting with "here are the takeaways from the meeting", with an offer to feel free to correct any issues or misunderstandings in the notes.
Djelimon@reddit
Propose a solution, make sure boss knows it's my idea. Even if it isn't accepted it shows willing. If it is accepted then cv gets a boost and maybe career
corny_horse@reddit
I worked at a place like this and it was almost always that upper management had very, very strong opinions about something but never wrote it down or, worse, didn't remember that and later took a totall opposite position. Sometimes to two different people or groups. The net effect is that people didn't want to defend the position (because it was frequently nonsensical and also possibly even contradictory), but they also didn't want to be seen as approving the dissent because then they'd have upper management breathing down their necks trying to forge some kind of "consensus," which usually meant strongarming engineers into agreeing with the direction verbally (NEVER in writing!).
caprisunkraftfoods@reddit
I think it's worth diving way deeper into as a learning opportunity. It's not necessarily that they're right, but they're obviously seeing something you're not. It's probably patterns from previous jobs/work where they've seen things go wrong, but heinsight hasn't left them with a silver bullet.
Try to dig into that while letting go of the current debate. You're not trying to fix a current problem, you're just looking for story time about what they've seen in the past that it reminds them of. Most people love to yap about their war stories if given the opportunity. Just take it in, digest it, and even if you still disagree you'll at least understand where they're coming from.
Feroc@reddit
I mean if it's a pattern and often about the same stuff, then... well... communicating I guess. We would raise something like that in our retrospective and then would try to get the pros and cons of doing X and then decide as a team what we want to do.
Regal_Kiwi@reddit
Good question, I call them the scarecrows, they work in FCDD, fear & confusion driven development. They never change, it is not technical, they won't change, it is a personality trait.
Exiled_Exile_@reddit
Learn to frame a conversation. Asking someone to "review" vs asking someone to help you build the document will get different results. More flies with honey than vinegar basically.
If they are obstinate then no amount of reframing fixes overly opinionated. At that point I'd seek out one of their peers that I work with and try to have a broader discussion. I would recommend having at least 2 in a review anyways should save some time for you.
kevinambrosia@reddit
You can always ask more questions. Many times, this either clarifies or disillusions the comments because they have to think about what they mean and either tell you or realize it’s bullshit.
If you’ve asked for clarification and they still say it’s your job to figure out, then stick to your guns. It was your job, you figured it out and they don’t have a better solution.
I know sticking to your guns can feel like conflict, but not all conflict is bad. By doing this, you’re forcing them to accept your solution or explicitly clarify how they’d do it differently. Just do it with the spirit of collaboration in your heart and words
Napolean_BonerFarte@reddit
This is good advice. If OP does this, hopefully they can get some concrete information about a path forward with the implementation. If not I think they just need to point their manager at the conversation. Ultimately a staff engineer is blocking delivery of the work and isn’t offering a way forward even with OP trying to engage and find a solution, then OPs manager needs to unblock it by forcing the conversation or deciding the work can proceed.
official_business@reddit
If people won't explain their concerns to me then I tend to ignore them and just move on.
Maybe it will be a problem that I'll trip up on later, in which case I'll deal with it when the time comes. Maybe it'll never become a problem.
You need to show your manager some progress, so keep pushing forward and don't worry too much about the concerns until they present a roadblock.
luckyincode@reddit
I raise concerns and get no answers. You tell me!
Current-Gold-7766@reddit
ask them directly for alternatives
New_Addendum_6172@reddit
sounds like a classic case of gatekeeping
CampfireHeadphase@reddit
I agree with many posters here, but want to share another perspective: Depending on their seniority, their job is to guide the attention of individuals to areas of improvement, not figure out solutions. As long as they're open to good arguments and are not pushing back out of principle or status, I think their comments are not necessarily toxic. If you're doing your job well, it should be easy to counter (and steal some social credits yourself). Just start noting down their arguments and, with a bit reflection, the best possible counter you could have made
Overall_Gazelle5107@reddit
That's the only reason! I've been in the same spot you are and learnt, the hard way, better to just try to keep them happy. It's insane how hierarchical structures work but once they are set there's nothing you can do, you'll always come up short and these "seniors" throwing terms around without any reason will just look "good" the the rest of the hierarchy.
anengineerandacat@reddit
IMHO any code change request without a snippet or specific call out to the concern isn't valid.
It's like a child saying they don't want chicken nuggets but they are still hungry; they can definitely communicate the problem better.
Just DM them in whatever messaging app and work through it, I suspect they don't want to officially be on the hook on a PR comment to guide you in a different direction.
Then once you get the feedback just annotate the comment with "Spoke with X, will amend PR with feedback indicating Y concern".
It's not an amazing CYA but does create a checkpoint for someone else.
ThlintoRatscar@reddit
The perjorative term for this is "shit-bird". People that fly by your work, shit all over it, and then fly away.
The usual answer is to simply ignore them and try not to get upset with the splatter.
They can get in the ear of certain management because "grumpy old dev" can be misinterpreted as "sage and wise elder".
The more negative a cynic, the more likely they are to be right as things rarely go to plan. So, when something goes wrong, they then cash in on "right" to prove that their negativity needs to be listened to. If it goes well, then you were just lucky and your success can be ignored.
You're right to call out the behaviour as clamouring for social credit, but also notice that a lot of devs are avoidant people pleasers who like to make others happy. It's all a corporate social dynamic and individual psychology.
Healthy and smart leadership doesn't get sucked in, but not every leader is healthy or smart.
At the end of the day, Anton Ego from Ratatouille has the best attitude about it:
""" In many ways, the work of a critic is easy. We risk very little, yet enjoy a position over those who offer up their work and their selves to our judgment. We thrive on negative criticism, which is fun to write and to read. But the bitter truth we critics must face, is that in the grand scheme of things, the average piece of junk is probably more meaningful than our criticism designating it so. """
eaz135@reddit
I try to come armed with evidence so things aren't just a matter of my opinion vs your opinion.
If you can find other design systems out there (there's lots of great open source ones (e.g. Shopify's Polaris, and many others) - that are doing the approach you are taking, it reinforces your approach and shows that you are aware of what others in the industry are doing. I find having hard tangible examples is the best way get through situations like this.
BTW - design systems are notorious for not being flexible enough to cater for real-world delivery nuances, and design system custodian teams often find themselves struggling to satisfy both needs of flexibility and consistency. There's an awesome conference talk about this by AirBnb "Building (And Re-Building) the Airbnb Design System" - you can find it on Youtube. That was one of my favourite conference presentations from that year!
VindoViper@reddit
Ask them directly, in a setting which is accessible to others e.g. slack thread, pull request, for examples of the solution they're hinting at. Since without such examples it's a game of guesswork as to what their opinion of "good" is, and a lot of time can be wasted in the back and forth. If there's a precedent in the org for doing things this way then you'll have a useful template, if not then they'll probably back down having been exposed for empty posturing.
CombinationNearby308@reddit
That is a valid concern - what do you suggest/propose we should do instead?
If they suggest some over engineered solution - that solves the problem and I'm happy to do it, but it adds x to the timeline due to additional complexity we are choosing to handle.
Other than this - just do it and if they raise comments in code review - that is valid, so, I created a new ticket to handle this as this is out of scope for current ticket.
cheir0n@reddit
Don’t bother and don’t create enemies. Keep your job and don’t poke the wasps nest.
LuckyWriter1292@reddit
If they offer no solutions I note their concerns and move on…