This was originally posted on my blog, here: 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.
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 meetings can inflict on timelines & productivity.
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.
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.
The response "it works on my computer" should be a ban-able offense, in my opinion. I'm exaggerating, but only slightly.
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
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.
Dogma should never trump reason - especially when it comes to choosing which tool to use to solve a problem.
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.
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.
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.
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.
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.
What are your favorite slogans or mantras for technical teams? Please share!