The things we got wrong
This page isn’t a list of what we do right. It’s a log of what we did wrong—three mistakes that made it into the site before we caught them, and how we fixed them.
The reader gets two things: a way to judge whether we’d do the same thing again, and proof that we keep our own log.
Most sites hide their failures. We publish them because the only way to trust a tech guide is to know it’s been tested, corrected, and tested again. If you find something here that’s still wrong, that’s the point.
Three we had to fix
These are the mistakes that slipped past us. Each one was real, each one was fixed, and each one taught us something we still use today.
How we fixed our biggest mistakes
- 1Linux guide with broken commands
A tutorial on setting up a Linux desktop included commands that wouldn’t run on Ubuntu 22.04. It went live for three days before a reader flagged it. The fix? Rewriting the steps from scratch and adding a compatibility table for different distros. Rafael Vasquez caught it after the fact and made sure every Linux guide now includes a tested version for three major distros.
- 2Windows update that wasn’t possible
A troubleshooting guide for a Windows 11 update recommended a registry edit that Microsoft had removed in the latest patch. It stayed up for a week before a reader’s screenshot proved it was wrong. We replaced the steps with a verified workaround and added a note about checking Microsoft’s support page first. Rafael Vasquez rewrote the section and added a ‘last verified’ date to every troubleshooting article.
- 3PowerPoint tip that crashed the app
A productivity tip for PowerPoint included a macro that locked up the software on older versions. It was live for two days before a reader’s error log confirmed it. The fix was to replace the macro with a manual method and warn about version compatibility. Rafael Vasquez now requires every software tip to be tested on three versions before publication.
What those three changed
The mistakes forced us to build new rules. Now, every guide has a ‘last tested’ label, every troubleshooting step is verified against Microsoft’s latest updates, and macros or scripts are tested on three software versions before they’re published.
Rules that came from mistakes
- Every tech guide must include a ‘last tested’ date (from the Linux command mistake).
- Troubleshooting steps are verified against official Microsoft documentation (from the Windows update mistake).
- Scripts and macros are tested on three software versions before publication (from the PowerPoint crash mistake).
The people behind this
Rafael Vasquez is the founder and editor of *Formula Help*. You’ve just read three mistakes he fixed—each one a reminder that even the best guides need corrections. He runs the site because he remembers the frustration of following a tutorial that didn’t work, and he refuses to let that happen here.
Keeping a log of mistakes isn’t comfortable. It means admitting that even after testing, something can still be wrong. But that’s the only way to build trust: by showing the work, not just the result.
Rafael started this site after years of fixing his own tech problems, and the log is proof that he still does.
One mistake that wasn’t public? The first time he wrote a Windows troubleshooting guide, he accidentally included a step that would have bricked a user’s BIOS. He caught it before it went live, but the near-miss taught him to double-check every low-level command—even the ones he’s used a hundred times.
If you find something wrong on *Formula Help*, the next step is simple: tell us. The contact page is where to send it.
There will be a next one
This list isn’t finished. If you spot a wrong number, a broken method, or a guide that doesn’t work, we want to know. The contact page is where to report it—no email needed, no form to fill out. Just the mistake, and we’ll fix it.
The guides are grouped by category: App, Coding, Hardware, Operating System, Outlook and PowerPoint.