Programming quotes
Koen van Gilst / September 22, 2019
4 min read • ––– views
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!
If you don’t actively fight for simplicity in software, complexity will win.
…and it will suck.
There are only two kinds of languages: the ones people complain about and the ones nobody uses.
Brendan Eich approvingly quoting Bjarne Stroustrup (C++ creator) when asked about the constant hate on JavaScript. From his AMA on Reddit.
Write tests. Not too many. Mostly integration.
It is also my experience that integration tests offer the best value for money when it comes to testing. Unit tests tend to be pointless (especially for front-end code) and fragile when you do large refactors. End-2-end tests tend to be too unreliable for large-scale usage.
Hierarchy of any implementation:
1 Correct
2 Simple
3 FastBe wary of the temptation to flip 2 and 3. Fast is great but if you can never touch the code again what is the point?
I like working with managers/product owners that also follow this philosophy. First, make it work (and ship it!), then make it right (and ship it!), and then fast, small, beautiful, etc will follow.
Turns out the quote Make it work, make it right, make it fast is originally from Kent Beck (who learned it from his dad).
When people say "React is declarative" this is what they mean.
Instead of manipulating the UI in response to user actions to arrive at an undeclared state, you declare state and then the UI that represents it.
Now user actions just change state and React mirrors it to the UI.
It's not always easy to explain what makes React's component-based programming model so powerful and fun to work with, but this tweet by Ryan Florence captures a major part of its appeal.
A physicist, a structural engineer, and a programmer were in a car driving over a steep alpine pass when the brakes failed. The car went faster and faster, they were struggling to get around the corners, and once or twice the flimsy crash barrier saved them from tumbling down the side of the mountain. They were sure they were all going to die, when suddenly they spotted an escape lane. They pulled into the escape lane, and came safely to a halt.
The physicist said, “We need to model the friction in the brake pads and the resultant temperature rise, and see if we can work out why they failed.”
The structural engineer said, “I think I’ve got a few spanners in the back. I’ll take a look and see if I can work out what’s wrong.”
The programmer said, “Why don’t we see if it’s reproducible?”
Anonymous
From Boris Cherny's excellent book on TypeScript. This one is related to another one of my favorite programming quotes:
Everybody has a testing environment. Some people are lucky enough to have a totally separate environment to run production in.