Resources Show Devs How Much They Don’t Know

Devs may have holes in their knowledge base.

Developers live at the intersection of knowledgeable and efficient. This can prove a struggle, and rarely leaves much wiggle room in either direction. Sadly, “knowledge” pays the price more often. A handful of resources show devs just how much they might be getting wrong.

For iOS devs, it’s NSDateFormatter.com, which will make you feel as though you can’t actually read a calendar properly. You can, don’t worry; it’s just a good example of how, when it comes to humans speaking computer, the translation isn’t always clear. At various points, the ‘month’ is either MMM, MM or MMMM, and can be designated via dot notation, dashes, commas, forward slashes or spaces. Good luck.

Because dates and times are also hard to grasp, we’ve found a second site you should check out: yourcalendricalfallacyis.com. Described as a site that will help you “navigate the insane complexity of calendrically [sic] correct date and time operations,” it dives a bit deeper into why times and dates elude us. It’s a collection of assumptions we make about calendars, such as what a weekend is, or that days always have 24 hours (by the way: false!).

As not everything involves dates and times, there’s also a GitHub repo tracking everything we’re probably wrong about. ‘Awesome Falsehood’ is an evolving collection of everything we think we know about computer science disciplines, but just might be wrong about.

Like most repos of its ilk, Awesome Falsehood is simply a collection of links to topics covered more granularly elsewhere, by people who are likely dedicating their efforts (or at least a project or two) to a topic. It spans everything from codifying music to validating emails. There’s even more discussion about calendars, if you’re not ready to ignore time for the rest of time yet.

While it might seem a bit pretentious for a site to explain topics you’ve mis-characterized, it comes from a good place. Based on the description of the types of articles that get into Awesome Falsehood, it seems the goal is to destroy naiveté:

These articles starts [sic] with the hypothesis that developers have a naive, simple view of the subject at hand. Then proceed to list a set of candid assumptions that might be held by such programmers. Each one is intentionally false, and sometimes illustrated by a counter-example.

While it admits “these articles might provoke an emotional reaction and cause flipping table [sic],” Awesome Falsehood’s reasoning for surfacing them is nonetheless valid. Being corrected is never fun, but at least it’s just the interwebz and you can lick your wounds in silence.

Comments

2 Responses to “Resources Show Devs How Much They Don’t Know”

March 24, 2017 at 12:00 pm, RobS said:

Then there’s the assumption that a byte is 8 bits.
But in my school’s computer (1980) the computer was a 9-bit processor for some reason so all of those bytes were 9 bits. (I assume that one bit was for check-digit, but not really sure.)

Oh, and the assumption that computers work with 0s and 1s? Of course not: they work with electrical charges with high flow (traditionally called 1) and low flow (the 0).

And love teaching my students about color…how blue+yellow does not produce green…well, it does with crayons but not with light and computer monitors (or your eye sensor), which treats yellow as a combination of bright red+bright green (you know, that whole RGB stuff…)

Although the article was pretentious in its presentation, it was fun to re-research some of the topics it discussed, making it worthwhile after all 🙂

Reply

March 30, 2017 at 4:28 pm, Steve said:

Not disagreeing with you….

There are published materials that say a nibble is 4 bits, a bits is 8 bits, and a word is 16 bits.

There are also materials which say that a ‘word’ is the width of the computers data bus. Therefore, it could be 8 bits. or 16. Or something else. 12 bits. A lot of other word sizes have been used.

I went to a university once where they changed from a 63-bit computer to a 64-bit computer, and it ‘broke’ a number of Fortran programs used for some administrative projects.

I hope you also teach your students about endianness, and memory-mapped I/O, too.

Reply

Post a Comment

Your email address will not be published.