Editorial standards

1. Authorship

Every article on this site carries the name of a single working author. The author is the person who drafted the post, ran the code in the examples, and stands behind the technical claims. We do not publish under house pseudonyms, generic team bylines, or AI-generated personas. Author profiles live at /authors and link to the writer's GitHub and LinkedIn so the byline is verifiable.

When a post is technically reviewed by a second team member before publication, that reviewer is named alongside the author on the article. A reviewer signs off that the code runs as described and that the claims about behaviour match what the team has observed in production.

2. Review process

A new post moves through three stages before it goes live. The draft stage covers the structure, the worked examples, and the framing. The review stage covers technical accuracy — code runs end-to-end on a clean install, version numbers match what's pinned, and any claim about a third-party library cites the relevant documentation. The copy stage covers readability and consistency with the rest of the catalogue.

Posts written by the founder are reviewed by the developer educator, and posts written by the developer educator are reviewed by the founder. The two halves of the catalogue (engineering deep-dives and tutorials) check each other. No post ships without that second reading.

3. Sources and citations

Technical claims point to a primary source where one exists — the specification, the RFC, the official documentation, the original paper. When a behaviour is something the team has observed in production rather than something documented externally, the post says so explicitly. We do not pretend lived experience is a citable standard, and we do not bury the line between "the spec says" and "we've seen this break under load."

Outbound links to primary sources stay as plain links — they are not rewritten, cloaked, or wrapped in affiliate trackers. The web is better when the citation graph is honest, and a small site loses nothing by sending a reader to the W3C or to a vendor's documentation when that's the better answer.

4. Corrections

Factual errors are corrected as soon as they are confirmed. When a correction changes the meaning of a paragraph — not a typo, but a substantive change to a claim — we update the affected text in place and update the article's "last reviewed" date. For larger corrections that change the conclusion of a section, we add a short note inside the article making the change visible to future readers.

Spotted an error? Email sharecodelive@gmail.com or use the contact form. Verified corrections are usually applied within a few business days.

5. Independence

The blog is part of ShareCode. We don't pretend it's independent of the product. What we do commit to: posts that compare ShareCode against other tools call out where another tool is better; posts that recommend ShareCode for a workflow say specifically why and what the trade-offs are; and we do not accept paid placements, sponsored sections, or undisclosed promotional content from third parties inside the catalogue.

If a future article involves a relationship that could influence its framing — a partnership, a sponsorship, a beta program with a vendor — that relationship will be disclosed inside the article in plain language. The disclosure goes near the byline, not buried in a footnote.

6. AI use

Articles on this site are written by humans. AI tools are used the way developers use them in everyday work — as a thesaurus, as a second pair of eyes on a paragraph, as a way to surface a name for a concept the author already understands — but no article is generated end-to-end by an AI model and posted under a human byline.

The author named on a post is responsible for every claim it makes. That responsibility is incompatible with handing the draft to a model, skimming the output, and shipping it. If an AI-assisted section materially shaped a conclusion or a recommendation, the article notes that the section was AI-assisted, and the human author still verifies the underlying claim against a primary source before publication.

7. What we don't publish

• Listicles or roundup posts that are mostly summaries of other articles. If we cover an external resource, we add original analysis, not a paraphrase.
• SEO posts targeting a search term we have nothing useful to say about. The catalogue grows slowly on purpose; a post we can't defend in a conversation with a senior engineer doesn't ship.
• Sponsored content, paid placements, or affiliate-driven product recommendations. Comparisons are written based on the team's own use of the tools and the public documentation.
• Posts that recycle the same advice in a new wrapper. If two posts would cover substantially the same ground, we update the original instead of publishing a second version.

8. Reach the editorial team

Topic suggestions, factual corrections, and feedback on the writing all go to the same place. Use the contact form or email sharecodelive@gmail.com. The two writers also publish their own contact details on their author pages if you'd rather reach one of them directly.