Hacker News Reader

Comment by silisili | Hacker News Reader

Yeah, no. I've literally read hundreds of RFCs, thousands of man pages, and who knows how much else. If I spent time writing down everything I know, I'd never get anything else done. And it's not like I'm some supergenius, all of this info is available freely on the internet. But that doesn't stop folks from asking about DNS, TCP, and other well documented things.

Many times domain knowledge is just a person who has the answers somewhat fresh in memory so you don't have to go trudging. But writing those things down each time is both futile and redundant.

View on HN

RFC's and man pages are written down already. When they say "write things down" it's not about duplicating that effort, though you might make an FAQ that links to them.

Point 1 specifically says to write things down every time someone asks you a question. Taking DNS as an example, 1034 1035/4034 4035, among some others, I don't see how that's helpful even if I make a linking FAQ. My notes would say 'DNS question, read these 4 RFCs' over and over and over.

You could document what common issues you have or any tricky situation you dealt with. You don’t need to say “dns stands for domain na…” but knowing the why behind some of your decisions is super useful.

The article is not a bible and there is something called judgement. If you are getting asked DNS questions all the time, this may be indicator of a wider knowledge issue and may be you can suggest conducting an internal session on DNS. Apply common sense.

I think you’re interpreting the advice way too literally. The author probably didn’t mean for you to document the answer to every single question you get, but questions you get about the system or domain you’re working, and where the answer isn’t readily available anywhere else.

I don't disagree with you. If the question was about design decisions I'd made, I'd be in full agreement. But the article quite literally says 'every time.' You could rightly say I'm being pedantic, but if you're going to write life advice, it should be quite specific IMO. I'm not trying to be a jerk, but rightly (also IMO) pointing out flaws with the wording and tone.

> Every time someone asks you a question, they are highlighting a gap in the documentation.

This is a sensible statement assuming that the question is about the domain or system you’re an expert in. Not “what time is it” or anything like that.

> Take the chance to write the answer down

Perhaps the author should have qualified this advise with “take the chance to consider”, but I think the advise stands well on its own and I understand to apply common sense to it.

This is so bizarre, what questions are you getting that require you to refer to the rfc - something with such detail that it covers things like how many bytes are allocated to which field.

If you're doing something so niche like some kind of network analysis tool, then your colleagues should already have the rfcs as a very basic reference.

Otherwise, if someone is asking very practical questions like, how to add a cname or something, then rfcs are way too theoretical.

No offense, but this is a typical thought, and one that shows that you've no idea the hundreds of corner cases that trap you.

There's a reason 'its always DNS' is a meme.

A simple example. Someone makes a new domain name, cnames it to their previous domain for web, and adds an MX record for emails. Why doesn't it work?

I'm sure you can Google the answer. But this stuff comes up -all- the time

If people trip up with certain things all the time, then is the technology itself suited for the problems that people need to solve?

Because at that point, it feels like people are serving the technology and its many quirks, not the other way around.

But regardless of that thought, i think both your words and those of the parent comment have merit - different levels of detail fit into different pieces of text (RFCs, vs a "How To" blog post), which fit different purposes. The quality of the information in either, however, still remains in question (given that some popular implementations of technologies, don't always even respect RFCs fully).

IT desk pro tip:

1) Have you checked DNS? It's usually a problem with DNS.

2. Have you tried turning it off and on again?

3) Is the power cable plugged in the socket?

4) Sigh, I'll travel up to look at it.

Done! :)

Yep, my indespensibleness is that I have all this mostly useness knowledge in my head, and if you show me the problem, I can usually get something useful out of my brain to get somewhere quickly. And if not, I can skim the code and get an idea; and if not, I can sort of operate a debugger.

What do you want me to write down to help someone else do that? Read all the things, just in case!

I think the article is not about general technical knowledge or even knowledge about specific technology used at your company but more about e.g. why a certain way to model your domain makes sense or how an unusual system design will pay off because of future plan X discussed with group of people Y in meeting Z - and here is the architecture diagram for it.

> Yeah, no. I've literally read hundreds of RFCs, thousands of man pages

Well, that didn't take more than a single line: "please remember to check relevant RFCs and man pages for additional information. This system depends on DNS for round robin load balancing (etc)" :)

But it also says .."in a document, bug, code comment—wherever..."

You don't have to make a big effort of it. Paste the question and answers from the emails into a text file. Make it into a FAQ email to share or paste it into a comment block the next time you mess with that code.

Reply on news.ycombinator.com