Particular Brand of Lazy: What Makes Engineers Unique

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

Patterns – Prototypes and Optimization

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

Patterns: Yin and Yang

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. Yin: Beginnings In the binary unifying force of the cosmos, there are

Patterns: Comment Through History

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

Patterns: The Documentation Contract

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

Patterns: Code Completion using VI

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

Patterns: Document as you go

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