Hacker News Reader

Comment by beaconstudios | Hacker News Reader

I tend to think that almost every time someone is doing something you don't understand or don't like, you're better off understanding the reason for the behaviour than trying to quash it. Even if you desperately want it to stop, they're clearly doing the thing as a means to address something so if you want to stop them using the current solution you should have a better solution to hand or the problem will once again be unaddressed and the behaviour will resume. You can't offer an alternative unless you know the cause in the first place. This approach makes sense for children (presumably above a certain age) and adults alike.

View on HN

Seems like a manifestation of Chesterton's Fence! https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence

This is also, as it turns out, one of the most pertinent things a developer should be considering at all times. Sometimes we may get a bit too refactor-happy, not seeing the use behind a certain fix, a line of code or a strange function. Our first instinct isn't to understand it, but to tear it down, gleefully assuming that it's useless.

This reminds me of the infamous comment block:

// // Dear maintainer: //

// Once you are done trying to 'optimize' this routine,

// and have realized what a terrible mistake that was,

// please increment the following counter as a warning

// to the next guy

// total_hours_wasted_here = 42

Edit: to improve legibility

Indent 4 spaces to format as a code block instead of flowing together or separating with blank lines as paragraphs:

    // // Dear maintainer: //
    // Once you are done trying to 'optimize' this routine,
    // and have realized what a terrible mistake that was,
    // please increment the following counter as a warning
    // to the next guy
    // total_hours_wasted_here = 42

Note that on narrow windows or mobile screens this doesn't wrap and needs to scroll sideways for long lines (though these are wrapped to 60 characters), which is annoying

(Increments time wasted counter)

If a viewport cannot handle gracefully lines of 80 characters, it is not the fault of the person writing the 80-character lines. If a code block is the right answer, I would hope that people use it, rather than attempt a workaround just to avoid a flood of gripes from people on mobile who don't want to scroll right. Fix your scrolling issue by fixing your scrolling issue, not by trying to retrain everyone that posts on HN to cater to mobile viewers, in lieu of just marking the text that requires differentiation of newlines from other whitespace.

Also, you only need to indent 2 spaces:

  Everyone- use code blocks whenever you need them.
  Mobile users- don't complain about code blocks.

The viewport can handle lines of 80 characters. The problem is that HN indents so far and even truncates on the right so you’re working with like 40 chars visible.

The trouble comes when the others working on your code are crazy enough that that strange code often is useless, so you have to spend the time trying to work out whether it's tear-out-worthy.

A sign of maturity is to a) recognize when code is crazy, and b) document why it is so in a comment.

Here let me fix that for you: "document why it is so in an executable test".

It's not always possible (or even advisable) to document with a test; to take two trivial examples from recent memory, one was a wrapping bug in IE 11 and the other was a typing issue with TypeScript. These issues required comments, not tests. (Granted, for the IE11 bug the ideal test harness would include a Win/IE virtual machine in a known state along with a good robot control and the ability to check screen geometry, but as of 2019 that's science fiction)

Your second example is a great example of how sometimes it's just not worth it. You're probably right that it makes sense to just write a comment and move along (after you've replicated the bug and filed an issue against the TypeScript compiler). Eventually it will get fixed, your team will upgrade their system, and you can remove the workaround.

I'd argue the first example illustrates my point quite well (but forgive me if this gets too ivory tower). It would seem highly unlikely that the wrapping bug is intimately coupled with whatever else the component is doing. It will likely come up again in some other situation, in this project or another. After all, some users will be on this browser forever.

All this suggests we would like to factor it out, in the name of the single responsibility principle and don't repeat yourself. And the extracted component should then be thoroughly tested to it's own why. That component's why, in particular, is to work around the browser bug, so a test specification that describes precisely which versions of Windows and IE are required to be worked around is actually exactly what you want.

As to good robot control and screen geometry, I don't think that's really science fiction anymore, unless your requirements are more exacting than mine.

Sometimes possible, but not always.

An executable test is good for documenting what a piece of code should do, but not always entirely sufficient for documenting why.

Though I agree that it's not always possible, I would contest your second point, at least for the majority of testing effort.

Sure, a unit test might just document what code is doing, because that's really the only why. But most testing effort should go into describing the why more carefully, which must be done at a higher level, as close as possible to how a user will interact with the thing.

Writing tests at the user's level and not getting bogged down in minutia requires careful factoring of the what and why. The what changes frequently, so if most of your tests are overly focused on the what, you will constantly need to update them as the code changes. The why changes much more slowly, so if your tests are written to exercise the why rather than the how, they will be resilient to changes in the implementation.

Of course, the what has to be somewhere, and when it changes there will need to be corresponding test updates, but these shouldn't require updating each individual test. The what can be kept cleanly factored out into helpers, leaving the why to remain as the essence of each test.

Exactly, and in the pathological case it ends up documenting the why incorrectly and the code is still wrong.

Yes, but this is hardly an argument against using comments.

There will always be a pathological case. The question is what approach will increase your chances of success, what's least likely to lead to problems, what's the cost-risk-benefit tradeoff etc.

Comments detailing the intent of a non-obvious function are valuable for maintainers wanting to figure out what's happening in the code. They are written in human-oriented business-oriented language, so they don't take effort to read. The intent of the code should not change that often. If they diverge from the code, the effort of changing them should be small enough to be worth it. Ideally they should be treated as important and if they are wrong it should be picked up in the code-review.

Comments detailing just the description of what a function does, by contrast, are not valuable, since that information can be deduced from the code itself. Every time the function changes, the comment will change. Reading them is as much effort as reading the code, so if they diverge it won't be picked up as easily.

There are always exceptions to these kinds of guidelines, of course, but this at least gives motivation for why I think comments should be used in this way.

Proper testing procedures will catch it, though.

AKA "Most regulations are written in blood."

Choose curiosity and patience over judgement and commands. Such a simple message, and yet in practice it's so easy to fall for the (illusion of?) control, thinking "there's no time for curiosity or patience here."

With a kid kicking and screaming violently at you, that's kinda hard. You are right though. Letting go of the urge to control my older son often helps more than tighten up.

A kicking and screaming kid should be rare though.

Easier said than done in practice, particularly when dealing with smaller children, who either can't articulate the problem, or don't grasp the causal connections. Even more so when the unwanted behavior isn't just "weird", but also self-harming (and very abnormal behavior is often socially self-harming).

Or harming a sibling!

The biggest hurdle seemed to be to regain enough trust to get a chance to discover the reason of the behaviour.

There was a window in the beginning when she still had the kid's trust and could have dug deeper, but if/once you are not a trusted party, understanding the reason because exponentially difficult.

To your point, it applies to everyone. I remember social courses at the uni about how some classes of workers would obfuscate key parts of their jobs to protect themselves from having client/managers get their nose into it.

In that sense getting to understand the core reason might often be the biggest chalenge. A bit like how finding why a bug occurs is more than half of the solution already.

The same is true even for dogs, to some extent. And, to some extent, some people are just born very slightly sadistic or mean and there's no noble underlying reason in the first place.

why would their reason have to be noble? Human motivations can be complex.

They can also be very primally simple, but confused by layers and layers of rationalization and self-justification. And that's more obvious in children, who haven't learned how to rationalize their behavior very convincingly yet. If a child throws a rock at someone's head, they're not going to come up with the same elaborate justifications for that kind of behavior that, say, a political rioter would, even though the underlying motivations are probably the same.

This should be applied to politics as well.

Reply on news.ycombinator.com