3 ms·

> > 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

by scubbo 1y ago

> > 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)

about3fitty 1y ago
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.
- scubbo 1y ago
  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

by scubbo 1y ago

about3fitty 1y ago

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.

scubbo 1y ago
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