Hacker News Reader

Comment by mannykannot | Hacker News Reader

I like this a lot. While those commenters who say it is too advanced for novices have a point, I feel these are still issues worth thinking about - and coming back to - as they learn.

The one exception is “Bad code gives you feedback, perfect code doesn’t. Err on the side of writing bad code.” My experience with bad code is that it does not tell me much; instead, it presents inscrutable and baffling mysteries. From the caveats and examples, I think the author is trying to say something rather different; something like “don’t obsess over completeness” or other concepts of ideal software - especially, I might add, dogmatic concepts of this nature.

View on HN

The Bad Code advice is for people who have the tendency for perfectionism (apparently like the author 15y ago).

My advice to me: write simple, dumb, repetitive code, but make an effort to be consistent.

Consistent, dumb code is really easy to visually parse. The repetitions slide into the background and the differences stick out. The more code there is, the easier to see what goes together (data aggregates/structures), what the overall flow should be (control, conditionals, order etc.). Then it's easier to factor things out or how to express more clearly what the code does.

But again, consistency is key. The code can be "bad", but it's very beneficial to do simple edits like renaming and reordering of things, grouping them under succinct comments so the structure stays clear.

Younger me would do the opposite: inconsistent code that is complex. I think its impatience that gets in the way, rushing to build abstractions and factoring out things way too early or trying out competing ways to express the same kinds of things (playing around with code).

Every programmer has their own tendencies and their own journey, so they need to hear different advice, in order to ignore it for now, but to have an AHA moment at some point when they realize why the advice was given.

I think this could have been phrased as, err on the side of shipping faster.

i.e. in most cases the cost of bugs is so low that the benefits of a faster feedback loop greatly outweigh the benefits of a more rigorous development process.

(On top of that, the number of defects asymptotically approaches zero with greater effort invested, i.e. diminishing returns.)

Agreed. "Perfect" code doesn't exist, but good code is written with the understanding that bugs happen, and exposes information at the right level for people to get the feedback they need, when they need it.

I think you got the wrong idea from that sentence; the author is talking more about the feedback you get from your end-users and/or customers, rather than development feedback a la debug info.

No I actually do mean the feedback you get as a developer when you realize which “bad” decisions actually end up being tech debt and which were totally fine and just saved time

Reply on news.ycombinator.com