Hacker News Reader

Comment by nox101 | Hacker News Reader

> #1 Understand the system: Read the manual, read everything in depth, know the fundamentals, know the road map, understand your tools, and look up the details.

Maybe I'm mis-understand but "Read the manual, read everything in depth" sounds like. Oh, I have bug in my code, first read the entire manual of the library I'm using, all 700 pages, then read 7 books on the library details, now that a month or two has passed, go look at the bug.

I'd be curious if there's a single programmer that follows this advice.

View on HN

This was written in 2004, the year of Google's IPO. Atwood and Spolsky didn't found Stack Overflow until 2008. [0] People knew things as the "Camel book" [1] and generally just knew things.

0. https://stackoverflow.blog/2021/12/14/podcast-400-an-oral-hi...

1. https://www.perl.com/article/extracting-the-list-of-o-reilly...

I think we have a bit different interpretations here.

> read everything in depth

Is not necessarily

> first read the entire manual of the library I'm using, all 700 pages

If I have problem with “git bisect”. I can go only to stackoverflow try several snippets and see what sticks, or I can also go to https://git-scm.com/docs/git-bisect to get a bit deeper knowledge on the topic.

Essentially yes, that's correct. Your mistake is thinking that the outcome of those months of work is being able to kinda-probably fix one single bug. No: the point of all that effort is to truly fix all the bugs of that kind (or as close to "all" as is feasible), and to stop writing them in the first place.

The alternative is paradropping into an unknown system with a weird bug, messing randomly with things you don't understand until the tests turn green, and then submitting a PR and hoping you didn't just make everything even worse. It's never really knowing whether your system actually works or not. While I understand that is sometimes how it goes, doing that regularly is my nightmare.

P.S. if the manual of a library you're using is 700 pages, you're probably using the wrong library.

> if the manual of a library you're using is 700 pages, you're probably using the wrong library.

Statement bordering on papyrophobia. (Seems that is a real phobia)

More like fear of needless complexity and over-broad scope, which is actually rampant in library design.

700 page manual can be produced in several ways.

- Scope of the library is massive

- very peculiar way of writing, with lot of impressively unnecessary description of minute detail, that the reader starts counting not only sheep but also breaths until the ultimate end before finishing a sentence. (I.e. Unnecessarily verbose)

- very extensive docs describing things from various angles including references, topic based how tos and such.

(I agree that the last one is the least likely, but there is always hope)

great strawman, guy that refuses to read documentation

I mean he has a point. Things are incredibly complex now adays, I don't think most people have time to "understand the system."

I would be much more interested in rules that don't start with that... Like "Rules for debugging when you don't have the capacity to fully understand every part of the system."

Bisecting is a great example here. If you are Bisecting, by definition you don't fully understand the system (or you would know which change caused the problem!)

Reply on news.ycombinator.com