“Lotteries are a tax on people who are bad at math.” — anonymous
We’ve all been there. Your friend posts something stupid on Facebook, so you add a comment, patiently pointing out that they’ve mindlessly forwarded some bogus, ill-informed, or downright fabricated meme as if it were gospel truth. No, the airlines are not giving away free tickets today to celebrate their anniversary. Diet soda is not rotting your stomach. And an asteroid is not about to destroy Earth (but if you’re worried, please send all your money to me).
This time, a good friend evidently felt she’d discovered a brilliant solution to an old problem. Maybe you’ve seen it, too; it’s certainly made the rounds. If you’ve somehow been spared, the message goes something like this: The current lottery jackpot is $X million. There are Y million people living in the United States. So why not divide it equally and give everybody a couple million dollars?
Poverty solved! Deficits wiped away! All through a simple redistribution of wealth. It’s so easy, why didn’t anyone think of this before? I’m a genius.
After you finish your face-palm, we’ll look at how this little gem applies to coding practice. As far as I can tell, there are at least eight things wrong with this. But first, an aside.
Why is it that all Internet memes are so badly written? Is that part of the joke, or is it unintentional? For example, why are some words capitalized and others not? And what’s with the random punctuation? Is there some rule buried in Facebook’s ToS that requires stupid memes to always be posted as poor-quality GIFs with fractured English? Maybe it’s a hidden signal for identifying hacker trolling. There is a strong correlation between bogus memes and poor writing skills. Does that mean that they’re all created by overseas troll factories? Or are conspiracy-minded Americans’ English skills really that bad? Maybe the mistakes are intended to make these things look more hand-crafted, grassroots, or artisanal. Perspiring minds want to know.
Language gripes aside, there’s a lot we can learn from this little nugget of financial wisdom.
1. Punctuation Matters
A missed semicolon in a C program can cause mountains of grief. Confusing = with == is an easy mistake to miss. And it’s awfully easy to lose track of apostrophes when you’re delimiting strings. Where’s the problem in this line?
std::string str = R”(The ‘\n’ character is here)” “\n” “and here”;
2. Capitalization Matters
Seventeen different variables can all have the same name capitalized differently, and most compilers won’t balk. It may be hard to keep straight in your head, but it’s legit code. There’s no good reason (well, almost no good reason) to invent variable names so similar that they differ only in their capitalization, so if you do it anyway, woe betide you.
3. Mistakes in Magnitude
The real problem with the lottery meme is that the math is wrong, but it’s wrong in an insidious way. Specifically, it’s off by a factor of a million – that’s six orders of magnitude – but it seems many of us can’t count zeroes in our heads. It’s easy when you’re dealing with small numbers like a restaurant bill, but harder when you’re talking about the national debt. Nobody I know leaves the waiter a $40,000 tip because they lost track of the zeroes, but many people (apparently) can be fooled into thinking that a million divided by a million is still a million.
4. Keep Looking
The single greatest lesson I learned from being a programmer: just because you’ve found one problem doesn’t mean you’ve found the problem. You can hunt for hours to find a bug in your code, and when you finally fix it, you pat yourself on the back, recompile, and wait for the beautiful result – only to find that it’s actually gotten worse. Not only did you not fix the bug, you screwed up something that was working just fine. Or, you did fix a bug, but not the one you were looking for. The original bug is still there; the one you fixed was latent and undiscovered. Kudos for fixing it, but there’s still work to do. Don’t give up so soon.
5. Math Matters
Check your math. Not just for orders of magnitude, but also for the basic arithmetic. Get out a calculator. Work it out with pencil and paper. Type it into a spreadsheet. Entering and re-entering those numbers can jog your brain into realizing that you’re not using the right numbers, or that you’re using the right numbers in the wrong places. It’s too easy to get complacent and stop looking at your digits because you think they’re already correct. Also, the population of the U.S. is closer to 326 million, so you’re about $170,000 too generous.
6. Read It Out Loud
Take a tip from actors and read your lines aloud. Sure, it sounds funny when you’re reciting printf poetry, but it’ll also help you spot problems like misspelled variable names because you’ll want to pronounce them differently. Reading out loud exercises different faculties than reading silently. Listening to yourself triggers internal proofing mechanisms.
7. Ask for Feedback
There’s a lot to be said for having another set of eyes. Instead of reading your own code, ask someone else to have a look. If you believe your code is correct, you won’t find any mistakes. Outsiders have no such blinders.
If you really want feedback, publish it to the world. Redditers will point out your shortcomings in no uncertain terms.
8. Assume You’re Wrong
It’s hard to find evidence of something you don’t believe exists. Thousands who read the chalkboard above already believed the math was correct and swiftly moved on to “explain” the social ramifications. But the fundamental premise was ludicrously wrong, rendering all further arguments moot. Start with the basics, nurture healthy skepticism, and remember what they say about assumptions.
Nobody enjoys scanning their own code out of a sense of duty or because their boss told them to. Turn it into a game. Tell yourself that there is a bug; you just have to find it. Chances are, you’ll be right.