Theses gems stuck out for me:
Eighty percent of all input forms ask questions they have no business asking.
A procedure should fit on a page.
And especially: Don’t make the user provide information that the system already knows.
This happens all the time, especially in e-commerce. And even moreso in paper form. For example, every time I go to a new doctor, I have to fill out 15 forms and 15 times I have to write down my name, address, SSN, insurance id, etc... Why can't the doctor's office, which already knows all of that, just print out 15 forms with all of that pre-populated?
Somewhat related: We build so many input forms demanding people provide data to the computer in a form that the computer can immediately read. The computer should work for the user, not the other way around.
Example: The FCC's Do Not Call web site has notes on its input fields that phone numbers have to be entered as numbers only. No dashes, parentheses, etc... How about the web site take whatever is input and strip out anything that's not a number? So basic, but I see this all the time.
Which brings us the principle:
Never ask a question whose answer you already know
If you know the answer already, why does the question exist on a form?
For the CS/programming side of it -- do you really know what you think you know? A smart form should let you put in house address and ZIP and look up the rest, but frequently developers think they know more than they actually do, and it's not a bad idea to have the user confirm or possibly override the information. Depends on the situation, really.
No you do not.
Anecdotal: I always leave that field blank and have never been asked for it.
Anyone can ask you for anything, anywhere. It doesn't mean they actually need it, or that you have to give it to them.
I went to a dealer to buy a car in cash (well, a cashier's check). They had a touch-screen computer with all their forms for me to fill out. It came to a credit approval/application form, and I refused to fill it out because I wasn't opening a loan. The lady assured me it was "standard" and that it wouldn't be used for anything, because I didn't need the loan/credit. I kept refusing, and she kept insisting they only needed it because the software required it to continue. After this impasse, I stood to walk out, and she suddenly changed her tune and somehow "figured out" how to bypass the form. Classy.
That's why they had a cashier's check and not a personal check.
Because, considering it sounds like you bought the car outright, there's absolutely no reason for that form to need signing.
> You are not required to have a social security number to open a checking or savings account.
Having spent more than a few years in FinTech, I know these things can vary from company to company as companies generally are required to design their own “risk-based” policies for AML and KYC.
(I'm not undocumented, but I imagine they see that enough which is why they don't bother saying anything when I leave it blank.)
I'm pretty sure they just want your SSN for collections/credit-reporting purposes.
Yet still, today, its a very rarely encountered technique. I wonder if so much has changed in the Zip+4 world to make it an efficiency sink...
Backwards paper systems serving the moneyed interests.
- change your damn passwords!
- reset the damn cache!
- say no to your damn project manager!
- use the damn frameworks!
- stop creating the damn global variables!
- don't use the damn "!important"!
They've assembled a database of probably a few thousands of those wisdoms for different industries and it's truly entertaining. They've added an API too.
Sadly it's not in English.
If you use !important, you either understand CSS very well, or don't understand it at all.
Someone probably knows of a targeted resource or two that may help.
Order of precedence is the hardest thing for me to figure out, if I have three nested <div>s and a couple of <li> elements and all of them with a conflicting fontColor property, which one takes precedence? If I think really hard and trace back all the code, I can figure it out. Or I can put an !important on it and future me will deal with the consequences.
You can paste in a series of selectors (getting new boxes by clicking "duplicate"), then hit "Sort by specificity".
"If you lie to the computer, it will get you."
From my observation at work, I'd change this to:
"If you lie to the computer, it will let you."
Lots of people who take computer output as gospel. They never get, GIGO.
It let you lie to it, and then it got you.
> [Conservation of Code Size] When you turn an ordinary
page of code into just a handful of instructions for
speed, expand the comments to keep the number of
source lines, constant.
"There are two ways of constructing software. One way is to make it so simple that there are obviously no deficiencies. The other is to make it so complex that there are no obvious deficiencies."
"The purpose of software engineering is to control complexity, not to create it."
Dr. Pamela Zave
"The most important single aspect of software development is to be clear about what you are trying to build."
"The cardinal sin is to make a choice without knowing you are making one."
"Good code is short, simple, and symmetrical - the challenge is figuring out how to get there."
"The ability to simplify means to eliminate the unnecessary so that the necessary may speak."
"Any intelligent fool can make things bigger, more complex, more violent. It takes a touch of genius - and a lot of courage - to move in the opposite direction."
"The cost of adding a feature isn't just the time it takes to code it. The cost also includes the addition of an obstacle to future expansion... the trick is to pick features that don't fight each other."
"If we'd asked the customers what they wanted, they would have said, "faster horses."
"What I cannot create, I do not understand."
"Such is modern computing: everything simple is made too complicated because it's easy to fiddle with: everything complicated stays complicated because it is hard to fix."
"A program is a poem: you cannot write a poem without writing it. Yet people talk about programming as if it were a production process and measure "programmer productivity" in terms of "number of lines of code produced." In doing so they book that number on the wrong side of the ledger: We should always refer to "the number of lines of code spent."
"As a programmer, it's your job to put yourself out-of-business. What you can do today can be automated tomorrow."
"The whole point of getting things done is knowing what to leave undone."
"Simplicity is hard to build, easy to use, and hard to charge for. Complexity is easy to build, hard to use, and easy to charge for."
"Knowledge is a process of piling up facts. Wisdom lies in simplification."
Martin Luther King, Jr.
"Measuring programming progress by lines of code is like measuring aircraft building progress by weight."
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."
"It ain't what you don't know that gets you in trouble. It's what you know for sure that just ain't so."
"Be careful that victories do not carry the seeds of future defeats."
"The most effective debugging tool is still careful thought, coupled with judiciously placed print statements."
"Controlling complexity is the essence of computer programming."
"Simplicity is prerequisite for reliability."
"...but there is one quality that cannot be purchased that way - and that is reliability. The price of reliability is the pursuit of the utmost simplicity. It is a price which the very rich find most hard to pay."
"UNIX is simple. It just takes a genius to understand its simplicity."
"Complexity kills. It sucks the life out of developers, it makes products difficult to plan, build, and test, it introduces security challenges and it causes end-users and administrators frustration."
"A charlatan makes obscure what is clear; a thinker makes clear what is obscure."
"Fools ignore complexity, pragmatists suffer it. Some can avoid it. Geniuses remove it."
Them: We need to add this feature for completeness.
Me: We do not need that feature to ship and make money.
Them: If we don't we're creating technical debt!
Me: You want to create a feature that needs to be maintained that isn't used in production. That's worse.
Them: It won't be finished until this feature is added.
Me: The program will never be finished.
Them: You're being unnecessarily difficult.
^^ conversation last week.
Interesting that people were aware about the Y2K problem 15 years before, but it still required so much work to correct. I guess it's kind of similar to the Year 2038 problem (https://en.wikipedia.org/wiki/Year_2038_problem) and how nobody cares about it yet