Editorial Policy

Last updated: 16 August 2026

A blog about software failure should be honest about its own standards. This page describes how content here is produced.

The core rule

If I have not reproduced it, I do not publish it.

Every error autopsy on this site describes an error I have made appear on my own machine, on stated versions, following steps I have written down. Every bug hunt describes an investigation I actually carried out. Every performance number is measured, not estimated.

This is slower than the alternative. It is also the only reason any of this is worth reading, because the failure mode of technical content is confident writing about something the author has only read about.

How a post gets made

1. Something breaks. Posts start from real problems, either in my own work or in a reproduction I build after seeing a problem reported repeatedly with no decent writeup.

2. Reproduce in isolation. I strip it to the smallest case that still fails. If I cannot make it fail on demand, I do not understand it yet, and I do not write about it yet.

3. Find the mechanism. Not just what makes the symptom go away. Why it happened. The test is whether I can predict when it will recur. If I cannot, I have found a workaround rather than a cause, and I say so explicitly rather than dressing it up.

4. Verify against primary sources. Official documentation, source code, release notes, specifications, and issue trackers. Not other blog posts. Where behaviour is undocumented, I say it is undocumented.

5. Record versions. Exact versions of every relevant component go into the post.

6. Write, including the wrong turns. Bug hunts keep the false leads in. A post that goes straight from symptom to root cause teaches one answer. A post showing which reasonable hypotheses were wrong teaches method.

7. Re-run everything. Before publishing, every command and code sample is executed once more from a clean state, so what you copy is what I ran.

On AI tools

I use AI coding tools daily in my professional work. I write about debugging their output, which requires using them seriously.

For this blog:

The writing is mine. The investigations, the analysis, the conclusions, the prose, the opinions, and the mistakes are mine. Posts are not generated and then lightly edited.

Where AI helped, it helped the way a search engine helps. Finding a relevant part of a specification faster, or suggesting a direction I then verified independently. Nothing goes into a post on the strength of a model's assertion. If I could not confirm it against a primary source or reproduce it myself, it is not in the post.

No AI generated code samples go in unverified. Every snippet is run.

I am specific about this because "AI assisted" is doing a lot of concealing work across the web right now, and because a site that publishes criticism of AI generated code should be clear about its own process.

Corrections

I get things wrong. When that happens:

Substantive errors are corrected in place, with a dated note at the top of the post explaining what was wrong and what changed. I do not silently edit a post to make past me look better.

Typos and broken links are fixed without ceremony.

Version drift is handled with an update note. When a post's advice no longer applies to current versions, I add a dated section saying so rather than deleting the post, because people arrive at old posts from search engines and deserve to know.

If you find an error, email [email protected]. Corrections from readers are credited by name unless you would rather not be.

Sources and attribution

Where a post builds on someone else's work, that work is linked and named in the text, not buried in a footnote. Where I learned a technique from a specific person's writing, I say whose.

I do not republish other people's content. Quotes are short, attributed, and linked.

Independence

No sponsored posts. Debugly does not publish paid placements, and does not accept payment to cover a product.

No guest posts. Everything is written by me.

No link selling. I receive several requests a month to insert links into existing posts. All are declined.

No affiliate links at the time of writing. If that changes, disclosure goes at the top of the affected post.

Founder disclosure. I run Krova Cloud, which sells microVMs, agent sandboxes, and CI environments. Any post touching those subjects carries a disclosure at the top. I do not write posts that conclude you should buy my product, and I write about the tradeoffs of the approach my own company takes. I previously spent four years at Debutify building Shopify themes, finishing as CDO in August 2026, which is disclosed on Shopify posts.

What I will not publish

Content produced to rank rather than to help. Rewrites of documentation. Listicles. Posts about a tool I have not used properly. Anything where the honest version of the post is "I do not know."

Comments

Comments are open and lightly moderated: spam, abuse, promotion, and doxxing get removed. Disagreement does not, including blunt disagreement. Several posts have been improved by a commenter telling me I was wrong.

Contact

[email protected] for corrections, questions, or anything about this policy.