9 ms·
Programmer proverbs
- jbob2000 12y 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.
- nialo 12y agoI 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 12y agoThat applies also to engineering in some degree...
- chriswarbo 12y 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 12y agoBecause 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 12y agoYea, 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.
- odonnellryan 12y agoI 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.
- nvader 12y agoI'm not seeing the drawback to him. It may have even worked out to his benefit, as over time his knowledge of the craft would grow out of proportion to the rest of his team, say, who were solely focussed on getting things done. I must say I'm really curious. What was his career trajectory? Has he been successful since?
- odonnellryan 12y agoNot sure, I don't believe so.
- marcosdumay 12y agoAt 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 12y agoI 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 12y agoThey 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 12y agoI 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 12y agohttp://c2.com/cgi/wiki?FeynmanAlgorithm http://c2.com/cgi/wiki?FeynmanAlgorithm
- shangxiao 12y agoI 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 12y agoHacking is trying until it works. Programming requires more precise understanding.
- btbuildem 12y agoIn 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.
- nvader 12y agoI 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 12y 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 12y agoIt'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 12y agoThat stagnation / laziness is often disguised as preference doesn't mean that every sign of preference indicates stagnation.
- npsimons 12y agoRight, 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?
- V-2 12y agoWell, the way I see it, the adage is right to recommend being suspicious of, and questioning fixated preferences. This attitude is healthy.
- AnimalMuppet 12y agoKnowing 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.
- squeaky-clean 12y 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.
- firepoet 12y agoWhy do they have to be in Europe? :-(
- PMan74 12y agoUp there with those motivational pictures - banal, empty, of little use to anybody.
- cafard 12y agoYes, I was just wondering when somebody would come up with a Despair.com reply to them.
- blowski 12y agoI 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 12y agoI 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 12y agoAt first I thought they were supposed to be a parody. It was quite upsetting to realise that they were deadly serious.
- luch 12y agoI'm actually a fan of the following proverbs. They are less pompous, and more humourous : http://theprofoundprogrammer.com/post/28552672458/text-maybe-a-clean-build-will-fix-it http://theprofoundprogrammer.com/post/28552672458/text-maybe... http://theprofoundprogrammer.com/post/30809835982/text-race-conditions-photograph-of-a-cheetah http://theprofoundprogrammer.com/post/30809835982/text-race-... http://theprofoundprogrammer.com/post/34818584135/text-do-not-remove-photograph-of-the http://theprofoundprogrammer.com/post/34818584135/text-do-no...
- deleted 12y ago[deleted]
- rev_bird 12y agoYou 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 12y agoOne 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 12y agoActually 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 12y agoLike this ? http://www.cs.yale.edu/homes/perlis-alan/quotes.html http://www.cs.yale.edu/homes/perlis-alan/quotes.html
- radoslawc 12y agoI like this better: http://programmingexcuses.com/ http://programmingexcuses.com/ (just press 'refresh')
- eidyia 12y agoaha must be a bad sign but I can "hear" half of them in my own voice :D
- gear54rus 12y agoThis 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 12y agoI 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 12y agoHere is one for to you add "Don't trust empty phrases on some random website".
- cafard 12y agoJon Bentley's "Bumper-Sticker Computer Science" pieces, collected in the Programming Pearls book seem a lot better to me.
- willvarfar 12y agoCan you link to particular proverbs?
- shangxiao 12y agoUnfortunately 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 12y agoThese 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 12y ago1. 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 12y agoWhat does #8 mean?
- shangxiao 12y agoI take it to mean that you'll be the first person to smoke test changes
- shangxiao 12y agoThese are quite good, source? I've heard of most of in one form or another from different people.
- V-2 12y agoAd. 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.
- SideburnsOfDoom 12y ago> Don't repeat yourself. (DRY) Beware the Share: http://programmer.97things.oreilly.com/wiki/index.php/Beware_the_Share http://programmer.97things.oreilly.com/wiki/index.php/Beware... It can bite you just as hard as DRY.
- henrik_w 12y agoMy 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-quotes/ http://henrikwarne.com/2012/02/25/favorite-programming-quote...
- restalis 12y 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 12y 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++/rYCO5yn4lXw/oITtSkZOtoUJ https://groups.google.com/forum/#!msg/comp.lang.c++/rYCO5yn4...)
- rev_bird 12y agoI 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 12y agoxkcd had one about, write as if the only thing between somebody trying to understand your code, and hot sweaty sex, is you.
- tokai 12y agoMost of these are horrible.
- JAlexoid 12y agoVery schizophrenic.
- deleted 12y ago[deleted]
- henrik_w 12y agoNot 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/
- insulttogingery 12y agoThis is some real pretty bullshit. They read like horoscopes / fortune cookies.
- sbensu 12y agoProgramming is about understanding with precision. Not trying until it works Unless you are working with Regex of course.
- arethuza 12y agoMy 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 12y agoBack 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 12y agoSee "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.