Hackathon Blog Guide and Checklist

You don't need to be a professional writer. Good writing reflects honesty, specificity, and usefulness. If a reader finishes your post and thinks “I could go do this now” or “I didn't know that,” you've done it right.

The strongest posts come from something you actually did, hit, or figured out and NOT a topic you googled and summarized. Whether you're writing about the project you built, an observability concept, or a topic of your choice, ground it in your own experience.

Ask yourself: “What did I learn that I couldn't have gotten by just reading the docs?” That's your post.

• It solves a real problem, or explains something that confused you until it clicked.
• It includes details only someone who did it would know.
• A reader could follow along and get the same result.
• It is feature rich (use all relevant SigNoz features).
• It has good feedback and a conclusion for the readers.

• It reads like a rewritten version of official documentation.
• It's all generic statements with no specifics, like: "Observability is very important for modern applications…"
• It could have been written by someone who never opened a terminal.
• It's obviously AI-generated filler with no real substance behind it.

• What I built: Walk through your project, explain the problem, how you built it, outcomes, and what you'd do differently.
• How to do X: A focused tutorial others can follow step by step.
• What I learned: A concept, gotcha, or debugging story from the hackathon.
• Why / my take: An opinion or comparison backed by real reasoning and examples.

Narrow beats broad → “How I instrumented my Flask app with OpenTelemetry in 30 minutes” is far better than “A Guide to Observability.”

1. Hook (first 2–3 sentences): Start with the problem, a surprising fact, or a question. Skip the long intro. Tell the reader what they'll get out of this post.
2. Context (what and why): What are you doing, and why does it matter? Keep it short.
3. The Main Body (show your work): The actual steps, code, config, or reasoning.
4. What You Learned / Takeaways: What worked, what didn't, what you'd tell your past self.
5. Conclusion: A one-line wrap-up and, where relevant, links to learn more.

Aim for roughly 1000–1500 words: long enough to be useful, short enough to stay honest.

• Include real code and config.
• Add screenshots like dashboards, traces, and the output you got.

Readers will try to follow your steps, so accuracy matters:

• Test what you write: If you say a command or config works, make sure it actually ran for you.
• Verify claims about tools: For OpenTelemetry specifically, check the official docs (opentelemetry.io) rather than relying on memory.
• Don't overstate: It's fine to say “this worked for my setup” instead of claiming it works everywhere.

• A LinkedIn social post is not a blog. Don't submit one.
• Publish your blog on a proper blogging platform, Medium, Dev.to, or Substack are all great choices.
• How to avoid AI writing: Signs of AI writing.
• Don't plagiarize your words and work. Quote and link sources instead of copying.
• Don't submit raw AI output. Using AI to help edit is fine, but submitting generic AI text with no real experience behind it is not.
• Don't turn it into an ad. Even if SigNoz is part of your story, focus on being useful. Genuine usefulness is more persuasive than a sales pitch.
• Don't bury the point. If your best insight is in paragraph 9, move it up.

• I tested the steps/commands I describe.
• Technical claims (OpenTelemetry, SigNoz, and others) are checked against official sources.
• I have relevant screenshots in my article (SigNoz dashboards look insightful, use them wisely and don't flood the article with just dashboards).