I am not good with words. I feel tempted to say most people aren’t. But as an engineer and because I know Akin’s first law of spacecraft design:

Engineering is done with numbers. Analysis without numbers is only an opinion. 1st of Akin's Laws of Spacecraft Design

I try not to assume things without solid data and facts to back it up.

And, in case you still don’t feel comfortable enough to affirm something, Akin has got another law for it:

Not having all the information you need is never a satisfactory excuse for not starting the analysis. 9th of Akin's Laws of Spacecraft Design

Go after the information you need in order to take the right decisions, after all, your efforts to make something faster and better will be futile if you didn’t know what your starting point was. Always:

Measure. Don't tune for speed until you've measured, and even then don't unless one part of the code overwhelms the rest. Rob Pike's 2nd Law of Programming

After all:

One accurate measurement is worth a thousand expert opinions. Grace Hopper

And

You can't manage what you can't measure. Peter Drucker

Since we’ve just mentioned expert opinions I also think it’s worth mentioning that we should always pay attention to appeal to authority fallacies.

The fact that an analysis appears in print has no relationship to the likelihood of its being correct. 17th of Akin's Laws of Spacecraft Design

And never, ever, forget why you’re going after data. You need to be able to know how to extract meaningful information from your measurements, because:

The purpose of computing is insight, not numbers. Richard Hamming

Once you have measured, make sure you follow the two rules of optimization:

Rule 1: Don't do it. Rule 2 (for experts only): Don't do it yet. Michael A. Jackson

As Donald Knuth once said:

Premature optimisation is the root of all evil. Donald Knuth

This also reminds me of the Pareto Principle, which states that:

For many events, roughly 80% of the effects come from 20% of the causes Vilfredo Pareto

Which is completely true when it comes to computer science, especially due to the fact that:

The greatest performance improvement of all is when a system goes from not-working to working. John Ousterhout

In computing:

More sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason - including blind stupidity. William A. Wulf

Do one thing at a time, that’s what TDD is all about and it works really well because:

You can't make it better until you make it work. McBryan's Law

Usually, especially when it comes to young products, you don’t have problems big enough to worry about scale. In those cases, remember Rob Pike:

Fancy algorithms are slow when n is small, and n is usually small. Rob Pike's 5th Law of Programming

Just focus on building things right. Be elegant, since:

The key to performance is elegance, not battalions of special cases. Jon Bentley and Doug McIlroy

And:

The cleaner and nicer the program, the faster it’s going to run. And if it doesn’t, it’ll be easy to make it fast. Joshua Bloch
If it doesn’t work, it doesn’t matter how fast it doesn’t work. Mich Ravera
A program that produces incorrect results twice as fast is infinitely slower. John Osterhout
Correctness is clearly the prime quality. If a system does not do what it is supposed to do, then everything else about it matters little. Bertrand Meyer

And don’t even think about mentioning how important it is to have automated tests or lots of clever scripts if they do not add value to what you are building.

Automating chaos just gives faster chaos. Mark Fewster

You need to know what adds value to what you are building and what does not. Productivity is not about keeping yourself busy.

There is nothing more unproductive than to build something efficiently that should not have been built at all. Milt Bryce

And it doesn’t matter how well you know and applies agile principles and methodologies.

Great execution towards a terrible idea will get you nowhere. Sam Altman

What you really should do is clearly reflected in YCombinator’s motto:

Make something people want Paul Graham

Computer programs do not exist to please us engineers.

The most important property of a program is whether it accomplishes the intention of its user. C.A.R Hoare

Be aware of your goal as an engineer.

Any run-of-the-mill engineer can design something which is elegant. A good engineer designs systems to be efficient. A great engineer designs them to be effective. 36th of Akin's Laws of Spacecraft Design

It doesn’t matter how clean your code is or how elegant your solutions are if it does not solve anyone’s problem.

Any program is only as good as it is useful. Linus Torvalds

But solving someone’s problem isn’t enough.

In programming, the hard part isn't solving problems, but deciding what problems to solve. Paul Graham

