The Great Programming Quotes 
Tags: writing, programming
Published: 2021-07-12 13:27:14

---
title: The Great Programming Quotes 
published: true
date: 2021-07-10 06:11:37 UTC
tags: Writing, Programming, 
canonical_url: http://coderscat.com/the-great-quotes-of-programming/
---

![kimberly-farmer @ unsplash.com](http://coderscat.com/images/kimberly-farmer-lUaaKCUANVI-unsplash.jpg)

Several days ago, I came across [John Carmack’s post](https://twitter.com/id_aa_carmack/status/1047504598527856642?lang=en) on learning programming. His advice is truly helpful for programming beginners and worth more reading.  
This reminds me to spread other great quotes in mind, which from great programmers and computer scientist.

Some of them help me understanding more on computing, some of them are principles I’m trying to apply to my daily work, and some of them are funny.

# Design and architecture

## Abstraction is essential

> Complexity is anything that makes software hard to understand or to modify.  
> -–John Ousterhout

> “All problems in computer science can be solved by another level of indirection”  
> – David Wheeler

The power of these can be seen in the domains of software development, design patterns, architecture and hardware design. The computing world is a combination of different abstraction layers, operating system, networking model, distribution system and graphic libraries are all abstractions, in different levels.

## Keep simple and changeable

> Simplicity is prerequisite for reliability  
> – Edsger Dijkstra

> Walking on water and developing software from a specification are easy if both are frozen.  
> – Edward V Berard

> Design is the art of arranging code to work today, and be changeable forever.  
> -– Sandi Metz

> There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.  
> – C.A.R. Hoare.

The Dutch computer pioneer Dijkstra, had many profound insights on computing complexity and algorithms. He is possibly one of favorite computer scientist in world wide. One of his most cherished habits was in creating [amazing articles](https://www.cs.utexas.edu/users/EWD/). Most of the articles written in a fountain pen.

Simplicity doesn’t mean doing less; rather, it’s a way to keep your software maintainable.

When you start writing code, you tend to make it very complex. As you become an experienced programmer, you will find that keeping things simple is the surest way to build complex systems.

Ability to make complex things simple is what sets apart a great programmer from an average one.

# Coding

## Do things in right way

> “Make it work, make it right, make it fast.”  
> – Kent Beck

> When in doubt, use brute force.  
> ——Ken Thompson

> The sooner you start to code, the longer the program will take.  
> —— Roy Carlson

> If you can’t write it down in English, you can’t code it.  
> —— Peter Halpern

> Get your data structures correct first, and the rest of the program will write itself.  
> —— David Jones

> Don’t write a new program if one already does moie or less what you want. And if you must write a program, use existing code to do as much of the work as possible.  
> —— Richard Hill

> Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.  
> – Rick Osborne

> We better hurry up and start coding, there are going to be a lot of bugs to fix. 😏  
> – Anonymous

I’m always happy to follow these principles when programming. These advice helped me to save a lot of time. Remember, do the right thing at proper time.

## Optimize it or not

> Before optimizing, use a profiler to locate the “hot spots” of the program.  
> —— Mike Morton

> In non-I/O-bound programs, less than four per cent of a program generally accounts for more than half of its running time.  
> —— Don Knuth

> Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.
> 
> Yet we should not pass up our opportunities in that critical 3%. A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code; but only after that code has been identified.  
> —— Don Knuth

_Premature optimization_ means begin to optimize a program without “hot spot” tracing. You won’t fix performance issue and introduce bugs in this kind of optimization.

## Keep code readable

> Programs must be written for people to read, and only incidentally for machines to execute.  
> –Hal Abelson and Gerald Sussman. Structure and Interpretation of Computer Programs

> Any fool can write code that a computer can understand. Good programmers write code that humans can understand.  
> – Martin Fowler

> It’s harder to read code than to write it  
> – Joel Spolsky

> Don’t comment bad code. Rewrite it.  
> – Brian Kernighan

> Good code is its own best documentation. As you’re about to add a comment, ask yourself:  
> ‘How can I improve the code so that this comment isn’t needed?’  
> – Steve McConnell (Code Complete)

> If the code and the comments disagree, then both are probably wrong.  
> —— Norm Schryer

> When explaining a command, or language feature, or hardware widget, first describe the problem it is designed to solve.  
> —— David Martin

> Code is like humor. When you have to explain it, it’s bad.  
> -– Cory House

Do you have trouble in reading the code written by yourself two years ago?

A single piece of code will, over its lifetime, be read hundreds, maybe thousands of times. It will be read hundreds or thousands of times because it must be understood.

Comments will help much on making code readable. Good programmers will write easy to understand the code, and don’t care whether the machine can run, compilers and interpreters will keep your code is right in syntax.

But too much of comments also will not help. If the code is self-explanatory, there is no need for comments. Even if you do need a comment, the comment should be about why you did it, not about what you did.

When writing code, it is better to be clear than to be clever. “Be cleaver” is something like: condensing multiple lines of code into one, using those tricky algorithms, or using some obscure feature of programming language to accomplish a task in a novel way. Tricky code will make it hard to maintain.

# Testing

> Testing can show the presence of bugs, but not their absence.  
> —— Edsger W. Dijkstra

> If debugging is the process of removing bugs, programming must be the process of putting them in.  
> – Edsger Dijkstra

> Testing leads to failure, and failure leads to understanding.  
> – Burt Rutan

> It takes 3 times the effort to find and fix bugs in system test than when done by the developer. It takes 10 times the effort to find and fix bugs in the field than when done in system test. Therefore insist on unit tests by the developer.  
> – Larry Bernstein

There is no doubt about the importance of testing. I’m afraid to maintain a code base which don’t contains enough test cases. We should try to find bugs in development phase as many as possible.

Unit testing, integrated testing, fuzzing testing are all good practices to improve the coding quantity. From my experience, the testing code is also document for code, which helpful for others understanding code.

Embrace testing, it will save you much of time.

# Deugging

> Of all my programming bugs, 80% are syntax errors. Of the remaining 20%, 80% are trivial logical errors. Of the remaining 4%, 80% are pointer errors. And the remaining 0.8% are hard.  
> —— Marc Donner

> The first step in fixing a broken program is getting it to fail repeatably.  
> —— Tom Duff

> Programming is like sex. One mistake and you have to support it for the rest of your life  
> – Michael Sinz

Debugging is a last-ditch effort to save the code. Debugging code is more difficult than writing code. Because when we need to debug, it means the error have escaped from coding, reviewing, testing.

Usually, find the root cause of a bug is much harder than fix it. If you have reproduced a bug, you almost finished 90% of work.

I’m a fan of Printf Debugging(a.k.a Caveman Debugging).

> The most effective debugging tool is still careful thought, coupled with judiciously placed print statements.  
> -— Brian Kernighan, “Unix for Beginners” (1979)

> Debuggers don’t remove bugs. They only show them in slow motion.  
> – Anonymous

# Productivity

> Don’t reapeat yourself. Every piece of knowledge must have a single, unambiguous, authoritative representation within a system”  
> – Andy Hunt and Dave Thomas

> I’m not a great programmer; I’m just a good programmer with great habits.  
> – Kent Beck

Lazy programmers are good programmers, who want to do avoid duplication and won’t do thing reputably.

If there is a lot of repetition in the code, it is likely that we should spend time to refactor the code. Most repeated task is more suitable finished by machine, so we should make it automation.

# Tools

> The most disastrous thing that you can ever learn is your first programming language.  
> – Alan Kay

> A language that doesn’t affect the way you think about programming is not worth knowing.  
> ― Alan J. Perlis

Programming languages, editors, libraries, all these are tools for programmers.

# Learning

> The only way to learn a new programming language is by writing programs in it.  
> – Dennis Ritchie

> The first principle is that you must not fool yourself and you are the easiest person to fool.  
> ―- Richard P. Feynman

> Avoid “cookbook programming”, where you copy and paste bits of code that you have found to make something work. Make sure you fully understand what everything it actually doing, and that you are comfortable applying the techniques in other situations.  
> – John

> 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

> Programming isn’t about what you know; it’s about what you can figure out.  
> – Chris Pine

> Theory is when you know something, but it doesn’t work. Practice is when something works, but you don’t know why. Programmers combine theory and practice: Nothing works and they don’t know why.  
> – Anonymous

When I learned programming, I was also anxious about knowing the details of everything, language syntax, libraries.

We have a ton to lear. This way of learning will make a learner frustrated.

Instead, don’t learn details, learn the essentials and concepts, apply them in practice. Problem-solving is the skill we end up using most.

Finally, don’t lose your curiosity.