
Programmer proverbs - staltz
http://futurice.com/blog/programmer-proverbs
======
luch
I'm actually a fan of the following proverbs. They are less pompous, and more
humourous :

[http://theprofoundprogrammer.com/post/28552672458/text-
maybe...](http://theprofoundprogrammer.com/post/28552672458/text-maybe-a-
clean-build-will-fix-it)

[http://theprofoundprogrammer.com/post/30809835982/text-
race-...](http://theprofoundprogrammer.com/post/30809835982/text-race-
conditions-photograph-of-a-cheetah)

[http://theprofoundprogrammer.com/post/34818584135/text-do-
no...](http://theprofoundprogrammer.com/post/34818584135/text-do-not-remove-
photograph-of-the)

~~~
rev_bird
You aren't one of the authors over there, are you? I'd love to hang up a
poster of the first link at my desk but the store is down.

------
shangxiao
Unfortunately I only agree with a handful of these particular proverbs. The
set of proverbs that I've found are truly useful to programmers would be "The
Zen of Python" (open a Python session and run `import this`)

The Zen of Python:

    
    
        Beautiful is better than ugly.
        Explicit is better than implicit.
        Simple is better than complex.
        Complex is better than complicated.
        Flat is better than nested.
        Sparse is better than dense.
        Readability counts.
        Special cases aren't special enough to break the rules.
        Although practicality beats purity.
        Errors should never pass silently.
        Unless explicitly silenced.
        In the face of ambiguity, refuse the temptation to guess.
        There should be one-- and preferably only one --obvious way to do it.
        Although that way may not be obvious at first unless you're Dutch.
        Now is better than never.
        Although never is often better than *right* now.
        If the implementation is hard to explain, it's a bad idea.
        If the implementation is easy to explain, it may be a good idea.
        Namespaces are one honking great idea -- let's do more of those!

~~~
peterwwillis
These are some good maxims. But I have to be "that guy" and suggest that
maxims and proverbs might not be the best ways to practice zen. I find that
the more I memorize how i'm _supposed_ to do it takes me away from thinking
about how I _could be_ doing it, with other people in mind.

There are some humorous/insightful koans from ESR, the Tao of Programming, the
Codeless Code, etc. The best ones do not _tell you_ how to program; they open
up your mind and let you discover the True Path. (They also sound more poetic,
and programmers could seriously use more poetry in their lives)

------
jbob2000
>Programming is about understanding with precision. Not about trying until it
works.

I think you're talking about engineering, because programming is _definitely_
about trying until it works.

~~~
3minus1
I think it's talking about people who don't know how to read code and discern
what's happening and just end up tweaking things, cutting and pasting code,
etc. just kind of crossing their fingers that it will work.

~~~
userbinator
They also tend to be the ones who have only a superficial understanding of
what their code/the language is doing, and to whom edge cases are an almost
unknown concept. Those people would be well advised to apply the Feynman
Algorithm more.

~~~
MetaCosm
I think you might have misunderstand the Feynman Algorithm (alternative
possibility, I misunderstood it).

My understanding of the Feynman Algorithm was that it was basically a joke by
Gell-Mann. Gell-Mann was pointing out that no one else on earth (even himself,
a Noble prize winner) could work the way Feynman did, the joke being that he
only needed three steps: (1) Write down the problem. (2) Think real hard. (3)
Write down the solution. It was about the absurd brilliance of Feynman, not
intended as any sort of useful model to follow.

