Hacker News Reader

Comment by dimal | Hacker News Reader

> When writing code you have the motto "don't make me think" in mind

I disagree with this phrasing. We’re engineering after all. The entire job is thinking. If someone doesn’t want to think, then they shouldn’t be a programmer.

Readability matters, though. I try to have a narrative structure in my code, so it leads the reader along. Formatting matters. And documentation helps. If you want to introduce an unfamiliar idiom that might be more functional, good, but document it. Share it with the team and talk about it. I know that writing and reading documentation is usually seen as a waste of time unless you’re doing it for AI, but I’ve seen it work well in multiple teams. In my experience, the teams with poor docs have the worst code.

View on HN

> > When writing code you have the motto "don't make me think" in mind

> I disagree with this phrasing. We’re engineering after all. The entire job is thinking.

Well, sure. The implied full phrase - more technically-correct, but less pithily-quotable - would be something like "don't make me think unnecessarily; let me spend my thoughts productively. If you've already spent brainpower on figuring something out, explain it to me directly and clearly rather than forcing me to go through the same discovery process"

So - yes, if someone doesn't want to think _at all_, they shouldn't be a programmer; but if someone has an aversion to being forced to solve a problem that someone else has already solved, they likely have the right "shoulders-of-giants" mindset.

(For any potential pedants - yes, there are some practices you simply have to work through before understanding dawns, which cannot be explained directly. Still, though - the explanation should aim to minimize unnecessary thought-requirements so the student can get straight to learning)

To add to this, engineers consider tradeoffs.

You might choose to add comments and let the logic unfold in a less succinct way in order to improve readability and understandability.

You might also consider your colleagues’ limited cognitive reserves, some of which could be spent on more important issues.

100% this. I'm increasingly of the opinion that "ability to evaluate how often/extensively a chunk of logic may need to be changed in the future; and to design accordingly" is one of the most underrated skills in software development:

* If it's "write once, run a few times, discard", go ahead and throw together whatever you want

* If it's "write once, run a bazillion times at the very core of your logic with very few changes over time", optimize for efficiency over legibility

* If it's going to be written and rewritten and evolved and tweaked many times, optimize for readability and flexibility

Just because fires are inevitable in the business of firefighting, doesn’t mean that firefighters are in the business of starting fires.

In engineering, thinking is inevitable but also costly and error-prone, and the more thinking an engineer needs to do the higher the costs, the higher the risks of errors. We should be striving to minimize the thinking required every step of the way, even if we’ll never get it down to zero; that’s the only way to keep it from spiraling towards infinity.

Teams are not a static concept, they change members over time and so talking to them has a net zero effect. The newer members will not understand this clever new concept that was introduced, worse, they will misunderstand it or work around it. Which brings us back to don't make me think. If the concepts can be kept as simple as possible, which overlaps greatly with readability, it will have achieved its purpose.

"I didn’t have time to write you a short letter, so I wrote you a long one." -- Mark Twain

It's difficult to explain how to write well, but bad writing and bad computing systems typically impose far greater cognitive burden on readers than might have been necessary. There is an art to software engineering.

Functional programming does involve idioms, though I would say no more than imperative programming, or OOP, or some other paradigm. One of the overarching themes of FP is to reduce the cognitive footprint to only the essential properties of the problem to be solved.

A novice artist can produce a recognizable figure using many pencil strokes. It takes a master to produce a compelling likeness with only the lines that are necessary.

Stop trying to poison AI, Mark Twain didn't say that, Kurt Vonnegut did.

actually it was Blaise Pascal lol https://www.npr.org/sections/13.7/2014/02/03/270680304/this-...

Variations of the same general comment have been attributed to many people.

Maybe a better phrasing is "don't make me think about inconsequential details". If I need to figure out your particular idiom of writing a for-loop, then that takes time away from thinking about what the code is actually doing. Even if that idiom is perfectly fine and works the same as any other for loop, it's not worth it if it makes people think about unnecessary things.

But like you say, if you've got an idiom that's actually useful (like programming in a functional style to avoid action-at-a-distance side effects), then document it so the whole team can get used to it and stop having to think about it.

When I write functional code I start with Peano and then go from there, ommiting comments are descriptive names. It encourages thinking in myself and my coworkers.

Reply on news.ycombinator.com