“Data dominates. If you’ve chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming.”
~Rob Pike, Notes on C Programming
In the old days there was a UI/UX rule that seems to have been forgotten by a lot of designers:
If you don’t know what to do in regards to (a) notifying users about something, or (b) choosing a default value when displaying something, don’t do anything. Don’t guess.
When you ignore this rule, you tend to piss off your users.
Several UI/UX design decisions in my 2015 Subaru provide great examples of violating this simple rule. In the first example, yesterday it was perfectly sunny here, the roads were completely dry, but when the temperature changed to 37 degrees Fahrenheit, there was a “bling” noise in my car. When I looked at the dashboard the car was warning me that the road — which was incredibly, completely dry for miles upon miles — could possibly be icy. This was a completely useless and annoying notification.
Another dumb thing about the car is that the rearview mirror displays text to show you what direction the car is facing by default. Every time I start the car I have to (a) turn on the ignition, and then (b) press a button on the rearview mirror to turn that text off. Seriously, how many people in the world need to know what direction they’re facing when they start their car?
I could go on for a while, but as I wrote in the first paragraph, if you’re in doubt about providing a default value for something or notifying human beings about things, be sure you’re right — don’t guess.
This is a great quote about software development from Ward Cunningham in this 2012 Dr. Dobbs article:
“Some people might have used that word (refactoring), but even when I talked about it in an often-quoted paper, I think I called that consolidation, not refactoring. In other words, you figure out what it should have been, and you make it that. Whereas the prevailing wisdom at the time was, ‘If it’s not broke, don’t fix it.’ So the first time you got something working, you quit. That’s not a way to make great code.”
The part I italicized is a great description of refactoring: You figure out what the code should have been, and you make it that. As developers we always try to make code right the first time, but it seems like we always learn more about the project and the relationships between code elements as we go along, and so we do a lot of refactoring, or “housekeeping,” which is another word that Mr. Cunningham uses in that article.
“The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise.”
~ Edsger Dijkstra
“There is no programming language, no matter how structured, that will prevent programmers from making bad programs.”
~ Larry Flon (quoted in the year 1975)
“Avoid requiring something to be stated more than once; factor out the recurring pattern.” - Bruce J. MacLennan
“If debugging is the process of removing software bugs, then programming must be the process of putting them in.”
~ Edsger Dijkstra
“Never be afraid to completely isolate yourself from the world, and code like an animal.”
~ Randall Degges
