Comment by MaulingMonkey
4 days ago
I don't want the private API key I temporarily hardcoded in my public history. Nor do I want the drag of worrying about so much as sneezing in the general vicinity of a secret in my editor window, when I already self review before commit.
I don't want the unkind rant about a coworker's design as I attempt to figure out what they were smoking when they made the thing I'm trying to use, needlessly offending them. For starters, once it clicks, it might all make sense, and have turned out to be my mistake. For another, even if a rant is warranted, a pass for "tact", or at least limiting the blame to the blame that is warranted, is proper.
I don't want to drag a coworker through my chain of confusion until I've made an appropriate amount of effort to unconfuse myself first. To do otherwise is likely to bring us both to confusion, possibly in different ways, possibly including confusion about what we're confused about, which is just a mess and dead weight. There's a time and place to explain and teach, and a time and place to expose my own confusion and ask for help, but neither is step 1.
Even if the API is undocumented and confusing, even if you're expected to ask for help as step 1, there's value in a fresh set of eyes getting a feel for exactly how the API is confusing before that, thus informing directions for potential improvement (be that API changes or improved documentation.)
I'm not advocating committing secrets to version control.
But you can learn to phrase your WTFs about your colleague's code politely and constructively. I would even argue that this an absolutely basic skill for professionals. It typically leads to faster and better answers whenever a discussion arises.
Even if confusion seems to spread in a discussion, I would expect the person who realizes this first to call that out and and to reset the conversation.
There is nothing magic or onerous about this.
> But you can learn to phrase your WTFs about your colleague's code politely and constructively.
I see a fundamental difference between thoughts and whatever words I pronounce. You're saying "you should share your thoughts", and I disagree. My thoughts are mine. Whenever I want to share something with the world, I phrase it and share the result of that process.
> But you can learn to phrase your WTFs about your colleague's code politely and constructively. I would even argue that this an absolutely basic skill for professionals. It typically leads to faster and better answers whenever a discussion arises.
Phrasing things politely and constructively is what I'm explicitly advocating for when I'm calling for "tact", yes. But said phrasing is not necessairly the very first thoughts out of my mind. When we push back on sharing our raw thoughts, it's precisely because we want a moment to be able to translate from passionate, driven, and perhaps rude thoughts - to polite, if perhaps a bit professionally dispassionate words. From unconvincing incendiary moral judgements against the cult of the singleton, to concrete examples of maintainence concerns and tradeoffs that can be discussed by everyone. From things that barely make sense in the context of our own minds, to things communicated clearly within the context and bounds of our shared understanding.
> Even if confusion seems to spread in a discussion, I would expect the person who realizes this first to call that out and and to reset the conversation.
Simply calling out confusion is insufficient to resolve confusion. Being able to narrow down what I'm confused about is an important skill and first step towards either unconfusing myself, or seeking help from others, allowing them to aid me in solving said confusion.
Unconfusing others is a step more difficult. Unlike with my own confusion, I find it necessary to build an accurate mental model of their thought process through my own indirect observation and questions, to understand where they've misunderstood, the correct understanding, and then a means of explaining and contrasting those two states through nothing more than clear communication to bring them out of said confusion. I may have to construct full blown examples, showing a concrete way their own initial biases fail them.
These are important skills and steps to take, of course, and you're right that there's nothing magic about it, but this is something I've expended a lot of time on over the decades I've been puttering around in development circles. It's time intensive, requiring one or more people focusing on a single individual's issues, just to reset things to a baseline of being unconfused enough to do good work.
And, of course, it will always be necessary, and I'm glad to help. It's a skill I believe I'm good at, and by unblocking coworkers and friends, I can potentially spend minutes of my time to save hours or even days of theirs, which is well worth it. But it's also worth taking the time to avoid such scenarios coming up again. It saves me time, and it saves them time.
Sometimes that means clearing up ambiguous or confusing documentation.
Sometimes that means keeping others at arm's length - at least until I'm at least no longer confused about what exactly I'm confused about.