[philh]

> So I decided to gamble on the opposite. Now I just assume I’m below average.

> It serves me well. I listen more. I ask a lot of questions. I’ve stopped thinking others are stupid. I assume most people are smarter than me.

> To assume you’re below average is to admit you’re still learning. You focus on what you need to improve, not your past accomplishments.

I dunno, I'm not convinced this is what "assuming you're below average" really looks like. At least not all of it.

When I think I'm below average I go along with decisions I disagree with; "that's not the strategy I'd go for but you're the person who actually knows our customers" or "that's not the architecture I'd implement but you have more experience with these things". When I think I'm above average, I'll push back harder. It would be nice to get everyone on the same page, ask questions until either I'm convinced or they are, but I don't think that's always realistic.

What does Derek do in situations like that?

[depressedpanda]

It's simple, at least in theory: Don't go along with decisions you disagree with until you've voiced your concerns and they have been addressed.

Having valid concerns is orthogonal to whether someone is above or below average.

[whatshisface]

That only works when both your ability to raise concerns is accurate enough to not just annoy everybody (at least half of your objections should have some merit), and also when everyone is working in good faith and will not see objections as a political attack. (If objections are seen as political attacks, then you should only raise them when a really serious problem comes up.)

[philh]

> It's simple, at least in theory: Don't go along with decisions you disagree with until you've voiced your concerns and they have been addressed.

Depending how I read "go along", "disagree" and "addressed", I think this either doesn't help or is unrealistic.

Like... suppose I say "this plan will run into scaling issues at some point" and the other person can say "that's true, but we don't know if we'll get enough usage for that to be a problem and in the meantime it lets us iterate quickly". I agree with this, but I still think we should go with the more robust thing up-front. How do I proceed?

I could say that I'm not going to work on that plan until I'm convinced it's the best plan. But if everyone followed this advice, approximately nothing would ever get done. If you have a team implementing a feature or product, it's important that everyone is working in the same direction even if they don't all think it's the best direction to go. It's not realistic to expect unanimous agreement on what the best direction is, even if everyone sits down to discuss it calmly and sensibly for a few hours.

Or I could say that my concerns have been addressed, and I go ahead and work on this plan. But why this plan, and not the plan that I prefer? There's a risk that we just go with the plan proposed first, or by the person who's most stubborn about liking theirs, or drawn at random from a hat. That seems bad too.

I don't think there's a good way to proceed where I don't at least try to answer: which of us is more likely to have a good plan? And if I assume I'm below average when I'm not, I'm more likely to get the wrong answer to that question, and then bad decisions are more likely to get made.

> Having valid concerns is orthogonal to whether someone is above or below average.

The things that make me a better dev than I used to be, and a better dev than most people just starting out, certainly aren't orthogonal to my ability to have valid concerns and not-have invalid ones.

If you simply mean that above-average people can have invalid concerns, and below-average people can have valid ones, then I agree but I don't know why you bring it up. I don't think I suggested otherwise.