Programmer proverbs

http://futurice.com/blog/programmer-proverbs

by staltz • 11 years ago

138 79 11 years ago

futurice.com

jbob2000• 11 years ago

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.

feider• 11 years ago

That applies also to engineering in some degree...

chriswarbo• 11 years ago

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? ;)

kaoD• 11 years ago

Because human-brain heuristics are very good at deciding what to try next, while too complex to be coded into a program in the first place.

Of course you could formalize those heuristics... trying until they worked ;)

failed_ideas• 11 years ago

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.

odonnellryan2• 11 years ago

I find it hard to really understand certain things: design patterns, data structures, and sometimes algorithms, without trying them.

I knew a very, very bright person who could come up with some great and clean code. He definitely understood the problem and his solution was "optimal." Problem, before he even started coding he did an insane amount of research. Not just learning syntax, common patterns, etc.. but to the point of memorizing the entire standard library and reading several books on the problem domain before even beginning with some hash-it-out code. This wasn't for hard problems, just simple CRUD apps (for the most part.) Made it impossible to work with him as a team member.

marcosdumay• 11 years ago

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.

3minus1• 11 years ago

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• 11 years ago

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.

shangxiao4• 11 years ago

I guess this is a problem with proverbs: lack of context. For architectural design or requirements elicitation it's all about improving with iterations. However with detailed design you can be quite precise and shouldn't just wing it.

fit2rule• 11 years ago

Hacking is trying until it works.

Programming requires more precise understanding.

nialo• 11 years ago

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?

btbuildem2• 11 years ago

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.

nvader2• 11 years ago

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.

Vaskivo• 11 years ago

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• 11 years ago

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-23• 11 years ago

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

squeaky-clean• 11 years ago

Having a preference means that you know all available options well

With tools, languages and frameworks evolving so rapidly these days, it's impossible to know all of your options well.

jharsman• 11 years ago

Having static preferences that never change does indicate stagnation.

But the proverb in the form given is dumb.

stupidcar• 11 years ago

Prefer not to code everything in Brainfuck?

STAGNATION!

ntlve• 11 years ago

What if preference is based on whatever makes you work the fastest? Or what if preference is based on objective, reproducible evaluation?

jerf2• 11 years ago

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.

firepoet• 11 years ago

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

klez• 11 years ago

Because we code too. What's the problem?

benihana• 11 years ago

Homeboy wants a job but lives in the States.

PMan74• 11 years ago

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

cafard2• 11 years ago

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

blowski• 11 years ago

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.

ctdonath• 11 years ago

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.

JimmyM• 11 years ago

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

luch• 11 years ago

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_bird2• 11 years ago

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.

webscale2015• 11 years ago

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

olla• 11 years ago

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• 11 years ago

Like this ? http://www.cs.yale.edu/homes/perlis-alan/quotes.html

radoslawc• 11 years ago

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

gear54rus• 11 years ago

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• 11 years ago

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.

fs111• 11 years ago

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

cafard2• 11 years ago

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

willvarfar• 11 years ago

Can you link to particular proverbs?

shangxiao4• 11 years ago

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• 11 years ago

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)

edw519• 11 years ago

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

sp332• 11 years ago

What does #8 mean?

shangxiao4• 11 years ago

I take it to mean that you'll be the first person to smoke test changes

shangxiao4• 11 years ago

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

V-23• 11 years ago

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.

SideburnsOfDoom4• 11 years ago

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.

lmm3• 11 years ago

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

jerf2• 11 years ago

That's true, but my recommendation to newer programmers is still learn to practice radical DRY first, then as the final polish, learn when to back off (i.e., "the rule of three"). Far, far more programmers do not understand DRY, and accidentally avoid over-sharing by virtue of simply having bad coding practices in general and rewriting everything every time than overdo DRY.

Someday I ought to write up a post about this sort of thing on my blog. I think part of our eternal warfare about coding practices (though by no means all of it) comes from the fact that there are different practices that should be followed by someone with two years of experience than someone with ten. For instance, I think test-driven development is great... for a new programmer. It is something that you will outgrow eventually. But in the meantime, TDD will teach you good design much more quickly than you would have learned any other way, and in the meantime, you'll produce better code than you would have otherwise just blundering around in the traditional manner. And for myself at coming up fast on 20 years of experience, I don't do "TDD" but I still do a lot of automated testing (and the damned code keeps surprising me, and punishing me whenever I think this time for sure I can skip the tests...).

So too here with DRY; you may someday outgrow it, but you'll learn better design and programming skills in the meantime, and in the end I still think you'll find the optimum point is closer to DRY than farther from it. I think that's because beyond the surface gloss of DRY from a perspective of simply "not repeating code" you come to understand how a bit of code can embody a concept, and what DRY is really trying to teach you to avoid is having a concept live in two places, rather than raw code repetition, and that idea will stick with you until the end of your career. But to get to that level of understanding, practice radical DRY until you understand.

btbuildem2• 11 years ago

Amen to #19!

henrik_w2• 11 years ago

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

JAlexoid2• 11 years ago

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

rffn• 11 years ago

Regarding the last one:

"Simple is beautiful."

restalis• 11 years ago

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

jackreichert• 11 years ago

"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_bird2• 11 years ago

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• 11 years ago

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

tokai• 11 years ago

Most of these are horrible.

JAlexoid2• 11 years ago

Very schizophrenic.

henrik_w2• 11 years ago

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/

insulttogingery• 11 years ago

This is some real pretty bullshit.

They read like horoscopes / fortune cookies.

sbensu• 11 years ago

Programming is about understanding with precision.

Not trying until it works

Unless you are working with Regex of course.

arethuza• 11 years ago

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

dwarman• 11 years ago

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.

7402• 11 years ago

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.

Programmer proverbs

Related Stories