~~~
23david
[http://c2.com/cgi/wiki?FeynmanAlgorithm](http://c2.com/cgi/wiki?FeynmanAlgorithm)

------
PMan74
Up there with those motivational pictures - banal, empty, of little use to
anybody.

~~~
ctdonath
I was struck by how the backgrounds had utterly nothing to do with the
verbiage. At least Despair.com strives for _some_ connection between image &
words.

------
henrik_w
My favorites are:

“A complex system that works is invariably found to have evolved from a simple
system that worked.” John Gall

“Enlightened trial and error outperforms the planning of flawless intellects.”
David Kelley

“It’s OK to figure out murder mysteries, but you shouldn’t need to figure out
code. You should be able to read it.” Steve McConnell

And two quotes from the Agile Manifesto:

“Working software is the primary measure of progress.”

“Simplicity — the art of maximizing the amount of work not done — is
essential.”

[http://henrikwarne.com/2012/02/25/favorite-programming-
quote...](http://henrikwarne.com/2012/02/25/favorite-programming-quotes/)

~~~
JAlexoid
Add: Code is written for people to read 8196 times and machines to compile 2^0
times.

------
edw519

       1. Start with the answer, then work back.
       2. Don't repeat yourself. (DRY)
       3. Normalize the data. The process will follow.
       4. Isolate. Isolate. Isolate.
       5. It worked. You touched it. It doesn't work. It was you.
       6. Write for the next programmer, not the machine.
       7. If you don't hate your old code, you haven't grown enough.
       8. The first A/B test is your own.
       9. Focus on the microseconds & the nanaseconds take care of themselves.
      10. The fastest code is the code you don't write.
      11. The 2nd worst programmer is who wrote what you're maintaining.
      12. The worst programmer is the one who changes your code.
      13. Comments don't execute.
      14. The best technical co-founder is a code generator.
      15. The user never knows what they want until UAT.
      16. Fast. Cheap. Right. Choose 2.
      17. Perfect specs or rapid iterations. Choose 1.
      18. Start with "Hello World", then amend.
      19. Never deploy on Friday.
      20. Forget to unit test? That's a paddlin'.

~~~
SideburnsOfDoom
> Don't repeat yourself. (DRY)

Beware the Share:
[http://programmer.97things.oreilly.com/wiki/index.php/Beware...](http://programmer.97things.oreilly.com/wiki/index.php/Beware_the_Share)

It can bite you just as hard as DRY.

~~~
lmm
Really? I've never seen that happen in today's days of, well, maven.

~~~
SideburnsOfDoom
I don't know your language's tooling, but I don't think that the decision of
when to share code or not - (i.e. if it actually represents the same concept)
is something that is solved by a specific tool, or is limited to a specific
language.

~~~
lmm
I've never seen a problem that comes from code being shared, and I think that
comes from maven getting the rules right:

* Releases are immutable

* Releases can only depend on releases

* Releases can only be made when all tests pass. Twice.

* The transitive dependency graph is a deterministic function of the config file; upstream changes cannot affect it

* Dependency versions are only updated by an explicit manual step

You never worry about "synchronizing" changes because other components can
perfectly well depend on an old version of the library. You never accidentally
break a downstream project, because everything's explicit. I have genuinely
never seen the problems described in your link.

~~~
SideburnsOfDoom
You are talking about binary compatibility and immutable dependencies. That's
nice, but it's a different topic to the conversation that jerf and I are
having about the semantics of shared code. I'm sure maven is good at what it
does, but it's not completely relevant.

~~~
lmm
Fine, then let me put it this way: your initial claim in no way matches my
experience. "Beware the Share" is bad advice; that wiki page is simply wrong.
Factoring out common code is a good thing and will not bite you.

~~~
SideburnsOfDoom
It's a wiki page, but it's also a book [1]. I have an actual paper copy, and I
would highly recommend it. I've seen several of the authors give talks, most
were good. Kevlin Henney (the Editor) was particularly so.

However I shall also treat the data from your deep experience with all due
reverence.

1] [http://www.amazon.com/Things-Every-Programmer-Should-
Know/dp...](http://www.amazon.com/Things-Every-Programmer-Should-
Know/dp/0596809484/ref=sr_1_1?ie=UTF8&qid=1424027969&sr=8-1&keywords=97+things+every+programmer+should+know)

------
fs111
Here is one for to you add "Don't trust empty phrases on some random website".

------
cafard
Jon Bentley's "Bumper-Sticker Computer Science" pieces, collected in the
_Programming Pearls_ book seem a lot better to me.

------
insulttogingery
This is some real pretty bullshit.

They read like horoscopes / fortune cookies.

------
Vaskivo
> The first symptom of stagnation is preference.

Love this one!

[EDIT]: I probably didn't understand it the same way. I read it as "don't have
favourites, be open to new stuff"

~~~
huhtenberg
It's quite dumb actually.

Having a preference means that you know all available options well, not that
you think there are no better alternatives.

~~~
V-2
That stagnation / laziness is often disguised as preference doesn't mean that
every sign of preference indicates stagnation.

~~~
npsimons
Right, which is exactly why "The first symptom of stagnation is preference."
is dumb. How do you tell the difference between "stagnation" and knowing the
best tool for the job? What's that you say? It takes time and thinking beyond
a pithy saying? Then why bother with the pithy saying?

~~~
AnimalMuppet
Knowing the best tool for the job means that you pick different tools for
different jobs. Having a (strong) preference means you pick the same tool if
at all possible.

------
jackreichert
"Always code as if the guy who ends up maintaining your code will be a violent
psychopath who knows where you live."

[Source]([https://groups.google.com/forum/#!msg/comp.lang.c++/rYCO5yn4...](https://groups.google.com/forum/#!msg/comp.lang.c++/rYCO5yn4lXw/oITtSkZOtoUJ))

~~~
rev_bird
I don't know why, but I'm still consistently surprised that we have the
ability to link to the obscure sources of well-known quotes from 24+ years
ago.

------
olla
Actually hoped to see more true, but satirical, statements like: "It usually
takes a long time to find a shorter way." or "Debugging software is the
practice of removing bugs. Programming is the art of putting them in."
Currently seems more like criticising a lecture.

~~~
swah
Like this ? [http://www.cs.yale.edu/homes/perlis-
alan/quotes.html](http://www.cs.yale.edu/homes/perlis-alan/quotes.html)

------
7402
See "The Klingon Programmer's Code of Honour"
[http://www.klingon.org/resources/klingon_code.html](http://www.klingon.org/resources/klingon_code.html)
\- First on the list:

    
    
      Specifications are for the weak and timid.

------
dwarman
Back in the days of Windows 3.11, in frustration, I coined one that so far has
not gained any traction:

"that which can be configured must be configured"

Just like there are few people with IQ exactly 100, there are few users for
whom all the default settings are appropriate. One has to review all config
panels to be sure, and I have never done so without finding one critical
default or another that was just plain problematic.

Lesson: make defaults clear, as few as possible, and all found in one place.

------
webscale2015
One of my favourites: "I don't need to know how it works, or if it is secure,
I just gem install it! Don't ask me, I'm just a web scale developer!"

------
restalis
"Elegant, efficient, and effective code beats any argument."

The scary thing is, I know people who firmly believe that, even when the
argument is on code correctness.

------
radoslawc
I like this better:
[http://programmingexcuses.com/](http://programmingexcuses.com/) (just press
'refresh')

~~~
gear54rus
This isn't serious, is it?

'The third party documentation is wrong' \- it's always right|?

'I haven't had any experience with that before' \- did I have experience with
everything?

I really don't understand what this is getting at, if it's serious.

~~~
nicholaides
I think it's trying to say that the lazy programmer uses these excuses for why
they failed/haven't made progress/have stopped working on something.

------
henrik_w
Not really a programmer proverb, but close enough and still pretty good.

Customer Disservice: "We're Not Satisfied Until You're Not Satisfied"

[http://www.funnyjunk.com/funny_pictures/477940/Customer/](http://www.funnyjunk.com/funny_pictures/477940/Customer/)

------
arethuza
My all time favourite:

 _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._

C. A. R. Hoare

------
tokai
Most of these are horrible.

------
JAlexoid
Very schizophrenic.

------
sbensu
_Programming is about understanding with precision.

Not trying until it works

Unless you are working with Regex of course._

------
firepoet
Why do they have to be in Europe? :-(

~~~
klez
Because we code too. What's the problem?

~~~
benihana
Homeboy wants a job but lives in the States.

------
willvarfar
Can you link to particular proverbs?

