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
Aristotle talked at great length about the essences of things and the accidens of things. The accidens were aspects of appearance that could change (or simply which could be different) while the essences are aspects which one cannot change without fundamentally changing the thing. For example, the accidens of an acorn is a brown
Industriousness is difficult to describe and harder still to sell. At first blush, it might seem like it'd be easy to sell the simplest way to ensure happiness, wealth, and general success, but long-term thinking is not natural for a great many people. This is why Aesop fables are so significant - they can
Most of us have at least heard of the Grimm Fairy Tales. The Brothers Grimm travelled through Germany compiling folk tales, which they published into an excellent collection of myths (pattern-conveying stories) that convey simple lessons to us at any age.
Today, we'll look at the story of Clever Elsa.
Elsa was a serving girl who
I write about programming patterns quite a bit, but there are many other places where patterns are important. For much of human history, these patterns have been presented in myths and fables, to instruct the young and the less-inquisitive in virtues and mental patterns that best serve and exemplify their society. We in the
If it hasn't happened to you yet, it will:
You're working with library code - say, GNUTLS. You've dug around and installed all the prerequesites, and the libraries are all set up. You're all ready to get to work...
But the documentation doesn't match the headers you have. It turns out that all the documentation matches
malloc(): memory corruption
When you look at an error message like that, what could possibly lead you to believe that, a hundred lines up, you didn't properly initialize a size variable? After all, all we know is that this malloc() operation could not complete because the memory it should be able to touch is corrupted.
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
It's amazing how often programmers forget the simplest rule of programming: 1=1.
This is the principle of logical unity (or modularity - they're largely synonymous).
Unity of Function
If we adhere to the principle of top-down modular design, all our functions should be relatively small. At the bottom of the tree, every function serves one purpose and
One of the key worries I have heard from those ill-informed OOP programmers is that C cannot protect inputs you pass into functions. They use private fields and retrieval functions to ensure that the stored value is protected from unwanted modification.
However, this concern is addressed by C's const keyword.
Taking a const value
There are times