Hacker News Reader

Comment by inanutshellus | Hacker News Reader

I've moved away from this.

Advice is supposed to convey information simply and efficiently, and "asterisks" for every edge case just muddle it. Now my pet peeve has moved to folk wheedling about 100% accuracy in advice. ;-)

e.g.

Great advice:

    "Never run a red light"

Technically-correct-but-will-never-be-read advice:

    "Don't run a red light, unless you're on a bicycle and you know that the intersesction you're at is on a weighted sensor that you're not going to set off. In which case, check your local laws on how to get through the intersection. Also, this likely applies to motorcycles. But not all motorcycles, so check your motorcycle's weight and cross-reference it to the weight sensors in your intersection (you'll need to contact your municipal engineering corps to get this). Also, one should look up for falling pianos at this point as well, just in case, because I can't say the word 'never'."

View on HN

This is the sort of thing that's great for helping engineers go from junior to mid-level and then dangerous for going from mid to senior. Thinking clearly about exceptions to "rules" is one of the most important skills you can impart.

Don't Repeat Yourself is great advice... but only if you start thinking about all the caveats where over-application leads to architectural disasters.

The GP is largely correct here: If your advice includes "never" or "always", you're probably doing more long-term harm than good.

That's why I have “make sure to justify deviations from” in there.

It's easy enough to make that policy, but you run the risk of making the development process too unwieldy to implement (See: Taligent's Style Guide).

I would hope that most style guides have caveats for deviation (disclaimer: I haven't read a style guide in eons, so I don't know what they generally say, these days).

I'd say that "We should do it this way, but, if you think your way is better, convince me." is a good approach.

Really, I see a lot of problems, caused by corporations' obsession with hiring lots of bad programmers, and trying to force them to be good programmers, by setting up strict boundaries, as opposed to just hiring a few good programmers, in the first place (which, admittedly, has its own issues). This is nothing new. I have seen this since the 1980s.

The really cool thing about software, is its flexibility. I feel that the enormous toolbox at my disposal, along with my experience in using said tools, makes it possible for me to develop some pretty good stuff. If someone tried to force me to do a "lowest common denominator" approach, I don't think the results would be good.

There is still a difference between leaving out special cases to give more succinct advice and going out of your way to repeat the words "never"/"ever" three times to imply the absolute absense of any exceptions.

Yeah. I'm on board for 'never', but by the second 'ever' you lose me.

> Advice is supposed to convey information

> Great advice:

> "Never run a red light"

If conveying information is the goal, then that is crappy advice because it conveys no information. The information you're not conveying is that "running red lights adds significant risk of injury and death for both yourself and others because you cannot easily see cross traffic with enough time to save yourself and them."

This is not only informative about stopping at red lights but also about when it might be ok to go through them without enumerating every grain of sand on the beach.

You could just say "Generally don't run a red light"

Reply on news.ycombinator.com