The things we got wrong
This is not a list of what we do well. It’s a log of what we got wrong—and how we fixed it. A site like this only publishes corrections if it keeps them, so every entry here is real, ordinary, and signed.
You’ll find no humblebrags, no failures that turn into strengths. Just the mistakes that slipped through, the methods that broke in practice, and the pages that should never have gone out. The reader gets a way to judge everything else by what we got wrong first.
Three we had to fix
Three failures stand out—the ones that cost us the most time, trust, or credibility. They’re listed below, most consequential first, with the person who caught or fixed them named in each.
Three failures we fixed
- 1A broken terminal guide
The *‘10 Hidden Bash Commands’* guide promised users could ‘delete files silently’ with `rm -rf /`—a real command, but one that would wipe a system. It stayed live for 48 hours before a reader flagged it. We pulled it, rewrote the section with safe alternatives, and added a warning banner to every terminal tutorial.
- 2A misquoted Linux kernel doc
The *‘How to Compile a Kernel’* article cited a kernel version that didn’t exist—our own typo. It went unnoticed for three months until a reader emailed us the correct line from the actual source. We updated the page, added a verification step, and now cross-check every command against official docs. Shawna Halloran verified the fix and published the correction.
- 3A PowerPoint shortcut that didn’t work
The *‘10 Office Shortcuts You’re Missing’* list included `Ctrl+Shift+F` for ‘find and replace in slides’—but it only works in Word. It stayed up for two weeks before a freelance trainer pointed it out. We replaced it with `Ctrl+H`, tested every shortcut in the actual software, and now require real-world validation before publishing. Shawna Halloran updated the guide and added a ‘tested in [version]’ note.
What those three changed
These failures forced three permanent rules: no undocumented commands, no unverified sources, and no shortcuts without testing. The log exists because keeping it is the only way to trust the work.
Rules that came from mistakes
- 1. No dangerous commands without warnings (from the broken terminal guide). Every tutorial now flags destructive actions in bold and requires a second verification step.
- 2. Every cited version must be real and linked (from the misquoted kernel doc). We now pull directly from official repositories and include exact URLs.
- 3. Shortcuts must be tested in the actual software (from the PowerPoint fail). No more copy-pasted lists—every tip is validated by running it ourselves.
The people behind this
Shawna Halloran is the founder and editor of *Calendar Tips*, where she turns tech chaos into clear steps. You’ve just met her through her mistakes—which is the most honest way to introduce someone who runs a site like this.
Keeping a log like this means admitting when the work fails, even when it’s uncomfortable. The first time she published a correction, she stayed up half the night wondering if readers would think she was careless. They didn’t. They trusted it more.
One mistake that never made it here? The time she reformatted a hard drive *twice* because she misread the confirmation prompt. The second time, she lost a year’s worth of notes. She still winces when she sees `Shift+Del` in a guide.
If you find a mistake in our work, the contact page is where to send it. No email address, no performance—just the fix, signed.
There will be a next one
This log isn’t finished. When a reader finds something wrong—or when we do—it gets added here. The next entry might be a missed edge case, a typo in a code block, or a guide that assumed the wrong operating system.
If you spot one, the contact page is where to tell us.
The guides are grouped by category: App, Coding, Operating System, Outlook, PowerPoint and Review.