I could quote this entire article by Dan North:
It takes daily resolve and good habits. It takes effort and deliberate practice to train yourself to ‘unsee’ the general case; to not reach for a library first ‘because it is only adding a single dependency’; to not prematurely abstract or DRY code because reasons; to not over-invest in a component because we have blanket coding standards with arbitrary rules like percentage of test coverage; to go back and stabilise that component you sketched to see if it would work, and it did; to excise that component you sketched that did not work out.
Building software this way is the perfect balance of freedom and discipline. As the author mentions it’s a matter of taste and experience and extremely hard to learn in any other way than by doing it.
BSSN (Best and Simple and Now) is the answer to “you should not build garbage” and “you should not overcomplicate your code prematurely” either.
Sketching in particular is a quality that should also apply to code (and will be impossible to explain to anybody who does not already get it).
Sketching does not mean hacking! I know many more engineers who are good at ‘proper’ code than those who can sketch well. Sketching is about providing just enough quality that you can sustain a direction, knowing you can go back and fill in the blanks later on (or throw away the sketch with minimal investment lost). Hacked code quickly becomes unmanageable. Well-sketched code is just a lighter-weight version of the real thing.
