I've alluded previously to a particular brand of laziness that separates a good engineer from the average person. It sounds disparaging at first, but there is an aspect to engineering laziness that is absent from almost every other kind of laziness:
Engineering laziness encourages progress
How can laziness encourage progress? When we think of laziness, we
The hardest interview I ever had: someone told me to go up to a whiteboard and solve a programming problem, in code, optimally, on the first try.
It's a basic fact of our field that we iterate toward the final product. Not unlike a sculptor bringing the David out of a piece of marble, we
How many programmers whine that C is dangerous because of memory leaks? How many programmers rely on IDEs because they can't keep track of how many layers of brackets they're using?
All of this stress is easily defeated with a little bit of Eastern Philosophy.
In the binary unifying force of the cosmos, there are
Programmers are not unlike Dory from Finding Nemo, in that we have a limited memory. It seems like every time we sit down to code, and we are randomly struck by a lightning bolt of inspiration, we immediately lose it when we notice something shiny.
That's an extreme example, sure, but programmers do have a
Fun fact: more than a few code conventions are inspired by the fact that everyone's computer is set up differently.
When you commit to a set of documentation, you are telling all the users how your code will work and how they should use it. This has a trickle-down effect, such that any changes to the documented features can destroy entire suites of programs.
Violation of the Rule
Suppose you provide documentation for an early-release form
Generally, I don't much care for IDEs. In my experience, IDEs add increasingly specific features to maintain their relevance, resulting in bloated software which takes too many resources to accomplish a relatively simple task.
However, as functions get more complex, it becomes increasingly difficult to make your code match the original prototypes. This is where
Ask any programmer what the most irritating part of programming is, and they'll either say debugging or documentation. Admittedly, I am one of the rare exceptions (I dislike the coding part most, because it's less about solving a problem than it is translating the solution), but I have a standard which removes the most