Pushing back on design
Posted by yobuddyy899@reddit | ExperiencedDevs | View on Reddit | 19 comments
I have 4 YOE and work in a relatively fast paced environment (don't we all these days?)
One of things that I really hate about my mind is being pushed and questioned by seniors and principals about my architecture choices. I don't hate the reviewer, I hate my mind for acting defensive and agreeing with them on the spot.
For example, let's say I was designing a painting of the inside of an apple. I show the apple without any seeds in it. Someone comes up to me and says "hey, why doesn't that have seeds?" This makes my mind immediately go to "oh you're right, I should do that".
Then I spend the next 5 hours realizing "oh, this doesn't need seeds because they were taken out and not useful", the concern of the other person isn't exactly true for my painting.
How do I stop my mind from doing this. Honestly, this isn't healthy.
greenhouse421@reddit
I feel like trade school uni (or bootcamp or ..) has a lot to answer for here. Theres a category of reviewer that didn't come from that background and we are seeing this confusion a lot. Challenging your design choices is not supposed to make you go and blindly "add seeds" nor will we be happy when you politely acknowledge our feedback about seeds and say nothing else. It's supposed to make you think and justify your decision or at least note that the omission of seeds is a considered decision. If you do the latter and get more "ok, but why?" You do the former.
kbielefe@reddit
Usually a comment like that doesn't mean "go add seeds", it means "I want to make sure seeds have been considered and if they are omitted it's for a good reason and not an accidental oversight."
I honestly don't care if you forgot seeds or I missed a reason why they aren't needed. We're working together to make a better product.
pizza_the_mutt@reddit
Be clear to yourself (and possibly make it known to others, if it makes sense) that different people have different roles in giving you feedback. These can include:
Most people will fit in one of the middle two buckets.
lawrencek1992@reddit
This
geeeffwhy@reddit
more important than any tactics for the design or design review, i’d ask you to consider how you personally relate to your work product. do you invest it with your ego? if someone doesn’t like it, does that feel like they don’t like you?
when you can separate the art from the artist, you’re much more able to make good use of honest criticism, and more able to ignore the bad faith complaints.
arihoenig@reddit
I think you need to spend more time in Linux or Windows.
OriginalTangle@reddit
I recognize this pattern in myself. In my case, the cause is low self-esteem, conflict avoidance and people-pleasing and I haven't found a real cure.
It's not really helped with skill or knowledge as your mind will just ignore what you know and align itself with what it thinks is true based purely on the question posed. It's frustrating.
One thing to try is to defer answering as much as possible with a "let me get back to you on that" wherever you can. But sometimes you can't without it being weird.
PatchSprite@reddit
The real architecture smell is agreeing with feedback before you've actually processed it, your brain is just running a people-pleasing hotfix in production.
Default response to any pushback: "good point, let me think about that." Buys you 24 hours and makes you sound thoughtful instead of defensive.
FatefulDonkey@reddit
Uou shouldn't be acting defensive, unless it's something you already thought about and concluded a justification of why it's not there.
Otherwise just say; thanks for your feedback, I'll take it into consideration.
Goingone@reddit
Did you mean to paint the inside of the apple without seeds? Or did you just forget them, get called out for not having them, and then realize you don’t need them?
My guess is the later….when it’s the former…you won’t have this issue anymore.
yobuddyy899@reddit (OP)
Thank you. You're right.
As much as I want to make something perfect, it's not always possible. I should probably acknowledge the pitfall of something while I design it
TheOwlHypothesis@reddit
You're doing it right now.
yobuddyy899@reddit (OP)
Fuck
geon@reddit
Try to instead answer something like ”Hm, I hadn’t considered that. Let me get back to you.”
Then you have some time to evaluate the pros and cons in peace.
lawrencek1992@reddit
Do you write like engineering specs or similar before beginning a project? If no, start, and get those folks to review it. If you already do try writing a skill for your agent to do an architectural review for you. As you get architectural feedback in the future you can keep tweaking the skill with things to look out for.
Also if your decisions are being questioned, it’s more about making sure you’ve thought of everything, not pointing out how you suck. I just tore a bunch of holes in my manager’s spec for a 2FA refactor. He’s got three times as much experience as me. I just saw issues he didn’t see when authoring the spec; it’s not a criticism of him as an engineer.
gfivksiausuwjtjtnv@reddit
Dude, tell your manager that you are bad at this and have them do it on purpose to train you up
PsychologicalCell928@reddit
Here's the thing to do:
As you are designing your architecture, write notes about why you made your choices. They don't have to be extensive - just enough for you to recall the thought process.
Also log some thoughts about why you didn't select another obvious option. ( The "this doesn't need seeds ..." part of the process. )
If you are also coding you might include a subset of the reasoning or a pointer to a file containing your design decisions.
When someone asks you about your choices you can either send them the document or pull the document up for the discussion.
I always found it helpful to also include what, where, and how I would change the code/design if the requirements changed - especially things like volume or response time as opposed to functionality.
For example,
/* Requirements state that the total number of items a customer can save and search will never be more than 30. That means that linear search will easily meet the performance requirements. If the number of items to search grows substantially another search method ( binary, B-tree) should be implemented. */
DeadlySpar@reddit
Start your design process by understanding the properties the implementation needs (google quality attributes) so you and the reviewer understand what’s most important. Otherwise people don’t share the same mental model of what is important and what trade offs are being made
throwaway_0x90@reddit
Design docs,
Your design doc should have,