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/30809835982/text-race-...

http://theprofoundprogrammer.com/post/34818584135/text-do-no...

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

[nvader]

I agree with you: the playful exploration of an idea space can lead to really creative solutions. However, I think what we need to focus on is hacking at the appropriate level.

For example, trying to iterate on regexen to see how well they validate credit cards on your shopping cart form is at a different level to say, trying out a new database system. The former can be undertaken in a desultory way more easily than the latter--and therein lies the trap. It's easy to generate a false sense of progress, seeing code being output and test cases passing, all the while without really understanding or learning anything about the code or the problem at all.

Precision understanding of the mechanics of coding, on the other hand, free you to concentrate on higher problems. You don't need to play whack-a-mole with locks and semaphores to eliminate race conditions, and can focus on developing that revolutionary game.

[failed_ideas]

Yea, that's about the worst advice to give a programmer/hacker. The "maybe I can try this" and "I wonder if I could do this" is the core of my world. I've been told by actual engineers that things I wanted to do were impossible, but I played, and did the impossible. Play with your code.

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

[marcosdumay]

At the end of the day, anybody that cretes anything of importance is hacking most of the time.

That does not mean one shouldn't plan, and know why his hacks work. Just that non-hackish solutions normaly only work in already solved problems.

[btbuildem]

In my experience, it ends up being much more efficient (in the long term) to "understand with precision" - think and think and think about it, and only after you've thought it through, write the code.

"Try until it works" is a mark of an inexperienced craftsman - simply not knowing enough about the tools, the particular domain and the problem at hand forces one to try and try again until something works.. but that kind of "accidental" approach is inefficient compared to an intentional, measured approach.

It's very humbling to work alongside an older, experienced developer - the proportion of time they spend writing actual code is relatively low; most of the time is spent on working out the assumptions, the constraints, teasing out the larger picture from the details, and constructing a technical design... the actual code-writing is like a few quick yet measured strikes of a samurai sword - quiet, almost invisible, frighteningly effective.

[chriswarbo]

> programming is definitely about trying until it works.

Sounds like you need some more meta. If "trying until it works" is your algorithm, why not have a program execute it for you? ;)

[fit2rule]

Hacking is trying until it works.

Programming requires more precise understanding.

[nialo]

I work as a mechanical engineer, and that involves only slightly less trying things until they work than programming.

Where else would one getting precise understanding, anyway?

[feider]

That applies also to engineering in some degree...

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

[blowski]

I don't know, I can imagine quite a number of fresh programmers marching into a meeting room, believing they've solved all the company's problems with a pithy yet profound statement.

[JimmyM]

At first I thought they were supposed to be a parody. It was quite upsetting to realise that they were deadly serious.

[cafard]

Yes, I was just wondering when somebody would come up with a Despair.com reply to them.

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

[JAlexoid]

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

[rffn]

Regarding the last one:

"Simple is beautiful."

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

It can bite you just as hard as DRY.

[shangxiao]

These are quite good, source? I've heard of most of in one form or another from different people.

[V-2]

Ad. 7. True, but if you get to hate your old code all the time, you must be doing something wrong and you probably don't actually progress.

[btbuildem]

Amen to #19!

[sp332]

What does #8 mean?

[fs111]

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

[7402]

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

  Specifications are for the weak and timid.

[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"

[jerf]

You shouldn't. It's gibberish.

Discrimination, when not applied to people, is a good thing. If you have spent years learning some discipline, and you have developed no preferences, you are not "avoiding stagnation", you are indecisive to the point of paralysis.

Challenge them occasionally, sure, but failure to develop preferences is a massive judgment failure.

For what it's worth, this is the first one in that list that I looked at and decided was garbage... I kept scanning for another few and saw little reason to change my mind, as it was not an exception. Pretty landscapes notwithstanding, this entire list was quite sophomoric... it seems to me the criteria for inclusion was sounding wise rather than being wise.

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

[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...)

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

[JoeAltmaier]

xkcd had one about, write as if the only thing between somebody trying to understand your code, and hot sweaty sex, is you.

[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

[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/ (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.

[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/

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