Engineering Mantras

Like everyone else, I have a list of favorite quotes that have influenced me or that I have found especially compelling. In the technical world, these sometimes become mantras, guidance, or even best practices.

Briefly, here are some of my favorites.

A prototype is worth a thousand meetings.

This one is often credited to Mark Davidson, the VP of Design at Twitter. Especially given the prevalence of meetings in modern office culture, I especially like this quote as it really highlights the importance of actually building things, and the opportunity cost of a meeting-heavy schedule.

Commit early and commit often.

This one is fairly straight forward and common best practice for using a VCS (e.g., git). Especially with modern systems like git, there really isn't any excuse for not being able to restore code to a specific state.

Pushed or it didn't happen.

A play on 'pics or it didn't happen', this doesn't mean pushed to production, but rather that the development branch has been pushed to the main repository (i.e., it's not only on the developer's laptop).

If code exists only on one team member's computer, then as far as everyone else is concerned it doesn't exist at all.

If it only works for you, it doesn't work.

The response "it works on my computer" should be a ban-able offense, in my opinion. I'm exaggerating, but only slightly.

If this shit was easy, everyone would already be doing it.

This one is from my old boss, Matt Ettus. If we ever groaned about how difficult something would be, this was his first response. And he was (usually) right ;)

If you can't explain it simply, you don't understand it well enough.

This is a quote from Einstein, and I've always found it to be a great barometer for how well some aspect of a design is understood.

Use the best tool for the job.

Dogma should never trump reason - especially when it comes to choosing which tool to use to solve a problem.

If it's not documented, then it's not done.

The key idea, here, is that documentation and code aren't two separate deliverables. They cannot be made orthogonal to each other, and one isn't complete without the other.

Premature optimization is the root of all evil.

This is actually a quote from the seminal book The Art of Computer Programming by Donald Knuth. It can be easy to fall down a rabbit of hole of trying to optimize code before it's complete or even operational, and this almost always complicates the rest of the project.

Try to solve problems that haven't already been solved.

This one seems obvious, but technical teams try to solve solved problems all the time. Commonly known as Not Invented Here (NIH), this is when a team decides to re-implement something that already has a good solution simply because that solution is third-party.

Open source has been one of the strongest tools to get people to stop re-inventing the wheel, because chances are there are a bunch of open-source wheels already out there. If a problem has already been solved, it's unlikely that you are adding value by solving it again.

Don't be clever, be smart.

Or, put differently, clever solutions are not always maintainable solutions. If code works, but it's so convoluted that no one but the author can understand it, then it isn't smartly written and it will, eventually, have to be rewritten.

Don't bike-shed.

The term bike-shedding is used to describe Parkinson's Law of Triviality. I recommend reading the Wiki article, but the summary is that teams will often fall into the trap of giving disproportionate weight to trivial issues because the knowledge barrier to having an opinion is so low.

For example, if you have a group of people designing a nuclear power plant, only a few people with the requisite knowledge will debate the power plant, but everyone on the team will have an opinion about how to design the bike shed. Hence, bike-shedding.

Ben Hilburn

Ben Hilburn

bits, nibbles, bytes, and words
D.C. Metro Area