Hacker News new | ask | show | jobs
by convolvatron 977 days ago
you just have to refuse to accept input like 'I don't buy it', 'I tried something like that before and it was a failure', 'thats a code smell', 'I saw a blog post about how that is an anti pattern', and other unsubstantiated disses on an approach. if its so bad, you should really be able to put some real words behind that.
2 comments

You have to exclude them from the discussion if you know they will go there.
I told a team for months to be wary of shoving everything into a single nuget package and using it for everything across 9+ API's.

fast forward 6 months and suddenly they have a lot of problems due to that shared library being a larger risk than they ever anticipated.

sometimes "I've seen this before" is a legitimate concern.

totally. not saying you shouldn't use your experience. but you should use that to really paint a picture of how it can go sidewise instead of just claiming authority. the former really moves everyones understanding forward.
You're not wrong, but the problem is that people sometimes just flat can't see it and think they know better than you.

The example I gave above, I definitely did spent months explaining to them how the risk to a library like that grows unexpectedly over time. How it's a small risk at first but if you don't consider the use of that library over the next few years you don't see where the risk profile ends up.

What's interesting is that I had a similar conversation with a VP recently. What I told him is that sometimes people really just flat out can't see it and in that case you have to "rule by fiat" as it were and issue an edict. If you wait for compromise with someone who just can't see it you'll get nothing done, especially if nothing can ever be agreed upon.

and I say this as someone who is very particular about the battles I'll fight, I'm a fan of compromise but only if everyone in that conversation truly understands all sides of the issue or I think it ultimately doesn't matter (yak shaving).