If Something is Odd, Inappropriate, Confusing, or Boring, It Is Probably Important.
That guy smiling at you is my Dad, David McEachen. He taught English Literature to a surprisingly large portion of the teenagers growing up in Santa Barbara from 1965 to 2004.
I’ll do the math for you: that’s 39 years where most of your day is spent with teenagers.
He was a brave man.
To be fair, he told us many times that he loved his job, and that he couldn’t imagine doing anything differently. But still. Teenagers. And walking them through arcane convolutions and labyrinthine mind-twisters that could only be described as Shakespearean. Because, Shakespeare.
His class motto:
If Something is Odd, Inappropriate, Confusing, or Boring, it is Probably Important.
He didn’t just use this motto—he and researcher Lesley A. Rex published academic research about this practice.
The study documented how this approach transformed how students engaged with literature, particularly by making confusion itself the starting point for learning rather than something to hide.
🧠 Your biases don’t always help
Our brains are excellent at discerning the patterns we’re expecting, and astoundingly bad at noticing things we aren’t expecting. This is typically characterized as belief bias, or an application of confirmation bias to reduce cognitive dissonance. The Selective Attention Test is gobsmacking.
This hard-wired, ham-fisted heuristic to dismiss the unexpected is a death knell for understanding anything nuanced: English literature, responsible governance, software engineering. Pretty much everything.
The surprising plot twists and character motivations, unintended legislative consequences, bonkers firmware: those are all wells of oddness and founts of confusion. They’re also the most critical parts to study.
🤔 Dad’s solution: ask “why”
My Dad’s solution was to regularly ask his students, “Why?” and encourage them to stop, think, and share.
“The author had led us here, and could easily have played out what we expected. So, why didn’t they?”
His favorite play was King Lear. All that sorrow and regret and jealousy and naked violence and bile. Confusing as hell to teenagers. But he’d walk the class through each character’s motivations: how could Lear’s beloved daughters turn against their father so viciously? Understanding the “why” behind the confusing parts was the whole point.
Asking “why” can be embarrassing: did I not get it because I’m dumb? Dad normalized confusion by making it the starting point for group discovery. When a student said “I don’t get it,” there was never shame, only opportunity. His favorite trick when someone was distracted? Tell them to help their neighbor follow along. Everyone stays engaged, and the student who was struggling gets to be the expert helping someone else.
Thinking about the “why” helps you break through your WTF-block and actually understand what you’re studying.
🌍 When you can’t just log in and poke around
For my entire professional career before PhotoStructure, when my code broke, I could fix it. The servers were in racks I could log into. The databases were on machines I could access. Something weird at 3am? SSH in and investigate.
But PhotoStructure runs on other people’s computers.
Thousands of different configurations. Windows, macOS, Linux, Docker, NAS, UnRAID, TrueNAS. Everyone’s setup is different. I have six physical test rigs, and my test suite runs more than 10,000 unit and integration tests on all of them. Even that can’t catch everything that happens in the wild.
When something breaks in production, I can’t just log in and investigate. Debug logs might help, but most users don’t enable them—they slow everything down, and reproducing an issue with debug logging enabled is asking a lot. Sentry crash reports sometimes help, but when issues only crop up under specific concurrent situations, the stacktrace rarely gives you a clue as to what actually went wrong.
Which means PhotoStructure’s behavior on other people’s computers is always odd, frequently inappropriate, and certainly confusing.
Dad’s class motto always echoes in my head: pay attention to the weird stuff. It’s probably important.
📸 Everything about media metadata is bonkers
Take camera metadata: there are more than 30 different tags that might—or might not—store the time that a photo was captured. Thirty. Different. Tags.
Canon does it one way. Nikon does it differently. Sony has their own approach. Even different models from the same manufacturer aren’t consistent. Hell, the same camera will write different metadata depending on whether you’re shooting RAW or JPEG.
Time zones? Sometimes included, usually not. Date format? Could be anything.
Depending on your location and account type, Google Takeout will happily edit your photos’ metadata before giving them back to you. GPS coordinates might be stripped. The captured-at time might be “improved” with an AI hallucination. Your photo gets renamed to a UUID—and the JSON sidecar with additional metadata might be {uuid}.json, or might be {most-of-uuid}.json with a few random characters shaved off the end. I had to teach PhotoStructure how to deal with that mess.
Some photo exports (including Google Takeout) use the wrong file extension entirely. I check the file’s magic bytes to determine the actual format before processing.
And my personal favorite: Some iPhones store depth information in metadata tags that are normally reserved for embedded preview images. This caused what I can only describe as “ghostly depthmap hijinks” until I taught PhotoStructure to detect and skip them specifically.
📝 Marking the odd and confusing stuff
At a Y Combinator dinner, Paul Buchheit, who created Gmail, gave me advice about how to keep codebases clean.
Oh, that’s simple!
Don’t let anyone shit in the soup.
The bluntness caught me off guard, but the message stuck.
Sure: avoid bad commits. Keep the codebase pristine and elegant.
But sometimes you can’t avoid it. The platform is broken. The library has a bug. The performance of the “elegant” solution doesn’t scale. You have to make the mess.
The problem is, ten months from now, you’ll see some weird lump of code and wonder: is this a scrumptious meatball, or…not? If there’s a flag in it, you’ll know.
That’s what SITS comments are for—flags marking the necessary evil. “Situation Is Totally Suboptimal” if you want the family-friendly version. There are more than 40 of them in PhotoStructure’s codebase, in equal doses of shame and pragmatism.
Here’s a real one:
# YAML SITS! You can't merge lists with aliases! BOO!
And another:
// SITS: macOS sometimes locks files when they've been copied. No, I couldn't
// find out why, but if I own the file, I can chflags the file back to being
// unlocked.
These aren’t elegant solutions. They’re not the code I wish I could write. But they’re the code that works given the constraints of reality.
When I encounter that weird file unlocking dance later, the comment tells me: this isn’t broken code. It’s intentionally weird code, because macOS is weird.
Most often, what makes code odd, inappropriate, or confusing is not being able to discern the why.
When you suspect a module won’t be intuitive to the casual observer, add a comment explaining why you made the choices you did. Link to other documentation, related modules, conversations, or design documents. Everything helps.
Trust that the Engineers of Tomorrow can read your code: they can answer the how for themselves.
The why slips away into oblivion all too easily. Even when you wrote it.
😴 The overnight rule
When I get a bug report without a clear reproduction case, my immediate reaction is skepticism. It’s probably user error, right?
I’ve learned to wait a day.
After a sleep cycle, I come back and ask: “Is there a simple way for me to reproduce this?”
Usually, there is—and it often reveals something unexpected: file oddness, metadata confusion, or a system setup quirk I need to teach PhotoStructure how to handle gracefully.
This scenario has happened dozens of times with metadata inference in exiftool-vendored. User reports something that seems impossible. I sleep on it. I wake up and realize I was making assumptions about metadata that only hold true for 95% of cameras. That other 5%? Odd, confusing, and absolutely critical to handle correctly.
Dad’s class motto has probably saved PhotoStructure from dozens of “works on my machine” shipped bugs.
All of this (the SITS comments, the overnight rule, the obsession with explaining “why”) is really just annotation: leaving notes about what seemed odd and why it matters.
📚 The inheritance
Dad taught English for 39 years. He kept annotated copies of every book his students read: passages highlighted, notes in the margins about what confused last year’s class, reminders of which metaphors needed discussion.
He didn’t do this because his students were slow. He did it because Shakespeare and Chaucer are genuinely confusing. The odd parts, the inappropriate violence, the boring soliloquies—those needed the most discussion.
I annotate my code for the same reason.
Not because the Engineers of Tomorrow are slow. But because platforms are weird, vendors are inconsistent, and six months from now, I’ll be the Engineer of Tomorrow looking at my own code thinking “What the hell was I thinking?”
The banner photo at the top was taken a week before he died in 2010. The next day he spent running around Disneyland’s Tom Sawyer Island with his grandsons. Four days later, during a Wednesday sailboat race, he felt tired and went below deck to take a nap. When his crew checked on him, he was gone.
“I’m just happy to be around you guys”: that was his everyday face, right up to the end.
Decades after sitting in his classroom, his class motto proves itself true again and again, one SITS comment at a time.
💡 TL;DR: If it’s odd, it’s probably important
When you write something that’s necessarily weird (a performance hack, a platform quirk, a workaround for broken metadata parsers), add a comment explaining why.
Link to the bug report. Link to the vendor documentation that’s wrong. Quote the StackOverflow thread. Everything helps.
Be wary when you think something is odd, confusing, or just straight-up broken. Keep in mind how our brains are wired to dismiss the unexpected.
And mark the weird stuff while you still remember why it’s weird.
Future you will thank present you.