Gordon Glegg knows this really well:

Sometimes the problem is to discover what the problem is. Gordon Glegg

And maybe someone has already discovered what the problem is, but their timing was not right or their team was not ready. In any case, you’ve got lessons to learn from them.

Learn from the mistakes of others. You can't live long enough to make them all yourself. Eleanor Roosevelt

You don’t need need to worry so much about being the first one to do something. You also don’t need to be that disruptive. Most businesses are not and they still succeed.

A good way to have good ideas is by being unoriginal. Bram Cohen
People think that computer science is the art of geniuses but the actual reality is the opposite, just many people doing things that build on each other, like a wall of mini stones. Donald Knuth

Please:

Don't reinvent the wheel, just realign it. Anthony J. D'Angelo

Software only exists to either decrease costs, increase revenue, or both. Like it or not:

Software solves business problems. Patrick Mckenzie

In the end:

It is not about bits, bytes and protocols, but profits, losses and margins. Lou Gerstner

It sounds sad, but as Patrick McKenzie and Douglas McIlroy noticed:

You’re in the business of unemploying people. Patrick McKenzie
As a programmer, it is your job to put yourself out of business. What you do today can be automated tomorrow. Doug McIlroy

And then, only then, when you know which problem you’re going to solve it’s time to decide how it is going to be solved. In order to do that, we all know that we must have specs, but in reality:

Writing specs is like flossing: everybody agrees that it's a good thing, but nobody does it. Joel Spolsky

All of us need to be aware that:

Without requirements or design, programming is the art of adding bugs to an empty text file. Louis Srygley

And even if we do write specs, most of the time we’re trying to hit a moving target.

Walking on water and developing software from a specification are easy if both are frozen. Edward V. Berard
In software, we rarely have meaningful requirements. Even if we do, the only measure of success that matters is whether our solution solves the customer’s shifting idea of what their problem is. Jeff Atwood

Building software is not only about code.

Much of the essence of building a program is, in fact, the debugging of the specification. Fred Brooks

So when it comes to debugging the specification, anyone who has been working in this industry for long enough knows that talking to your customers isn’t enough most of the time.

If we’d asked the customers what they wanted, they would have said “faster horses” Henry Ford

Well written specs are key, not only for building the right product, but also to allow engineers to build it efficiently. If you ever had to write code for a feature which didn’t have specs that were clear enough, you know what I’m talking about.

Good specifications will always improve programmer productivity far better than any programming tool or technique. Milt Bryc

But managers and product people need to know what to prioritize and how to calculate costs.

The cost of adding a feature isn’t just the time it takes to code it. The cost also includes the addition of an obstacle to future expansion. The trick is to pick the features that don’t fight each other. John Carmack

Nowadays,

We see a lot of feature-driven product design in which the cost of features is not properly accounted. Features can have a negative value to customers because they make the products more difficult to understand and use. We are finding that people like products that just work. It turns out that designs that just work are much harder to produce that designs that assemble long lists of features. Douglas Crockford
Any program that tries to be so generalized and configurable that it could handle any kind of task will either fall short of this goal, or will be horribly broken. Chris Wenham

Having said that, I think we all agree that, when it comes to features:

The whole point of getting things done is knowing what to leave undone. Oswald Chambers

And the only way of knowing what to leave undone is having a clear mission, is being purpose-driven. Purpose-driven companies are often more successful due to the fact that:

The most important single aspect of software development is to be clear about what you are trying to build. Bjarne Stroustrup

What I’m trying to say here is that the more important part of writing software is asking the right questions. I think this is why this anecdote by one of my favorite characters in history, Charles Babbage, fits well in this context:

"On two occasions I have been asked [by members of Parliament]: 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question." Charles Babbage

Of course:

You certainly don’t need to have everything figured out in the path from here to world domination. Sam Altman

So:

Do what you can, where you are, with what you have. Roosevelt's Law of Task Planning

Because:

If it is not written down, it does not exist. Philippe Kruchten

As we have mentioned before:

