Alexisms
Sayings I use, only some of which I originally said. Anyone with research on a saying's provenance or attribution, please let me know.
A comment is a lie waiting to happen.
Which is not to say comments are bad. But they should illuminate the code, not merely describe it.
I had a problem, so I used microservices. Now I have N^2 problems.
for "microservices" you may substitute "Service-Oriented Architecture" or "distributed system"
We used to have a different name for microservices. We called them "objects" and they had encapsulation and interfaces and unit tests and exceptions and everything. They were pretty fast too, since they ran in-process! Give me a refactorable, hot-deployable, OO monolith over a million microservices any day.
Technology is anything that wasn't around when you were born. (Alan Kay)
"Legacy" means any program that people are actually using.
(Feathers: "Legacy" means "no tests.")
Double negatives are not unconfusing.
The confusion is multiplied in conditionals and booleans, e.g. if not window.disabled.
So try to name all your booleans in the positive, e.g. window.show() not window.setInvisible(false).
The only perfect program is an empty file.
There's no such thing as human error, just flawed systems that include humans.
If a human of good intent made a mistake, then the fault lies in the system that allowed him to make that mistake and then allowed that mistake to survive without being noticed or corrected.
Playing the Five Whys game can help expose the root causes of these mistakes.
See also this twitter thread
every config file eventually becomes Turing-complete
see also http://beza1e1.tuxen.de/articles/accidentally_turing_complete.html https://stackoverflow.com/questions/648246/at-what-point-does-a-config-file-become-a-programming-language
It's always a people problem. (Jerry Weinberg)
If you pay attention to something, it gets better.
You can see a lot just by looking. (Yogi Berra)
Mr. Berra wrote a book called "You Can Observe A Lot By Watching" but I prefer to think he was misquoting himself.
Language Log has a take on this quote: She was seeing at me.
Read the error message.
Even if it looks like total barf, there are pearls in there, and you have to roll up your sleeves and feel around for them.
"Never solve a general problem. There are no general problems." (William Pietri)
https://clarity.fm/questions/946/answers/2941
Premature generalization is almost as bad as premature optimization.
Object-Oriented Programming is like teenage sex: ...
...everyone says they're doing it; few actually are; and those who are rarely know what they're doing. (Anonymous, via Misko)
Here's a simple test for whether you're doing it right: Is your data in the same class as the methods accessing it? Oh, really? Check again.
Encapsulation means putting similar things together, and keeping dissimilar things apart.
Of course, the trick of design is knowing along what axes to group or differentiate items. One rule of thumb that has served me well since the days of Gamelan -- when we were sorting dozens of incoming applets per day into categories -- is:
Don't look at the item and think, "What category does this item belong in? Look at the category and think, "If I were looking for items in this category, would I want to find this item?"
In other words, make your API fit the mindset of the user, not that of the provider.
Conway's Law: "Any piece of software reflects the organizational structure that produced it."
Or, "The structure of the code reflects the structure of the coders."