Programmer proverbs
futurice.com
futurice.com
http://theprofoundprogrammer.com/post/28552672458/text-maybe...
http://theprofoundprogrammer.com/post/30809835982/text-race-...
http://theprofoundprogrammer.com/post/34818584135/text-do-no...
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!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)
I think you're talking about engineering, because 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? ;)
Of course you could formalize those heuristics... trying until they worked ;)
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.
I must say I'm really curious. What was his career trajectory? Has he been successful since?
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.
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.
Programming requires more precise understanding.
Where else would one getting precise understanding, anyway?
"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.
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.
“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...
"Simple is beautiful."
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'.Beware the Share: http://programmer.97things.oreilly.com/wiki/index.php/Beware...
It can bite you just as hard as DRY.
* 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.
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...
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.
Specifications are for the weak and timid.They read like horoscopes / fortune cookies.
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"
Having a preference means that you know all available options well, not that you think there are no better alternatives.
With tools, languages and frameworks evolving so rapidly these days, it's impossible to know all of your options well.
But the proverb in the form given is dumb.
STAGNATION!
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.
[Source](https://groups.google.com/forum/#!msg/comp.lang.c++/rYCO5yn4...)
"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.
The scary thing is, I know people who firmly believe that, even when the argument is on code correctness.
'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.
Customer Disservice: "We're Not Satisfied Until You're Not Satisfied"
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
Not trying until it works
Unless you are working with Regex of course.