Learn not to add too many features right away, and get the core idea built and tested. Leah Culver

It doesn’t matter how many unit, integration or acceptance tests you’ve got.

Regardless of your plans, production is the ultimate testing environment. JT Wall
Computer science education cannot make anybody an expert programmer any more than studying brushes and pigment can make somebody an expert painter. Eric S. Raymond

So you need to get your hands dirty.

As a rule, software systems do not work well until they have been used, and have failed repeatedly, in real applications. Dave Parnas

And they will eventually fail.

No one in the brief history of computing has ever written a piece of perfect software. It's unlikely that you'll be the first. Andy Hunt

So let’s go back to Akin’s laws of Spacecraft design because they teach us an important lesson:

To design a spacecraft right takes an infinite amount of effort. This is why it's a good idea to design them to operate when some things are wrong. 2nd of Akin's Laws of Spacecraft Design

Even if the odds are small, they still exist.

That hardly ever happens is another way of saying 'it happens'. Douglas Crockford

Experienced engineers know that when writing software:

Making code do what it's supposed to do is the easy part. Handling the myriad ways it can go wrong is the real work. @ajlozier

So why not avoid writing code as much as possible?

When it comes to security:

The most secure code in the world is code which is never written. Colin Percival

When it comes to beauty:

The most beautiful code, the most beautiful functions, and the most beautiful programs are sometimes not there at all. Jon Bentley

And when it comes to costs, efficiency, and reliability:

The cheapest, fastest and most reliable components of a computer system are those that aren’t there. Gordon Bell

Work to not work. Strive to be lazy.

The code you write makes you a programmer. The code you delete makes you a good one. The code you don't have to write makes you a great one. Mario Fusco

Looking at a PR and noticing that you’ve got a huge number of additions, many times, is not a good thing. The more code you delete, the better.

Deleted code is debugged code. Jeff Sickel
When debugging, novices insert corrective code; experts remove defective code. Richard Pattis

And Ken Thompson, the man himself, completely agrees with it.

One of my most productive days was throwing away 1000 lines of code. Ken Thompson

Given all this, we can conclude that:

The real hero of programming is the one who writes negative code. Douglas McIlroy

The less code you have, the more sophisticated you are. Da Vinci knew that way before we had any computers:

Simplicity is the ultimate sophistication. Leonardo da Vinci

Antoine de Saint-Exupéry also had something very wise to say about simplicity:

A designer knows that he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away. de Saint-Exupery's Law of Design

And it’s important to keep this in mind because:

Simplicity is prerequisite for reliability. Edsger W. Dijkstra

I know we have already talked a lot about the importance of being picky when deciding which features to implement, but one cannot emphasize that enough, especially given the huge impact it has on complexity.

A primary cause of complexity is that software vendors uncritically adopt almost any feature that users want. Niklaus Wirth

Follow the UNIX philosophy and focus on doing one thing and doing it well.

So much complexity in software comes from trying to make one thing do two things. Ryan Singer

Avoid it at all costs.

The purpose of software engineering is to control complexity, not to create it. Pamela Zave

Even if you find a complex system that you admire, remember this:

A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. John Gall
Inside every well-written large program is a well-written small program. C.A.R Hoare

Complexity not only makes it harder to investigate bugs and fix them, it affects all the human components involved in the project.

Complexity kills. It sucks the life out of developers, it makes products difficult to plan, build and test, it introduces security challenges, and it causes end-user and administrator frustration. Ray Ozzie

In any software, the ones that build it are as important as the project itself so make sure everyone is satisfied with what they are doing.

Programmers don't burn out on hard work, they burn out on change-with-the-wind directives and not 'shipping'. Mark Berry

But talking isn’t enough, you’ve gotta fight technical debt actively.

An evolving system increases its complexity unless work is done to reduce it. Meir Lehman

Even if in the beginning you feel like fighting technical debt is not something your customers will notice, you will soon realize that:

Good design adds value faster than it adds cost. Thomas C. Gale

In fact, even technical skills are not enough when it comes to design, after all:

