How do you handle workplace disagreements when you think you're right?
Posted by Ok-Introduction-9111@reddit | ExperiencedDevs | View on Reddit | 124 comments
Just got a new job (working for 5 months in that company). I recently had a technical disagreement with a more tenured colleague whom I'm trying to learn from.
The context: We're building a saved filters feature for a table. Each user can have multiple named filter presets (like "My Active Items" or "Q3 Priorities"). The backend dev chose to store all of a user's saved filters as a single JSON blob, one document per user containing the entire array of filters. To add or delete a filter, the frontend loads the full array, mutates it, and sends the whole thing back.
My approach: I argued for per-record CRUD. Each saved filter as its own record with its own ID. Reasoning was that the blob pattern has structural issues for collections of independent items: concurrent edits across tabs cause silent overwrites (deleted filters can resurrect, added filters can disappear), the frontend has to implement CRUD-like state management on top of a non-CRUD API, no per-filter IDs makes future features (sharing, pinning) hard, and migration cost grows with user count. I framed it as a user-experience concern, silent data loss, even rare, erodes trust.
Their approach: Blob storage, "this is the standard pattern," edge cases acceptable for v1, can refactor later if needed.
I made the case multiple times with different framings (including a "hybrid" reframe, CRUD at collection level, structured contents within each record). I engaged with their counter-arguments. My (now departing) lead privately agreed with my view but didn't override the call. The QA initially leaned toward my view (because he taught that was BE dev's opinion), then sided with the BE dev once he said his position. Decision was made for blob. I'm now implementing it.
What I'm curious about:
- When you have a genuine technical disagreement and you think you're right, how do you decide how hard to push?
- When do you stop pushing, and how do you know it's time?
- How do you accept the outcome when you still think the team chose the wrong path?
- How do you maintain your judgment without becoming the person who fights everything?
03263@reddit
Well that's not wrong, can always change it later, so just go with it and let the reasons you think it won't work make themselves evident.
Sheldor5@reddit
change later = migrate all data from the blob storage to the new storage
have fun
TheTacoInquisition@reddit
To be honest, this isn't as annoying as it might feel. Since the data storage would be quite different, just writing to two tables (1 blob and then the "new" approach), wouldn't be a massive job and would migrate most of the data without any scripting. Same with reading, check the new place first and fallback to the blob and update the new table so it's the source of truth for next read.
Any mopups can be made (assuming there are any) after that's been running for a while and they want to remove the blob. Has the benefit of being a very safe migration as well, since it can be rolled back easily if required.
roger_ducky@reddit
It’s relatively safe… until inconsistencies in the data makes it hard to do.
Now, that’d still be a 2-6 week job at worst. But it’s still annoying.
MoreHuman_ThanHuman@reddit
2-6 weeks? why? couple days tops
roger_ducky@reddit
Depends on how tangled it gets. Sometimes you’d have to carefully extricate the actual valid data in multiple stages in order to not break production behavior.
Cell-i-Zenit@reddit
any blob storage is immediatly turning into a huge pile of garbage. Impossible to reason about whats inside or not.
How do you want to write a migration if there is literally zero validation on the content of the json? FE is writing directly into the storage lol
TheTacoInquisition@reddit
It's not like nobody knows the schema. Otherwise the frontend can't even parse it. Since they control the storage and the frontend, I'd say they have a very good chance of being able to reason out that problem pretty darn well
Cell-i-Zenit@reddit
especially in FE where you manipulate the json directly without knowing about it (eg any type ;) ), alot of stuff can happen.
Additionally 100% FE devs dont think about migrating their data in storage. They never have to because that is were BE engineers come in and prevent them from by having versioned endpoints etc.
Iam not saying it cant work.
But if i take into consideration the "average" dev, then this will fail spectacularly.
Also this whole idea sounds incredibly bad so i suspect the skillset in their team is pretty low... fighting for schemaless storage in 2026 is like all the mongo db is webscale bullshit again. Have they not learned anything?
03263@reddit
Job security for all
caffeinated_wizard@reddit
“Can we migrate this with AI if we layoff all the senior devs?”
Windyvale@reddit
Are you my old company?
davewritescode@reddit
What really matters here is the volume of data, if this is anything less than a billion rows this isn’t a one-way door.
Assuming this is not a billion rows, while I agree with OP, storing collections in a single record can lead to some weird edge cases a lot of times this won’t matter unless you have multiple users editing concurrently and even then you can bandaid this. This is a time when you raise your concerns publicly and just go with it.
If there’s a lot of bugs or bad UX you look smart while not explicitly trying to make your lead look like a moron.
yxhuvud@reddit
OP is the frontend. The migration is not his problem but reside squarely on the backend. I'd call it a learning experience.
New-Locksmith-126@reddit
You need a migration already to add the overwrought schema OP is imagining. I don't see why a data migration adds a lot of complexity here.
MoreHuman_ThanHuman@reddit
ain't no thang
ciynoobv@reddit
At face value I agree but I think the reason we get hung up this kind of stuff is that we’ve been burned far often on "bad faith later".
SELECT LATER FROM PLANS WHERE LATER = 'NEVER';
03263@reddit
True but it's still the business problem if their product is not working as intended, not really our concern if it ever gets fixed or not. And maybe the way people end up using this feature the blob of data will just work fine.
nickelickelmouse@reddit
This is definitely not always true.
Unhappy-Ladder-4594@reddit
But its definitely not always false.
FactCompetitive7465@reddit
For large impact decisions or just plain disagreements we adapted this pattern that Microsoft documents: Maintain an architecture decision record (ADR)
We adapted it 'Technical Decision Records' (TDR) since they are not always architecture decisions and we create one to compare approaches and pick the best option. Extremely helpful for ensuring decisions within the project stay consistent and we don't forget reasoning behind certain decisions.
New-Locksmith-126@reddit
I wouldn't even store this in a server-side db initially.
Model it however you want in a browserside db, and sync that periodically with the server.
The sync can save all the filters at once. Who cares? You're just storing it as a convenience, right?
Only if you want to upgrade these filters to shared objects (i.e. between users) do you need to invest more energy into a db schema.
symbiatch@reddit
And when user uses two machines to access…? Perform conflict resolution somehow? Break stuff?
New-Locksmith-126@reddit
Depends on the app. If it's b2b saas most people don't actually use multiple devices.
Saved table filters are not mission critical (considering they don't even exist yet, apparently). Overall, storing locally is an improvement.
Once you have that working, sync it ban to a user settings blob or whatever. Then it persists across machines. Done.
Making a DB schema for this is just premature optimization. Incremental improvement is the way to go.
symbiatch@reddit
“Most people” isn’t what one wants to go for. If they’re paying clients they won’t be for long with that attitude.
Making things more complicated also isn’t the way to go. Stored filters might be important - considering they mentioned literally v1 this might not have users right now.
I can see so many issues and handling them properly is not premature optimizing.
New-Locksmith-126@reddit
I can imagine a bunch of issues too but that doesn't mean they're likely to happen.
Anyways I think I got distracted from the original ask which was about how to handle the conflict.
I would try to understand the more tenured person's concerns. Don't assume that they don't comprehend normalized schema design, just because they want to use a blob.
RequirementsRelaxed@reddit
Yes exactly; more often than not you’re missing some aspects of the bigger picture that they’re talking into consideration
RequirementsRelaxed@reddit
You need to think harder and flesh out your argument in a form that can appeal to upper management. Then start arguing based on (your understanding of) the bigger picture and go top-down. In the process you’ll either find out you were missing some information or convince the other party (or their boss). Regardless of the technical merits of either position, you leave the execution decision to people who are paid to take that responsibility
586WingsFan@reddit
The other person is more senior, so ultimately they will be held responsible. State your opinion, if the other person still disagrees do it the way they say. If anything goes wrong you can say I wanted to do it X way, but senior dev told me to do Y
DesperateAdvantage76@reddit
You defer to the person with higher authority and note your concerns. If you are in a deadlock with someone of equal authority you ask your lead/manager what to do depending on how iimportant it is.
moreVCAs@reddit
Strong opinions weakly held.
metaphorm@reddit
this isn't a hill worth dying on. there are pros and cons to each approach. just ship something and commit to maintaining it. if it needs a refactor later, so be it.
Dhczack@reddit
Just implement. In 10 years you won't care, and if we're being honest you shouldn't care now because it doesn't sound like the weight of responsibility for this is on your shoulders. Worst case scenario you refactor to your approach later and get to feel smug about having been right. Maybe leave a comment to the effect of "this approach has some potential issues that could be resolved by a different approach."
oblongfuckface@reddit
* It depends on the ask. If we’re disagreeing on something fundamental to the project (like a critical architecture update, or a change that could seriously impact the system in a negative way), I’ll push until my point is made and I’m convinced it’s heard by those who need to hear it. If it’s something trivial or less critical, I’ll argue my points but I won’t die on the hill. Always try to keep an open mind and hear others’ point of view
* Same idea as above, depends on the criticality of the ask. if I’ve articulated my concerns and made them known and it’s falling on deaf ears, there’s not much else to do. I see my role as providing technical guidance and detailing options and risks; I can make the argument, but I can’t make someone’s mind up for them
* Take it on the chin and press forward as you can. If you hit into technical issues or constraint, make them known early and to those who can do something about it. Also document everything and refer stakeholders back to this to make it known this was discussed and decided on. Architecture Decision Records (ADRs) are your friend in these scenarios
* Maintain the mindset that I have a lot of value and experience to offer, but I also don’t know everything. It’s healthy to discuss options that I may not agree with, and helps me to think critically about solutions and my approach. Always keep an open mind and be respectful of others’ viewpoints
TL-PuLSe@reddit
I'm not going to do any better than what has already been said, but there is a well established way of handling this. Ultimately, the "more tenured person" weighs the options and makes the decision. Your role at this point, having voiced your concerns and suggestions, is to do the best you can with the decision they make.
https://en.wikipedia.org/wiki/Disagree_and_commit
Hot_Money4924@reddit
Here is what you do, from the perspective of a "more tenured person". You respect the expertise and seniority of your colleagues because you're the newest member of the team and you want to be seen as an asset, not a threat, and not an ignoramus lacking years of battle-tested wisdom. You accept that often times "perfect" is the enemy of "good" so if there is an acceptable convention then just follow it.
When you want to present what you think is a better idea then you pose it as a question or series of questions as if you truly are a smart but curious dumbass who needs the input of your peers. You leave the final decision to them but present yourself as insightful and open-minded. What I'm saying is don't be abrasive and don't dig-in, just be like "Hey, blob storage will definitely work, I was just thinking that it seems to leave a couple gaps and maybe we could fill them by doing it a different way, but I want to know your thoughts if there's a reason that won't work or a stronger argument to just do the blob storage."
You need to build social capital and respect right now, and you do that by being helpful and positive, even when pushing back, and then ultimately falling in line with the consensus and being a team player if you are overruled. No sour grapes. Let go of the technical fights, especially over minor shit that doesn't make or break the bottom-line. Your team has deadlines, a stream of incoming bugs, and a never-ending backlog and they hired you to deal with that crap, not to argue about they way they've been doing things for their whole careers.
First you gain respect, then you work to change the culture or the architecture from the inside.
Ratiocinor@reddit
Also it's important to point out that in situations like these you probably aren't telling them anything they don't already know. They probably already know it's not the "ideal" or cleanest solution but they've decided on balance that it's easier anyway. Pick your battles
Because if we add a new database table and change the schema we need to run it through the approvals process and document it and migrate all the testing and live production customer data through and validate that and make that breaking change to the backend and keep everything that interacts with it in sync and we've now made every database backup we've ever taken completely useless and have to develop a migration script to import old backups before this breaking change but also handle backups made after this breaking change and goddamnit it's just easier to leave it decoupled from the database schema in a json blob that we can put anything we want into and you can add as many new metadata fields to it as you want for your fancy web frontend stuff without affecting our actual business logic. Annnd breathe
Tbh this disagreement just feels like "we don't want our database schema to be dependent on the stupid user defined filter's functionality" because they know as soon as you implement that you'll be like "actually it would be cool if user's could have more than one record per foobar" or "can we add a column for baz" and it would be never ending
psysharp@reddit
Yes but the reason they’ve got a never ending stream of bugs is precisely because of how they’ve been doing things all these years. What are you, the nurse or the surgeon?
nullpotato@reddit
I get a lot of traction when asking curious questions about places where I can see the plan misses something. "Blobs sound neat, but I'm not understanding where we store them when users want to share queries, can you explain what I'm missing?"
And then watch the light bulb click on when they realize their solution can't handle it. Or they explain something you genuinely overlooked.
ChaoticBlessings@reddit
I would emphasise that this approach holds true for basically any professional position in life. Unless you are being hired to scorch the ground deliberately (as in: come in and take responsibility for fixing this thing no matter what), asking questions and building rapport is near universal strategy no matter who you are and no matter what you do.
For out profession, be that development or architecture, we get confronted with half-broken systems that evolved over years and accumulated tech debt from tradeoff decisions all the way through our career. Being understanding for the people who had to build these things, often against their better judgement, is key for… well everything really. And the same is true for a situation like OPs.
Good advice all around.
really-tile@reddit
As a senior dev this is the true answer.
MaiMee-_-@reddit
Who here isn't "senior" somewhere lol
If you're FAANG senior then maybe that's something. Not to dismiss your specific experience or anything.
really-tile@reddit
Unfortunately for me I’m senior in every aspect
Interesting-Monk9712@reddit
I will document my disagreement and propose an alternative I deem to be superior.
If it ends up badly, I am not at fault unless I made the decision in which case I couldn't care about if somebody else didn't like it, its my ass on the line, I am making the decision.
nullpotato@reddit
My only argument against this is if you are in a similar position to me, where you are the one who gets pulled in to fix things. So it will become my problem in like 6 months and if I can argue a bit better now we all dodge that time waste.
Interesting-Monk9712@reddit
If I get pulled to fix a mess somebody else made, I am taking my sweet time to fix it, so its a win win for me.
Or I negotiate a raise/promotion
eled_@reddit
Yup, if you think a valid, eventually superior, design alternative exists, document it.
This is one of the reason we encourage ADRs commited with the codebase. You can make architecture / design proposals, they embed context, you eventually mark them as rejected for x, y concern.
Best case there is a turnaround and you have somewhere to pick up from, worst case you have a trace of what was considered and why you did/didn't do it.
MediocreDot3@reddit
I generally won't argue or debate with people unless the idea is dangerously bad or it's going to create more work for me and me only and it's not coming from my manager or a stakeholder
New_Enthusiasm9053@reddit
I mean this is dangerously bad. They're trusting the frontend to provide valid data when the user can send whatever they want. Any filter changes should be an API endpoint that loads the blob from the DB directly, mutates it and writes it back in a single atomic transaction.
Probably unlikely a filter leads to an exploit but weirder shit has happened. Trusting frontend inputs is some whacky shit.
Yeah-Its-Me-777@reddit
Additionally, you just know that there will be this one power user who defines around 10k filters and complains that everythign is soooooo slow.
nullpotato@reddit
Or a manager that wants to share queries to everyone on their team
Material-Smile7398@reddit
This is the correct answer, I’d 100% challenge this decision as well. Being less tenured doesn’t mean you don’t have a valid opinion.
revolutionPanda@reddit
Tbh. I don’t really care that much. I let them know my opinion and that’s it. If their method works, great. If it doesn’t, it’s noted that I suggested some different. Other than that I don’t care too much.
mxldevs@reddit
Whoever is taking responsibility for when things go to shit is the one that gets to roll with their implementation.
charging_chinchilla@reddit
You "disagree and commit": https://youtu.be/Afoh23PHVP0?si=SzAioJ5dXr4___pP
You both raise valid points. Ultimately, it sounds like you were overruled. That's natural. Not every hill is worth dying on.
This isn't some huge irreversible decision, so just disagree and commit and move on.
Aleks_Zemz_1111@reddit
Stop arguing about JSON blobs. You're debating the orientation of a specific gear while the factory is on fire and the Tech Lead has already been thrown out the door. I've worked 16 sh*t jobs—from Lithuanian factories and roofing to running a multi million pound foiling machine, and I've seen this pattern. When leadership vanishes, the tenured staff hide their own stagnation by reverting to the path of least resistance.
You've correctly identified a systemic flaw, but you're wasting energy trying to convince a busy fool who is just trying to survive the next redundancy wave. This isn't an architectural disagreement, it's donkey work. You are currently a replaceable number in a broken system. Implement their broken blob, collect the paycheck, and stop losing sleep over a machine you don't own. Use that reclaimed mental energy to build your own sovereign digital asset so you aren't the next 'redundancy' when their acceptable v1 edge cases eventually blow up the supply chain.
Material-Smile7398@reddit
I had the exact same argument with a colleague recently, they wanted me to store UI settings as a JSON blob.
I knew from experience that this can be problematic, basically relying on the UI grid provider not introducing breaking changes etc. IMO its a cheap solution that introduces problems later on, and like anything, separation of concerns and modularity is of paramount importance.
CyberneticLiadan@reddit
> When you have a genuine technical disagreement and you think you're right, how do you decide how hard to push?
It depends on the stakes. Things like user safety, business data integrity, and security are lines where I'll stand my ground. This kind of disagreement ain't it.
> When do you stop pushing, and how do you know it's time?
Have you clearly documented and conveyed your reasoning? Have you fully understood the position of the other side? Great. Keep moving.
> How do you accept the outcome when you still think the team chose the wrong path?
You're employed to exercise your professional skills for the organization. This isn't your personal magnum opus and an expression of your personal identity. Don't attach your identity to particular outcomes, products, or deliverables. Identify with the quality of your process.
> How do you maintain your judgment without becoming the person who fights everything?
Keep learning, keep an open-mind. If it helps you can keep a little "told you so" scorecard in the back of your head. Treat all of this like an ongoing science experiment. In some of the cases of disagreement, you'll go along and see that the choice didn't matter that much. In some cases you'll feel vindicated.
Wide-Pop6050@reddit
It is true that you have to balance technical disagreement with the other considerations. Something may be an acceptable risk, or truly not essential for V1.
You have to be very careful and delicate about this. One thing that helps is being very matter of fact and logical, and never get emotional. That helps keep it a discussion not a fight.
It is definitely easier to fight back if you have some leverage. Expertise in that area, seniority, tenure at the company, etc.
minusfive@reddit
We call that “disagree and commit”. Express your disagreement in a positive way, record it if possible (again, constructively while not making the decision maker feel / look bad), then let it go and focus on putting your best effort into implementing their solution. You’re part of a team, get used to it. And always be open to the fact that you may be wrong and there’s more to learn, especially when you think you’re right and more senior people are pointing in a different direction.
If you were right all along you’ll know and they’ll know, and you’ll look great. If you were wrong you’ll look great as well for being a team player and open to grow.
asarathy@reddit
You make your case, but in the end sounds like the person with more tenure makes the call. So then you disagree and commit to the plan, but document what you suggested and hopefully if you were right the next time they will listen to you more. Until it's your responsibility all you can do is make sure it doesn't come back on you and be seen as not a team player.
CerealkillerNOM@reddit
I'm there for the money. Either way works
-darkabyss-@reddit
I'm starting to learn the importance of this approach after many cycles of burnouts. Not my monkey, not my circus.
Big_Bed_7240@reddit
Boring non-answer. We could just retire this sub at that point because that answer works for literally every single thread.
gfivksiausuwjtjtnv@reddit
It’s true though. Why make a big deal? The world won’t end. Nobody cares about your stupid product.
I hated the architecture of our last product. Shitheap. Tried to push it in the right direction and was blocked by the others. Guess what, it had no users and got mothballed in the end. Multiple person-years of effort on it
Big_Bed_7240@reddit
Yes, of course it’s true. But why even discuss anything here at all then? You will always fallback to this answer when you run out of things to say. It’s just intellectually lazy.
Why discuss anything at all? We’re just stardust experiencing itself worrying about trivial shit.
Great. Now what?
Pleasant-Cellist-927@reddit
Why bother doing anything well then if you're here for the money? Might as well just do whatever management want.
Management and the business do not give a fuck about how you structure the code architecturally, how readable it is, how the databse patterns are designed. All of this is here so that when the business inevitably changes its mind, future you has an easier time making said change.
AcesAgainstKings@reddit
Not particularly helpful
CerealkillerNOM@reddit
The gist of what I'm saying: Choose your battles. Some are just not worth the trouble.
Sometimes it's good to push back. This one isn't the case.
There is so many folks out there driven by ego. They seem to argue for the sake of being right. I'm there for the paycheck.
SpudroSpaerde@reddit
Ok but the interesting discussion is how you choose your battles? Captain Obvious.
magicpilz@reddit
I bet you are one of those guys that he describes
SpudroSpaerde@reddit
Considering my other reply in the thread I bet you don't read well.
Pleasant-Cellist-927@reddit
You're not important enough to be keeping track of in a sea of comments. Good job proving the ego-driven point though.
SpudroSpaerde@reddit
Edgy. Isn't the true form of ego treating a forum as a write-only place? Why even engage if you're not doing so honestly? Especially in a thread with less than 100 replies.
DrShocker@reddit
I'll just point out I'm scrolling on my phone mainly to shitpost and if your comment is above this, I would have had no reason to notice your name, and if it's after this then that comment isn't possible for me to have noticed before reading what you've said here. Reddit rearranges things in different ways and deemphasizes which user said something.
So yeah, it is just simpler to assume no one knows what else was said because they're being lazy.
ShoePillow@reddit
Who even keeps track of who wrote which comment and tries to formulate a complete picture of what each individual commentator has in mind. Just state your point here.
AcesAgainstKings@reddit
This I can get behind.
I think I heard a quote here once which had the gist:
JuanAr10@reddit
CDD: Check-Driven-Development!
bstaruk@reddit
Pot, meet kettle.
NewFuturist@reddit
All the other replies to you think that somehow you are going to save the company and the world and end up on TV because you made the "right" technical decision. Everyone needs to realise it is not your code. It's the company's. If the company is paying you to make suggestions and you make the suggestions and the company also pays someone else more money to make decisions that override yours, that's the decision. Don't over think it. Be ready with the fix when it falls over and move on.
CerealkillerNOM@reddit
Amen brother.
I distilled 20 years of cooperate experience into less than 10 words but there is obviously more to it. My secret to survive so long in tech without burnout is to not care too much about things.
Sometimes I do care, but only if decisions put the company at risk or cause me issues in the future. But we are discussing some freaking filters for a data table here.
pl487@reddit
Anything short of a security hole or data loss, I don't push, I just state my opinion and let the org decide. This kind of thing isn't close to important enough.
ZombieLavos@reddit
What is the user story ? When I lead a team I left design and implementation details on the person working the task. My reasoning for that is if I tell you how to build something and you 100% disagree with me. You still have 100% control on how you are going to get it done. When it came to code reviews for the task I was focused on style and code flow. Does it meet our use case for the story. In your example I would accept either design if it met the user story need. For the blob example sure I can see that we are making it simple to get the feature out. Your example might take longer but provide more rich features.
My philosophy for project work. Keep moving, see what works and keep trying. What you need today you might need something different tomorrow. Have fun doing it.
muntaxitome@reddit
Well if I really believe that their choice will cause big hassles in the future I will make the case very clearly, but pretty much just once or if I really care maybe a second time.
However, it is not my company, End of the day someone has to make a decision and if the person responsible for chosing or implementing picks X then I will support them in their misguided efforts.
Which-Meat-3388@reddit
This is the healthy response. Do your job by suggesting a better alternative. Don’t try to be a savior, or go above and beyond for an organization that will drop you at their convenience. Give other people the latitude to try and fail on their own. You can be the hero then with your “I told you so” plan later.
Also none of this will matter in a few years at most companies. If they are still around working on the same thing it will have been replaced, rewritten, or hardened into something serviceable. Maybe you won’t even be there.
kagato87@reddit
From a technical standpoint, their design isn't as wrong as you think and does have advantages. (I'll get to that in a minute.)
For the disagreement, especially when you're new, is to understand WHY that decision was made.
With any workplace disagreement, as a general rule, approach the problem from a point of understanding. Learn why they made that decision. Sometimes, especially for sql, "because it works" is an answer you get. Other times, there is a very good reason.
You need to understand that reason fully. Then you can make an argument that they will understand.
For your example, and because this is in my domain (sql), I will give you some possible arguments.
For starters, if that entire json blob is only a few hundred bytes, heck even a few Kb, it is cheaper on the sql server to return the users entire filter set in a single transaction and profess it on the front end. One connection, one read.
The key advantage of normalizing out data in a database is SARGability. The ability to Search ARGument it. If you need analytics that show what kinds of filters a large subset of users are making, then there might be value on having that represented in a way that can be indexed.
From my background, I'm inclined to lean towards the existing implementation being better. Why? Because how is that data retrieved? This is a user preference. Will it ever need to be searched and retrieved by its content, excepting rare upgrade scripts?
That's the killer question, and the important one in sql. How till this data be used. Only the keys that could be searched and filtered on matter 9 times out of 10 (there's that "why" again - it's not always the case).
There is one important behavior of sql to be aware of: it always reads and writes while pages of data at a time, and that page is usually 8kb (it's configurable, but it's uncommon to change it).
If we're talking abiut 50-100 byte filter sets that can be unpacked downstream - on the app server or user computer, then a single blob is the right answer. If a user might have filter definitions in the MBs, then a single blob will start to fall apart. If that filter needs to happen at the sql read level for some reason (like RLS), whole different story as soon as you need to use it in the sql engine itself.
Context matters. Understand the whole problem.
MaiMee-_-@reddit
Nice discussion you opened up here. Didn't think we'd have an actual career-relevant topic in this sub, but it's nice to see.
It depends on how wrong I think they are, and how much of my own ass is on the line. The more wrong they are, the more I push back. The less this decision affects me in a foreseeable, concrete way, the less I push.
If it doesn't really matter, I make my opinions known and then the team accepts the consequences of their decision. If it matters but I'm not responsible (because there's someone higher up), I need to look at whose ass is actually on the line. If it's partly me because of my role as a developer, I try to get it documented. If we're not doing RFCs, I'll at least write up an ADR with or without their help. If I am responsible, then I decide. If it sort of matters, sort of doesn't (you can fail) (as opposed to you don't want to fail), I allow the team or the person to fail (or for me to be wrong) and to take it as a growth opportunity.
I take it that you don't own the responsibility with this question. I don't push particularly strongly (that is my style). I push once, perhaps twice, ending at something concrete (documentation) being recorded. After that, it doesn't really matter as you are not responsible. Doing too much is likely to be more negative than positive.
This is not a problem for me since "we aren't saving lives here." If I don't own the responsibility, it's not my concern as long as I did my due diligence. So after doing that, there is nothing to regret. Success or failure—that is all with the team. I don't really take it upon my shoulders. It's much harder to deal with outcomes that are on your shoulders, so I worry about that instead.
My two cents on this: You don't have to not fight everything. But you have to be able to work well with people. Try gaining more people skills. Look at people. Observe them. Analyze them. See what they like, what they don't like. What their main concern is. (Not concern as in the problem but concern as in what they focus on.) Some people almost welcome conflict. Some people hate it to death. You need to treat people the way they wish to be treated.
I very much see quirks with all my team members. I notice how they work. And they work differently. Most people probably won't work the way you would like them to, but after you learn to accept their strengths and navigate their... gaps, you really can appreciate competent people. I just hopefully assume that other people give the same grace to me. To which being competent assuages this worry in me.
gdinProgramator@reddit
I am actually working through this exact problem, and can share some insight. We did a full refactor from blob to per-record in the DB.
First off, the blob storage becomes an issue when you have thousands of entries in it. For a few hundred the weight is insignificant for modern web stacks.
Another issue we had is that there were other regulated systems that specifically HAD TO get a JSON. So I had to make adapters for them.
It’s a fucking filter man, nobody in c-suite gives a shit about it. Go with the idea of the more tenured colleague and make your mark elsewhere
Lotus_Domino_Guy@reddit
Being right isn't actually that important. Don't take it personally either way.
CardboardJ@reddit
You do what they say and collect a paycheck. If it's stupid, then you've learned how it's stupid. If it turns out that all your fears are unfounded, you learn that too. Maybe you notice that it's a really good idea in some situations but bad in others and then you've learned that too.
Stop being mentally inflexible. Learn, adapt, and grow.
phatmike595@reddit
20 years ago, we handled this by a couple of us fresh out of college decided to go over our boss' head to the president of the company with what (to this day, after adding 20 years of experience I still stand by) we felt like was technology malpractice. It didn't go how we planned, and I quit before finding out how my boss would retaliate once he found out.
I landed at a spot where I was fortunate to have an incredible mentor, and the biggest lessons I learned had little to do with tech and everything to do with how to communicate effectively and persuade gently in corporate environments. My strategy these days when i disagree with either my team, my leaders, or my customers is to try to trick them into thinking they came up with the right answer. People are much more willing to change their mind about something if they think they're doing it because they came up with a better approach.
Far_Swordfish5729@reddit
You have to judge this based on the actual business outcome of the bad decision and how invested the process is already, the same way you would triage a bug. Is it worth the upheaval based on the impact? If the observed bug requires a user to open and edit two separate preset filters on two separate tabs without reloading state on either, how often does that actually happen? How much of a disruption is it? Often the answer is not often and not much. If you are in an authority position, use it as a teaching moment and ask for a revision. Don’t go to war with someone over it.
You have to pick moments that actually matter and that are obvious. Even then, technical and team upheaval sometimes requires the right moment. You will find yourself disregarded in favor of inertia and need to wait until there’s a visible problem to present your solution. Never handle this by being impersonal and then saying you told them so at the crisis. Politely disagree and then be visibly helpful in the crisis. It works over time.
In this case, my actual recommendation would be to use a json column or edit library if supported rather than raw binary and only modify the portion of the blob that actually changed. Relational databases have supported that for over a decade and it’s pretty normal. Just suggest the write should be a key and fragment so you’re not round tripping or accidentally reverting unchanged, out of sync data.
rk06@reddit
it is very easy: don''t fight. do what you are asked.
FX2000@reddit
You can make your case politely and hope people will listen to you. If they don’t and you’re not in a position of authority then disagree and commit, don’t become a blocker or a whiner because you didn’t get your way. Ultimately if you can’t articulate your opinion in a way that will convince others, maybe you’re not actually correct, always leave room for introspection.
jake_morrison@reddit
It is sad to see how far the mighty relational database has fallen. The MongoDB brain worms have taken over.
IdeaJailbreak@reddit
I mean, if they want to store it as a blob, that's on them. What I would be arguing about is that the API contract makes the frontend overcomplicated. He's basically pushing all the complicated bits on to you, you might as well consider storing these directly on object storage and skip the backend entirely at this point because you aren't getting better semantics from the backend.
30thnight@reddit
There’s no problem with his approach but I do agree with you, it almost always sucks terribly and the refactor will never happen.
But at 5 months in, there’s a good chance you may still need to be building rapport on the team.
I wouldn’t push the issue but on the frontend, I would highly recommend you use a define a schema that you can validate the JSON against with tools like Valibot (Zod works too if you already are using it)
This way, the FE team still infer types from the schema, simplify any state management, and make any future migrations less painful.
Isogash@reddit
For this case, they are right IMO. The main benefit of blob storage for front-end user prefs is that the back-end remains decoupled from the design of the front-end. If you need to change how a user pref works, then you only need to change it in the front-end where it matters.
You're right that some features will not be possible in this design, but unless those features are on the roadmap, you shouldn't assume that they will ever be needed. It's probably not your job to decide on which work is valuable (normally that's Product domain) so the best you can do is make the case that this will save time overall and hope they agree.
In general, it's a good idea to design components that change independently and keep their communication boundary simple and fairly abstract so that they don't need to change often (updating a communication boundary is expensive.)
Anyway, as for how hard should you push, the answer is "not so hard that you create more problems than you solve". There's a knack to being able to disagree constructively without frustrating people and making the work environment more difficult for all of you.
Respect that engineers with more experience than you have more than likely seen these scenarios play out before, and are choosing solutions that avoid real problems they have had experience with (e.g., overcomplicating features and creating more maintenance work than was needed.) Ultimately you'll need to accept the decision and move on.
findingtheyut@reddit
I don’t know the full use case, and I also don’t know if I’ve fully understood the design of their co-worker, but I’m inclined to agree.
What are the odds that there would be concurrent writes in this system anyways? I wouldn’t expect a user to regularly create multiple, different filters in bulk, if ever, so the whole case of conflicts is fairly moot. One can also use etags for optimistic concurrency control - assuming this is Azure Blob Storage.
I’m also curious about the listing of all filters for a particular user if there would be different IDs per filter. Not something I’ve personally tried to do since I usually use blob store for point reads
blood__drunk@reddit
Remember - there is only disagreement because you both think you're right.
Also remember - in many engineering situations you can both be right.
Don't dig your heels in just because you think you're right. Ultimately if you've made your arguments and the decision is still to do it the other way then that's that. Disagree and commit. Sometimes you're actually right, sometimes you're actually wrong, and most of the time it doesn't matter.
Professional_Mix2418@reddit
Sometimes the best answer is the wrong answer. I value consistency more over a better approach. So one way to move forward is agree to align with this, but to have a backlog item to refactor all to a better approach.
You both win 👍
ShoePillow@reddit
Why does the QA weigh in on this decision?
It should be the call of the feature owner or the lead.
If you don't have such a person, it should be the decision of whoever implements it or has to accomodate their code for it.
If they don't agree, let it go. You can mention it in some document or ticket if you want, but don't expect to ever have to come back to it
Oakw00dy@reddit
The root of the problem is that you don't have a lead who's responsible for the decisions and the outcome. Right or wrong, it should be their call. Can't you go to your boss and ask who's the acting tech lead? In this case it seems the more tenured colleague is the lead by fiat, so disagree and document but once the decision is made, commit to the solution.
yxhuvud@reddit
I start with asking the question: What are the consequences of choosing the wrong answer? Here, it is quite probable that there is essentially no consequences except a bit extra work. No data loss of consequence etc. I'd argue my case, but accept a loss. Life is too short to die on hills for no reason and sometimes people need to choose the wrong solution a couple of times to learn how to do it right.
I'd also agree with your opinion on how the api should look like. Bulk updates in crud APIs are sometimes necessary but usually really rare.
softgripper@reddit
Sometimes you'll realize there are actually 2 versions of "right" and you have to let one go.
You can probably do something with client side storage across tabs relatively easily.
The devil is in the detail.
TheTacoInquisition@reddit
Document what the worries are, what the trigger point is for doing something about it (could be a single incident, could be x hours of manual intervention if one of the worries happens often, etc), and then make sure it's easy to change later if you need to. Put a service layer abstraction in front of the data writing and reading and then the implementation choice is isolated and shouldn't be hard to alter later if your fears turn out to be correct.
Then just get on with it and circle back around if the worries were correct.
Personally, unless I can see a REALLY big problem (for example, storing passwords in cleartext in the DB, or allowing a user to see another users bank details by changing the ID in the url, etc), I'll just figure out what I think could go wrong, and then either agree to mitigate it or put some observability in to see if, when and how often it's happening. That either gives me actual metrics to use if I'm right, makes me feel better that the problems are not happening if I'm wrong, and I tend to be quite modular in my code anyway, so changing things is often not that hard.
What I won't do is keep coming back around to it UNLESS it's shown to be a problem. Spending extra time pissing off your colleagues and never letting them win a technical disagreement isn't going to help you. Give and take is important.
EdelinePenrose@reddit
> how hard to push & when to let go
it’s probably never a good idea to push too hard without clear consensus, authority, or accountability.
view politics as a marathon not a one and done sprint.
state your proposal clearly in written format.
state your feedback for others as questions in written format.
let go when people stop engaging with your ideas or when they are rejected. there will always be another chance to voice your opinion.
escalate abuse to your manager. otherwise, don’t take feedback or losing a technical decision personally.
> how to cope
learn to disagree and commit. record the ongoing costs of the decision and try to manage them. make it visible to your manager how productivity or customer satisfaction is being impacted.
> how to not become the difficult co-worker
choose your dissent well. not every decision requires your input. you’re not forced to take all the battles you’re invited to.
—
what’s your manager’s role in all this?
D-Alembert@reddit
If I think it's so wrong that it's a hill worth dying on, instead of dying on that hill I push as persuasively as I can until people are reaching the point where they're unpersuaded and just want to move on. At that point they'll politely continue to hear you out but they're not entertaining change, the status quo has too much inertia, I'm not going to be able to turn the ship, so all I'd be achieving would be straining relationships if I continued to push.
At that point, I drop it completely and go with the flow. Not grudgingly, but genuinely; this is the path we're taking so I'll do what I can to make it work.
YMMV. Depending on company culture you might want to email some CYA recommendations at some point in the process, but that doesn't have to be confrontational, it just needs to exist
greensodacan@reddit
Focus on specifics, don't generalize the other side. It's more verbose, but you keep the conversation squarely on the technical end without critiquing the other person.
Some people may try to goad you into personal attacks, or make emotional pleas by mentioning someone's skillset or experience. If that happens, acknowledge that you see the plea, but that you'd like to focus on the technical side because the goal isn't to critique anyone's expertise.
Give it a few tries, then decide if you should escalate. Never let yourself get frustrated into acting unprofessionally.
Write down what happened and why. Keep track of how often this happens. I've worked on teams that made the same mistakes over and over, and it was years before I realized how poor the decision making in that org actually was.
Don't allow work to be your identity. Have a personal project going so that you can mentally lean on it as your "focus". The work project is for money. Not your sandcastle.
Again, you really want to keep track of how often this happens. Have a work journal, and when you notice that you're frustrated for too many projects in a row, it's time to look elsewhere. People leave jobs out of frustration all the time. It's more professional to do it sooner rather than later.
symbiatch@reddit
I won’t address the matter that was disagreed upon since that’s not the question here.
If the matter is actually worth it and it’s a dev level:
If both sides have said their case and there’s nothing clearly changing the viewpoint of one or the other then I’ll bring someone else in. Explain both sides. Preferably not “I said and they said” but more “this is the issue and there’s two viewpoints, do you have other views or knowledge or comments?” It’s not always possible to anonymize, for example if it’s some PR, but still keep it impartial when presenting the case.
The third person can then give their view and that might already be enough. There’s not much reason to keep fighting.
If the matter is actually worth it and is at least partially outside dev level:
Discuss it with any stakeholders. Business/product side should know if there’s something that may affect things. If they’re ok with things not working the best in this version then that’s it. If they’re not then they’ll ask for changes. The. It’s outside dev decision and that’s it.
If the matter isn’t worth that much of my attention:
State my case, possibly mention in the ticket or somewhere that “the implementation has these issues which may need addressing later” and that’s it. My view has been recorded, there’s a possibility someday in the future someone runs into it and sees “oh someone actually thought about it” and/or “ok this feature does need changing since it’s said here.” And that’s it.
I was actually today the third party in one dev level disagreement. Didn’t go as I hoped it would and one party didn’t accept “two against one” even as a result, and not even “two-and-strong-preference-from-third against one” for some reason, in a kind of trivial matter. So now this case requires more checking why that happened. And that’s another situation I have to think how to handle since it’s not in my responsibility but affects wider things.
VoiceEnvironmental50@reddit
He’s right
MetalKid007@reddit
For me, I simply ask questions. Instead of saying we should do B instead of A directly, I ask questions about things that would naturally cause B to be the better choice. Sometimes, people will then naturally say we should do B instead without me saying anything, saving their ego. Other times, new requirements I didn't know about surface. People can often get defensive by being told what to do, but not with good questions.
SputnikCucumber@reddit
There is no lead to arbitrate the decision. So this feels a little like you're indirectly fighting over who is the new 'leader'.
Maybe you can find someone in an adjacent team to weigh in? Someone more impartial.
jiter@reddit
I have my opinion. I make it heard. Management decides. I carry out. So what!?
GoodishCoder@reddit
You have to pick your battles. Implement it so it's easy to swap later and be done with it.
When you're new anywhere you're going to have disagreements about how things are done but ultimately it is going to go to the more tenured employees until you've built a better reputation for yourself.
SecretaryAntique8603@reddit
I’m in a leadership position, but here is how I handle it:
I’ll usually call for a little workshop, have everybody present their arguments, and sum up the most promising options with their key pros and cons accurately represented.
Then I’ll state my preference saying “I value X more than Y, and since solution F optimizes for X I recommend/prefer this approach”.
Then I’ll have the team state their preference, and if it’s not a critical decision I will let the majority rule.
I think you can follow this model even if you do not have any kind of mandate or authority. If you lack authority and strongly disagree with the decision, then just remember that it’s not your problem at the end of the day. Mandate and responsibility go hand in hand, so let someone else suffer the consequences of the decision.
AnbuBees@reddit
If the feature's performance becomes a concern in the future you have another ticket to work on, if it never arises as a concern its not a hill worth dying on.
Shazvox@reddit
First of all I determine how severly an "incorrect" solution will impact us. If there actually is an impact (and not just my own personal opinion) then I inform about the correct solution and the consequences of not implementing it that way.
After that I do whatever is decided and clock out after my 8 hours, go home and do something else. Simple as that.
gUI5zWtktIgPMdATXPAM@reddit
You've mentioned your concerns but the team disagrees. Assuming you're correct which sounds like you are, this buggy approach isn't the end of the world.
I think I'd end it there and let it happen.
Different story if it's something bigger like ethical or security where it matters.
It's also not an irreversible implementation, and could be fixed up with a code change and update script to convert things over.
Also a small feature not some underlying architectural issue.
onefutui2e@reddit
I always think about in terms of "what's at risk?" If your option is "merely" technically superior/clever but theirs is good enough, then you probably don't need to spend too much time arguing about it. If there are real scalability concerns but those are years away, again, probably not worth spending too much time on it (as an ex-Google employee now working at startups, I find myself sometimes still falling into the trap of "everything must scale to hundreds of millions of users with N+1 redundancy from the get go").
On the other hand, if the risk is tangible, the scalability concerns are real and near-term, and/or the cost to pivot later is extremely high, those are generally worth discussing. I assume you're already capable of making nuanced, reasonable, logical arguments and can dance in the political arena a bit, so won't get into that. You'll still likely "lose" at least some of the time, in which I would just note these risks and assumptions in the design doc, tech spec, or whatever you use as a system of record for these projects. Then you can later say, "See, I told you!" (don't do that).
It can be challenging now with AI because you can sometimes find yourself arguing with people who are just plugging your comments into an LLM and then having it come up with counterarguments and then you're potentially wasting time reading slop on top of slop. But that's the world we find ourselves in.
Sorry if I didn't address all or any of your questions directly (it's 6:30am and I'm still drinking my coffee). But hopefully this helps a bit.
Basic-Kale3169@reddit
Just make your code modular so it’s easy to switch from one storage mechanism to the other for your specific example.
Software engineering is all about tradeoffs. The more experience you get, the easier it will be for you to pick your battles.
SpudroSpaerde@reddit
Discuss alternatives with technical lead then disagree and commit. I don't spend time on going back on these discussions unless requirements or circumstances change.
youarewelcomeputa@reddit
How we usually do it is have a tdd list approaches and have their pro vs cons and then recommend a approach. Decide on that and move on , if its against your wishes you highlight your reservations and move on
AcesAgainstKings@reddit
Sounds tough. I think ultimately this is why someone should "lead" any given project so they can make the ultimate call but in practice this isn't always done.
I think if you've made your points but he's the one building that part of the feature it's now on him and you have to step back. If you're the one building it and you've heard his points but are still convinced yours is the way then you may be empowered to do it your way.
The caveat to this is it sounds like the system is already built this way, so if this refactor is going to take significant time you'll probably need to get buy in from stakeholders (which will be tough if another engineer disagrees it's necessary).