Hacker News Reader

Comment by dfxm12 | Hacker News Reader

The flip side of this is: seek documentation, not people.

I spend a lot of time writing documentation. I think it is well written. Many employees do as well. However, some people come to me with questions already answered by the documentation. They aren't interested learning anything, they only want to make their problem into my problem, or they want me to do their job for them. I'm happy to take extra time to guide new employees through something or discuss edge-cases, but with all my day to day tasks, I am simply not given time to spend with senior employees on things answered by the docs.

View on HN

> However, some people come to me with questions already answered by the documentation. They aren't interested learning anything,

Not entirely a counter, but i think it's worth remembering that because documentation is difficult - a lot of people have been trained to ignore documentation by way of documentation not being the answer in far too many cases.

I'm sure there are many people whose behavior is driven by the reasons you give, though.

It is unprofessional for someone to just assume their co-worker has done a bad job, no?

Not if every other coworker they've ever had has done a bad job at this particular thing, no. That's just rational

I think documentation feels like a bit of a sink, as written documentation starts degrading (in terms of being up-to-date) as soon as it gets published, and it gets extremely frustrating going through docs and not feeling like you can "trust" what you're reading

It depends on whether you have better people skills or better reading comprehension. I use whatever source gets me the answer fastest as I am skilled in both. That's not true for everyone, but being able to use a decision tree where you have both options is a big part of being a 10x programmer IMHO.

Is your PM/BA/Coworker so overwhelmed they can't think straight (Mind your P's & Q's)? -> Go look at the docs.

Can you politely insert yourself into a conversation with a coworker given their bandwidth and their ability to understand functional and technical requirements and quickly explain what is required? -> Schedule a short meeting.

The problem is that often people come to you and just want a solution to their particular problem. Then you explain but forget or leave out some details because you assume they know those. If you're too verbose, they might just have read the documentation.

In fact the best thing to do is to point them to the correct paragraph in the correct document.

It can be hard to find the thing you're looking for in documentation, especially if you're not too familiar with the piece of software you are currently looking at. Saving your coworkers a couple of hours by spending ten minutes of your time can be a good trade - even though it's annoying for you.

As I've said, the docs work for many people. Even in a situation where something is hard for someone, I disagree. It reinforces learned helplessness. Yes, work sometimes will be hard, but things get easier as you gain experience. To be fair to myself, the company cares if I achieve my goals and, importantly, does not give me extra time or extra credit to achieve other people's goals. Even with this in mind, as I've already said, I understand the importance of going the extra mile in some cases (to my own detriment). If another employee does not have the initiative or wherewithal to go through the normal channels and is only interested in skipping the line, this is not a good trade for me or our company.

If people are still coming up with you for questions that the docs answer, then the docs are not discoverable. Nobody is going to sit through hours of docs to find that one small thing they are interested in knowing the answer to _right now_.

LLMs can solve this to some extend now tbh.

As I said, people doing this aren't interested in looking for an answer. They're interested in making their problem someone else's problem. An AI agent doesn't solve this.

Insofar as "the problem" is sifting through pages and pages of documentation to find the relevant information for an answer, I think that current-day LLMs are actually quite capable at this.

Before needing an LLM for it, they might want to ensure their doc system is using a search system that actually works. There's too many doc-focused templates / apps that have the worst search possible.

They expect you to teach them in a way that's immediately understandable to them, and if they don't get it immediately, it's your fault. They get offended if you tell them a single thing they already know, but also blame you if you fail to tell them anything that they don't already know but need to. They'll complain about a lack of documentation, and then won't read it when it's there, and if they do, they complain that it's too hard to understand.

I've had a coworker ask me how to do something in a general way, and tell me "please don't tell me 'it depends on the context'. I just want to do my job and go home." Of course, it did depend on the context. Everything does. This is a senior software engineer with 16 years of experience.

Similarly: monitoring dashboards

You can find the exporters like we did, scrape away. Stop trying to get me to look at it with you

Reply on news.ycombinator.com