feature article
Subscribe Now

Learn Programming from Facebook!

Social Media Can Teach Us a Lot About Good Coding

“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.

One thought on “Learn Programming from Facebook!”

Leave a Reply

featured blogs
Aug 14, 2018
I worked at HP in Ft. Collins, Colorado back in the 1970s. It was a heady experience. We were designing and building early, pre-PC desktop computers and we owned the market back then. The division I worked for eventually migrated to 32-bit workstations, chased from the deskto...
Aug 14, 2018
'€œPrediction is difficult, especially the future.'€ '€” Niels Bohr Okay, in my post last week , I revealed that I was a deterministic Newtonian, and my reasoning was about two hundred years old. I posited, '€œIf I could identify all the forces and weights and measur...
Aug 14, 2018
Introducing the culmination of months of handwork and collaboration. The Hitchhikers Guide to PCB Design is a play off the original Douglas Adams novel and contains over 100 pages of contains......
Aug 9, 2018
In July we rolled out several new content updates to the website, as well as a brand new streamlined checkout experience. We also made some updates to the recently released FSE locator tool to make it far easier to find your local Samtec FSE. Here are the major web updates fo...
Jul 30, 2018
As discussed in part 1 of this blog post, each instance of an Achronix Speedcore eFPGA in your ASIC or SoC design must be configured after the system powers up because Speedcore eFPGAs employ nonvolatile SRAM technology to store its configuration bits. The time required to pr...