A bad design with a good presentation is doomed eventually. A good design with a bad presentation is doomed immediately. 20th of Akin's Laws of Spacecraft Design

And that:

No matter how slow you are writing clean code, you will always be slower if you make a mess. Uncle Bob Martin

Know when to walk away.

Sometimes it pays to stay in bed on Monday, rather than spending the rest of the week debugging Monday's code. Christopher Thompson

And know when you are not ready to write code. Don’t be afraid of getting a piece of paper and drafting your idea before starting to type.

First, solve the problem. Then, write the code. John Johnson

Because:

The sooner you start to code, the longer the program will take. Roy Carlson
Weeks of coding can save you hours of planning. Unknown

Even if you planned and solved the problem first, it is likely that your estimate will be wrong many times. When estimating, keep Hofstadter’s Law in mind:

Hofstadter’s Law: It always takes longer than you expect, even when you take into account Hofstadter’s Law. Douglas Hofstadter

Good engineers are careful. They try to make sure they have considered all details and asked all the necessary questions. When doing whiteboard exercises on interviews, one of the things that interviewers take into account is your ability to figure out which pieces of the puzzle are missing. They value it so much because:

A good programmer is someone who always looks both ways before crossing a one-way street. Doug Linder

If you’re solving a kind of problem you have never solved before then you need to be even more careful and when that happens you will probably suffer from impostor syndrome, but that’s okay too.

Every great developer you know got there by solving problems they were unqualified to solve until they actually did it. Patrick McKenzie

In software engineering and life in general:

The true test of intelligence is not how much we know how to do, but how to behave when we don’t know what to do. John Holt

Learn when to ask why and trust determinism, it’s almost always your fault, never the compiler’s.

The amateur software engineer is always in search of magic. Grady Booch

Sometimes it seems hard to believe in that, but only because:

Any sufficiently advanced technology is indistinguishable from magic. Clarke's Third Law

If I could use a single quote for whenever people ask me for career advice, I would say the same thing as Paul Graham:

One, learn a lot about things that matter. Two, work on problems that interest you and three, with people you like and respect. Paul Graham

Develop soft skills, focus on things that matter.

Programming is not a zero-sum game. Teaching something to a fellow programmer doesn’t take it away from you. John Karmack
Be gentle, kind, and forgiving of your peers; respect from people you respect is really the only reward that sticks. Rusty Russell

If you are managing people, that becomes even more important.

There's one technique that you must use if you want people to listen to you: listen to them. The Pragmatic Programmer

Just because you are a leader, it doesn’t matter you will always be right.

The group is often much wiser than the individual, and I've been proven wrong more than once! Sam Newman

Listen to everyone. Always seek consensus.

In nature, the optimum is almost always in the middle somewhere. Distrust assertions that the optimum is at an extreme point. 8th of Akin's Laws of Spacecraft Design

If you were not able to convince your team, learn when it’s the right time to intervene.

Think about teaching a child to ride a bike. You can't ride it for them. You watch them wobble, but if you stepped in every time it looked like they might fall off, then they would never learn, and, in any case, they fall off far less than you think they will! But if you see them about to veer into traffic, or into a nearby duck pond, then you have to step in. Sam Newman

People matter.

Be humble, communicate clearly, and respect others. It costs nothing to be kind, but the impact is priceless. Addy Osmani

And now, after 100 quotes about software engineering, I’ll allow myself to add an extra one, that pretty much sums it all up.

If it takes more than a sentence to explain what you are doing, it’s almost always a sign that what you are doing is too complicated. Sam Altman

Yes, Sam, what we are doing is very complicated.


Get in touch!

If you disagree with anything I said or if you have anything you’d like to add or comment, feel free to use the space below or send me a tweet @lfernandescosta.

If you feel like submitting a PR to fix any possible typos or fix my grammar mistakes, you can also find me on GitHub @lucasfcosta.


More Amazing Quotes

The quotes in this post come from many different places. I can’t link all of them because I usually just add them to my Evernote when I find one that I like, but you can find lots of them at:

Thanks for reading!