Hacker News Reader

I didn't read this as expecting simple answers to questions, but as the question being simple and instead of the person being asked giving a direct answer to that question, instead they give an answer to a tangential question.

I've worked with people who do this consistently. Know this I would try to formulate as simple and direct a question as I could, but always the answer would be to a tangential, often more basic question.

At first I thought maybe the person was being condescending, answering basic questions that weren't asked, that anyone in my position should know. Maybe he was, I still don't know, but I refused to "believe" that. It's tricky suspecting something but forcing yourself not to believe that thing, but it was very helpful in that I was prepared to get past the initial phase of him not answering the actual question without it being contentious at all.

I agree with OP, it does seem like a lot of people make no effort to communicate clearly.

There are no shortage of such people - I've encountered a bunch. And yes, it's always a pain in the workplace. In my experience, this strategy:

> Know this I would try to formulate as simple and direct a question as I could, but always the answer would be to a tangential, often more basic question.

Always fails with them. At some point, you have to become humble enough to realize that your approach is flawed and look for alternative approaches.

Or just keep hammering away with the same question until you get an answer.

"What's 2+2"? In response, the person explains how addition is. "Okay, thanks for that context, but I don't think we ever actually got to the original question - what's 2+2?" The person tells you a story about something cute their kid did when learning addition. "Again, I think we're getting off track - can you please tell me what 2+2 is?"

If they continue long enough, you need to start cutting them off or addressing the issue more directly.

"I've asked four times what 2+2 is, and you've told me several stories about addition but haven't answered the question. Is there some reason you're not able to tell me what 2+2 is?"

Repeat until you either get an answer to the question or an explanation of why the person you're asking can't answer the question.

Unfortunately it's not always socially appropriate to do this, no matter how annoying the other person is being.

It's a workplace situation, and I think it's appropriate to say:

"I've asked four times what 2+2 is, and you've told me several stories about addition but haven't answered the question. Is there some reason you're not able to tell me what 2+2 is?"

In a party, perhaps not.

I've often phrased it as:

"I've asked four times what 2+2 is, and I still don't have an answer to that question. I'm afraid I cannot proceed with X until I know the answer to that question."

Often, though, I've found that simply putting the burden on the other party unblocks them. It shifts their mindset from "I need to answer a question" (which they think they did) to "I need to solve this problem" (which they realize they haven't).

"We need X. Can you sort it out?"

It's absolutely appropriate in the workplace. I'm not going to be mean or snide, but if I'm asking you a reasonable question and you're not answering it, I'm going to be increasingly direct. If I need information from you to do my job, and you're withholding it from me, then you're the one acting inappropriately.

> but if I'm asking you a reasonable question and you're not answering it, I'm going to be increasingly direct.

And herein lies the flaw in your approach. It's reasonable to be annoyed that you're not getting the answer, but it doesn't mean your approach is helping you get there. It's the equivalent of "If someone doesn't understand me, I'm going to shout even louder" or "I'm going to use the same words, but speak even slower".

There's no good reason to think that more directness is more effective.

Would be interesting to see an example.

I’ve been on the receiving end of people who want their question asked exactly as worded, cross-examination style, and it is not fun. I wonder if it is that?

If the other person doesn’t answer how you expected, then expect that, persist, be kind and be calm. Assume the best intents.

They might actually be saying dumb things to help themselves make sense.

Here might be an example:

You: Why is the test suite taking 30 minutes now?

Them: Did you run it last night?

(Because they know something about the system state last night and want to check if the implied unhappiness about the test run length might be due to that)

It's never a cross examination or contentious from my end.

One recent edited example:

My question: "I'm trying to investigate why a request is failing, I found it in aws, the logs for [service] contain a stack trace up to where the [microservice] request is made, logs are very sparse. Is there a way to get [microservice] stack trace?" [I included links to logs and relevant info]

His response is "Do you want a stack trace on every log? I assume dumping a stack trace is somewhat expensive (though I don't actually know if this is the case) so I would be hesitant to attach one to every log entry"

Did I ask to attach a stack trace to every log? I guided him through the original ask and did receive some help. If this happened one time it wouldn't register, but his initial response here was very typical, something I got used to.

Wanted to add for context, this question wasn't directed to him specifically, was posted in a general channel. I don't want to sound paranoid but based on his pattern of responses it seemed like this type of immediate response in a public channel was intended to influence other's perspectives. I'm not into the office politics games but I am aware that people play them.

Is this pattern of responses from him, the same to everyone, or just to you?

If it's the former, it's probably just them and not office politics.

Their answer sounds fine to me.

Stack trace usually means a full stack trace. I've rarely seen one in production - it's usually for unhandled errors. Usually it'll be a one line log which will point you to the point in code where it's erroring out.

Sounds like you just want the logs for the [microservice] for a particular failing request, and not the stack trace?

It'd be bad communication on both sides, here.

I'm genuinely surprised that a question about a particular failed request could be interpreted as a request to start logging stack traces for all requests. One reason for the surprise is I also believe it would be unreasonable to log the stack trace for every request.

I always try to give people the benefit of the doubt, if my interpretation of something seems unreasonable I like to make sure there's not a more generous interpretation, and give the benefit of the doubt when possible.

Again it's about a pattern over time, not just one instance. I realize I'm consistently not being given the benefit of doubt so I work on my communication. It continues and I start to wonder if it's intentional. To answer your question in the other thread, it seems similar for some but not others.

I think some people form an initial impression of others and that impacts the communication going forward, probably not always intentional. I think also some people try to diminish others through public communication. I don't know if that is what I was experiencing but it could be the case, something to be aware of.

From that example. My take:

You explained clearly and respectfully with the background info what you need.

They came back with a question. An odd question. I suspect:

* They are not experienced

* They have been “punished” before because someone asked for “X, and common sense implies X,Y” but the requestor wanted “X,Z”. So they ask dumb questions to be sure.

* Not enough coffee, and realtime conversation they didn’t parse what you said properly.

I would take the question with a sense of calm and not worry. It is a good think they are asking questions. Encourage dumb questions. 1% of the time they are smart questions.

As a senior dev it could be your time to shine with some mentoring:

“It would be fantastic to have a stack trace on every log, but I suspect this would cause performance problems and increase our log storage costs. It is sufficient to only have stack traces when an exception occurs”

I guess you said something like this at the time.

By the way stack trace logs where there are no exceptions are something I have done, but not every log.

Aside: A stack trace for every log almost sounds like a cool startup idea or monitoring product differentiator, as long as the UX is good and it doesn’t add noise.

They are experienced, we were equals, maybe I'm just under him, maybe that was what we was trying to assert.

Again this was an observed pattern, not just one time.

>it's not reasonable to expect all employees to understand how effective communications works

By chance did you mean "it's not unreasonable" here?

Nope. It's not reasonable to expect all (or even most) employees to understand how effective communications works. Some people happen to be good at it, but those are a minority. For the rest, it's a skill one has to learn, and most employees will not learn it. And even if they do, it takes years of practice to become really good at it.

I mean, you could mandate everyone take courses on it, but the reality is that most senior leadership have poor communication skills and don't want to spend time on it.

Edit: To clarify: What I mean is you'll get further understanding and acknowledging that most communications is poor, and adapt to that than to expect people to communicate well. You may have spent years honing your technical skills, but most employees have spent approximately no time honing their communications skills.

Curious what your book recommendations would be?

See this comment: https://news.ycombinator.com/item?id=33658571