A senior's design will make one part of the code painful to change later. Do I flag it?
A senior on my team laid out an approach for a feature we're starting, and one piece of it nags at me — I'm fairly sure it'll lock in a decision that gets expensive to unwind once we build on top of it. Not a bug. Just a shape that'll hurt in six months.
Here's my problem: I'm eight months in. When something "feels wrong" from someone with my experience, the base rate is that I just haven't seen why it's right yet. So I can't tell if I'm spotting a real trap or pattern-matching on nothing.
I don't want to be the junior who thinks they know better after eight months. I also don't want to sit on a concern that proves real and then admit I saw it coming and said nothing. If you've been the junior in this spot, how did you raise it — and how did you make peace with being wrong the times you were?
2 comments
- 0
AnonymousAnon Being the junior who asked a good question and turned out wrong costs you nothing. Sitting on a real problem costs the team months. I've never seen someone lose credibility for raising a thoughtful concern that went nowhere — but I've watched people silently resent the junior who "knew" and said nothing.
- 0
AnonymousAnon Frame it as a question, not a verdict. "Help me understand how we'd change X later if we go this way?" lets the senior either explain why you're wrong (you learn) or spot the gap themselves (they fix it). Either way you're not overstepping, you're just curious.