Creator guidelines

Everything you submit is checked against this page before it is published. Use it as your checklist.

What good work does

A good post helps one kind of reader with one clear thing. A good project lets a specific person get a specific result in a stated amount of time, and leaves them knowing something they didn't before. In both cases a reader should be able to decide in under a minute whether it is for them, and then succeed without having to ask you anything.

Blog posts

Before you write

• Pick one reader and one question. "How do I read a CSV file in Python?" is a post. "Everything about Python files" is a book.
• Check what already exists. Say something newer, clearer, more honest or more practical than the top results, or choose another topic.
• Only write what you have done, tested or can source. If you haven't run the code, don't publish it.

Structure

1. Title: specific and honest, about 60 characters, main words first. No clickbait.
2. Opening (2 to 4 sentences): who it is for, what they will get, and the short answer early.
3. Body: headings a skimmer can follow, one idea per section, an example soon after each new idea.
4. Close: a summary or a next step, with links to related posts, Practice problems or projects where they help.

Most useful posts run between 600 and 1,500 words: as long as the topic needs, and no longer.

Voice

• Write like a clear person talking to one other person. Prefer short, plain words.
• Be concrete: name the version, the command, the number.
• Be honest about limits: what you didn't try, and where the advice stops working.
• Explain jargon the first time you use it. Avoid "just" and "obviously".
• Be inclusive and respectful.

Projects and guided builds

The promise (what a visitor reads first)

• A title that says what you get ("Build a REST API with Node and SQLite", not "Backend Project 3").
• A one or two sentence summary that makes sense on its own.
• Who it is for, what you will have at the end, an honest time estimate, and everything it needs (tools, accounts, versions, anything that costs money).
• A featured image, and a live demo or screenshots wherever the result can be seen.

The content

• Starts from a known state: starter files, or exact set-up steps.
• Small, ordered steps. Each says what to do and how to know it worked ("you should see ... in the terminal").
• New ideas are explained where they are first needed, briefly, with a link for more depth.
• Includes the two or three mistakes people actually make, and how to fix them.
• Ends with a finished result, a next step, and a reference solution a stuck learner can compare with.

The code

• It runs, from a clean machine, following your steps exactly. This is the most common reason a project is sent back.
• Versions are stated and the lockfile is committed.
• No secrets or personal data: provide a .env.example instead.
• The licence is stated, and anything third-party you include may be redistributed.
• Anything with a user interface works at phone width, has enough contrast, and has alt text on images.

Test it. Before you submit, someone who isn't you completes the project from the page alone. Watch where they pause, record how long it really took, and fix the places they got stuck.

Code, images and sources

• Every code block names its language, and all code works as shown with the versions you state.
• Keep examples small; link to a repository for anything longer than a screen.
• Use images you made or have the right to use, with alt text on any image that carries meaning.
• Quote briefly, mark the quote and link the source. Don't paste or lightly reword text from elsewhere.
• Cite facts a reader could doubt (benchmarks, statistics, security advice) with the primary source.
• Mark affiliate or sponsored links clearly.

Using AI tools

You may use AI tools to draft, outline or edit, but you are the author and responsible for every claim and every line of code. Don't publish text you haven't read closely, code you haven't run, or sources you haven't opened. If a large part was drafted by a tool, say so in your submission notes. Work that reads as generic or unchecked will be sent back.

What gets work sent back or declined

• The code doesn't run, or only runs on the author's machine.
• It is copied or lightly reworded without permission and credit.
• The title, time estimate, skill level or result overpromises.
• It contains secrets, personal data, harmful code, or content that breaks the site's rules.
• It asks the reader to pay or sign up for something unexpected to finish it.
• It is a thin rewrite of something that already exists.

How review works

A reviewer reads your work, runs the code and checks sources, then replies with accepted, changes requested (with a short list) or declined (with the reason). Expect at most two rounds of changes. We may edit titles, excerpts and tags for consistency and search, and we will tell you if we change anything substantial.

After publishing, corrections are welcome and quick. If something becomes outdated, update it or ask us to mark it outdated.