I’ve had a series of realizations that have helped me with this.
First was that I noticed that on most of my usual internet hangouts, the norm was that if someone is replying to a comment, it must be a disagreement. Even the occasional agreement is often mistaken for disagreement because it’s so uncommon for folks to post in agreement. The more I noticed this pattern, the less inclined I became to follow it.
Second was noticing just how much time and energy I would spend taking down someone’s post in my head, even if I had gotten up from the computer and was doing something else. And while there is something exhilarating about refining an argument, clarifying one’s own thoughts, and then posting them and watching for upvotes, there’s also a very negative energy associated with it that I found lasted a while afterwards. So I came to believe it wasn’t a good trade off.
Finally, a tangential realization. At work I noticed a pattern in others and then in myself where product or technical suggestions would be made and then developers would instantly chime in with the reasons it can’t be done. But it can be done, we have the source code, and our job is to find a way to do it. Dismissing it because our first thought doesn’t work is simply not doing our job. So I learned to suppress any reactions until I’d actually attempted to enable whatever was suggested, and I think this had an effect elsewhere in my life, including posting on the internet.
I think the last part you touch upon is one of the natural dangers of our profession. In my experience developers are simply extremely good at spotting potential issues in projects.
Which can be very good if you’re trying to minimise risks or estimate tasks. It can also be really bad if you’re doing it in the idea-generation part of a project, and it’s just too easy to carry your fault focus into those meetings. Especially if you go directly from development to a brainstorming workshop. I know that this is something I’ve had to work quite hard at myself. Thinking twice before speaking out, to make sure I’m going to contribute something useful. Typically my golden rule is to keep quiet unless what I have to say is positive or supportive. Because it’s exactly like you put it, it can be done.
Regarding your last point, sometimes I will say "the stupidest thing that could possibly work". This is an idea that could work, but has serious and obvious flaws. I find that once a team gets used to it, saying out loud a stupid but plausible solution can frame the discussion away from "whats wrong with the idea" to "find something better".
First was that I noticed that on most of my usual internet hangouts, the norm was that if someone is replying to a comment, it must be a disagreement. Even the occasional agreement is often mistaken for disagreement because it’s so uncommon for folks to post in agreement. The more I noticed this pattern, the less inclined I became to follow it.
Second was noticing just how much time and energy I would spend taking down someone’s post in my head, even if I had gotten up from the computer and was doing something else. And while there is something exhilarating about refining an argument, clarifying one’s own thoughts, and then posting them and watching for upvotes, there’s also a very negative energy associated with it that I found lasted a while afterwards. So I came to believe it wasn’t a good trade off.
Finally, a tangential realization. At work I noticed a pattern in others and then in myself where product or technical suggestions would be made and then developers would instantly chime in with the reasons it can’t be done. But it can be done, we have the source code, and our job is to find a way to do it. Dismissing it because our first thought doesn’t work is simply not doing our job. So I learned to suppress any reactions until I’d actually attempted to enable whatever was suggested, and I think this had an effect elsewhere in my life, including posting on the internet.