Keep the beams standing. Replace what they carry.
— The 36 Stratagems, Replace the beams with rotten timbers
Previously on this series:
#23:...
For further actions, you may consider blocking this person and/or reporting abuse
I'm seriously gunna try take 2 hours or so the weekend to catch up, just been too hectic lately, but I'll do my best to read up to date on the weekend 👊
Haha, I'll sit tight and wait for you to catch up. The story's not going anywhere. Focus on your own things first – and here's to both of us landing great jobs soon!👊
We'll do it! Thoughts and prayers with you my friend, I know the Chinese job market is ruthless, you'll land a goodie though! Maybe have a look at Moonshot? Surprisingly AI companies prefer people who dont use it all that often 😂
Moonshot? Man, you're overthinking it, lol. I'm realistic about myself. But if writing actually takes off, I might just end up changing careers after all🤣
Hey, you never know, you might just be underselling yourself? You know how many people land jobs based on luck? Not to mention, if you reference your writing work, you might have a solid shot at Developer Advocate? Your job would essentially be engaging with the community, which I think you'd do great at!
I just imagined myself dressed as a mage, throwing a 'keyboard APM +50%' buff aura on all the R&D guys🤣
I’ve been following your writing for a while.
Good writing skills and technical expertise—it’s a rare combination.
A suggestion: If you enjoy teaching, you could write a book on QA for beginners, perhaps in the style of The Manga Guide to Physics. Or, you could create a high-quality online course.
Good point! I’ll try to share more of my QA journey and some starter tips later. Just hope my old-school QA skills can survive the AI wave… Ah well, maybe taking it slow is the new fast these days.😂
The sixth test is the whole story. Five analyses of existing data, three green and two gray, all of it consistent with a profile that held. Then one environment change and the thing collapses in a single visit.
You can't detect a performance by analysing the performance harder. Derek recomputed ten percent by hand, ran reverse validation, filtered anomalies, and every check passed, because the data was never wrong. It was authentic data about a fiction. The only thing that broke it was making the environment do something the script had no branch for.
New features per visit: eight, six, five, then three, three, three. He paused on that cell for half a second and kept going. Variance too low is an anomaly, and it's the hardest kind to catch, because every monitoring instinct we have is tuned for the outlier rather than its absence. A curve drawn with a ruler should be as alarming as a spike.
One thing I'd push on, and I suspect Derek knows, given he named the file 0 rather than 2.0.
The 70/30 split is right in principle. Kernel jitter, scheduler drift and stray SYNs are far harder to author than an auth sequence. But that 30% is still a property of infrastructure the other side chose. Timing can be shaped, jitter can be injected, and a normalising proxy flattens the texture on the way out. It's a better class of evidence, not clear evidence, and rebuilding on it is the same move one layer down. The postmortem flags it as unverified, which is the honest answer.
And the printer is the detail I can't get past. The vendor pulled that version hours before the update notice arrived, so the channel it came through wasn't the one it claimed to be. Disk encryption protects a machine that's off, and that laptop was never off, only locked, with sandbox keys on it. The printer is the one device nobody puts on its own VLAN, sitting on the same WiFi the entire time.
Separately, one thing for the resume thread, because @unitbuilds is right about all of it, but it's solving the second problem. A few applications and near silence isn't a resume signal yet. What you have is unusual and completely invisible in that channel: a book, a series people reread, close to 20k followers, and a public body of work about how AI systems fail. None of it survives an automated first pass, and all of it is decisive once a real engineer reads it. So I'd put half the effort into routes where a human sees you before a filter does.
Shipping this a week after a landslide and a KDP submission is faintly ridiculous. 👊
Really great comment, you caught every single one, haha. Guess I need to bury the hooks deeper. And yeah, you're right about the 30%. It's a better class of evidence, not proof. That's exactly why the postmortem calls it unverified.
This chapter was me finally letting Derek be the test engineer he actually is (he's the test director in the story). A lot of the stuff in his process, the single-variable diff, reverse validation, anomaly filtering, that's just how I'd actually do it.
Derek shows up less than the other five, but he's probably the most real one of the bunch. Gets confused, makes mistakes, reflects, improves. Total failures and he never quit. The never-shutting-down-laptop thing, that's an IT person's disease, haha.😂
Resume side, at our age, experience can hurt you more than help. Taking it one step at a time. Not in a rush, more focused on getting the book out. Speaking of which, just saw my Amazon review got BLOCKED. They said they'd email me, nothing yet. Already talked to support, they escalated. Waiting now. Knew it wouldn't be clean, but this is how you learn the KDP process. Get through this one and the 36 Stratagems series will be way smoother. 👊
Sorry about the block. Rough timing, when everything else had finally lined up.
Worth saying though, blocked at review is not rejected. I think it's a hold. And the most common trigger for a book like yours is that the content already exists free on the web, which makes KDP ask the author to confirm they hold the rights. If that's what it turns out to be, you are the rights holder, and it resolves with a reply. Annoying, not fatal.
Support has escalated, so the useful thing now is patience and a paper trail. Keep the case reference, and if the email doesn't land in a few days, reply on the same thread rather than opening a fresh case. New cases go to the back of the queue.
On Derek, that lands. He's the one doing the boring work who stays confused the longest, which is exactly why he reads as the most real. And the never-shutting-down laptop is diagnostic. Every IT person I know has that disease, including me 🥱. I have been up since 3 AM this morning☕️.
Mostly though, I want the book. Paperback, on the shelf, the whole thing. Tell us the minute it clears. 👊
Haha interesting timing😂, I just refreshed the Amazon status and the Kindle edition is BLOCKED but the paperback actually went to Publishing. "Your paperback is being published. A confirmation email will be sent when your title goes live. It can take up to 72 hours for the product image, search keywords, and product description to display or become functional on the site."
So now I have no idea what Amazon's review logic is. My guess is the BLOCKED might be because the ebook has my Dev.to profile link and email in it, but who knows. Waiting on the email for now. At least the paperback is fine, so the ebook should probably be okay too in theory.
I love how every IT person who wakes up before dawn gets called out here, haha. But seriously, sleep more, health comes first. Hope we all eventually get normal sleep schedules. ☕️
YESSS. The paperback is going live. That's the one I wanted. 🎉
Seventy-two hours from now, I'll be refreshing that page like it owes me money. Say the word the moment it appears, and I'm buying it that day.
And your guess about the ebook is, I think is the best explanation, because it explains the asymmetry. Same text, but the paperback's links are just ink while the ebook's are clickable. If the check is about live external links pointing readers off Amazon, only one of those two formats could ever trip it. Worth putting that theory in your reply to support, since it gives them something specific to look at instead of a generic appeal.
On sleep, I'm the wrong person to lecture anybody. I work flexibly now, which mostly means late nights and early mornings stitched together. Then every so often my body files a shutdown notice, and I sleep ten hours straight to pay off the debt. On those days it's an early night and a late morning, and I pretend that was the plan all along.
So yes to normal sleep schedules for all of us. Eventually. Probably right after the 36 Stratagems series wraps. ☕😆
Then I'd better speed up the remaining 11 stratagems so you can get a normal sleep schedule sooner, haha.🤣 #26 should go live in a few hours actually. Helps that I'm unemployed now, no more squeezing writing into lunch breaks and late nights like when I had a job. Good and bad come in pairs, just depends on which side you use.
A system that does not react to a changed delay may be hiding a missing feedback loop. Timing is often product state, not a cosmetic setting, so it deserves explicit observability and tests around the boundary conditions.
Well‑said! Timing is genuine system state rather than cosmetic config. Missing feedback loops behind unresponsive timing behavior are extremely sneaky failure modes 👍
The 200→800ms test is the best scene in the series so far for me. One variable, one question — and the scanner "answers" by not answering: dwell grows by exactly the latency delta, retries stay at zero, port order untouched. A script has no branch for the environment, so nothing triggers. That single diff table says more than pages of exposition would.
Leo's line lands the real thesis: "No mistakes, no redundancy. Variance so small it's unnatural." It works way beyond fiction — scripted behavior can fake decisions, but it can't fake the texture underneath (scheduler jitter, kernel timing, wasted attempts). Perfect consistency is itself the tell. In data auditing it's the same rule: records that are too clean are the first thing you flag.
I also like that Derek's counter ends up being the same stratagem in reverse — the file stays in place, but "Saw it." turns a read into a message. Both sides know now. Waiting for #26.
Thank you for such a great read‑through.🎉 You hit the main point perfectly: perfect consistency is a huge red flag.
Using that diff table as evidence was intentional — show, don’t tell. And right, Derek flips the very same stratagem; plain observation turns into a signal.
Nice to see the data‑auditing parallel lands. Anyone working QA or auditing quickly learns to distrust records that look too spotless.
By the way, stratagem #26 went live yesterday. Can’t wait to hear what you think. 👏
Great write-up!
Handling unexpected latency or artificial delays is always where rigid automation breaks down. The fact that the agent adapted without state desync or timeout loops shows just how critical robust error boundaries and adaptive polling are when orchestrating AI workflows. Enjoying this series.
I’m really glad you’re enjoying the series. While writing, I always try my best to strike a balance between storytelling and technical depth. I keep worrying that it might turn out either purely‑technical or just plain fiction. The tech has to be solid, and the storyline also needs to be engaging. Welcome to the Third‑Cup Café.🥳
Stratagems #25 is finally out. 11 more to go — part of me is already dreading the ending lol🤣
I'm saying "Welcome back!" lol :-)
welcome🎉
Cat and mouse, mouse and cat ... and what about that printer firmware? Hmmm ... :-)
You're getting good at reading the furniture. Derek pulled up the firmware record — the version was already pulled, withdrawal time earlier than the update notice. Then he stood up and went to get water. Wrote nothing down. Just… got water.🤣
Haha yes, nice the subtlety of all those little points!
Another great one! I’m honestly getting more curious with every chapter about where this is going 😄
Haha, I hope my writing skills haven't dropped since I got back from Wudang – if anything, maybe they've gotten better! I also hope the 36 Stratagems series ends in a way that everyone's happy with. I'm working on #26 right now, so please keep cheering me on when it's ready!🙌