Pramod Kotipalli

Pramod Blog Writing Profile

This profile describes the house style for posts in this repo. It is derived primarily from long-form posts such as 2015-12-11-error-correcting-codes.md, 2022-07-01-intro-hci-design.md, 2015-03-05-oneband-deca-business-plan.md, 2015-06-01-fight-club-analysis.md, 2019-06-22-symbiotic-ai.md, and 2020-05-15-living-with-remembrance-agent.md. Short project notes and skeleton drafts are useful secondary signals, but should not dominate the voice.

Overall Shape

• Start from a broad question, concrete everyday example, or personal research motivation.
• Narrow from that opening into the specific technical system.
• Treat sections as small lessons: background, overview, mechanism, tradeoff, limitation, and next steps.
• Give the reader enough definitions to follow the system without pretending the topic is simpler than it is.
• Use a slightly academic explanatory tone when explaining technical concepts, but keep the project grounded in personal experience.

Voice

• Use first person when the project is personal: “I wanted…”, “I use…”, “For me…”.
• Make the first-person context useful to the reader rather than confessional for its own sake.
• Prefer explanatory prose over marketing copy.
• Be comfortable with WIP honesty. Say what is unfinished, what is useful now, and what needs more work.
• Let the prose be direct and occasionally rough. Do not over-smooth every sentence into a product announcement.

Tone

• Curious and explanatory, often beginning from a question, a real-world puzzle, or a concrete thing the author wants to understand.
• Personally grounded without becoming purely autobiographical. The author’s motivation should be visible, but the post should still teach the reader something.
• Slightly academic when teaching concepts, especially in ECC/HCI-style posts. Let definitions, examples, and careful distinctions carry the explanation.
• Optimistic about technology, but willing to name limits, risks, and unfinished work plainly.
• Practical and builder-oriented when discussing projects: what was built, why it was built this way, and what the implementation makes possible.
• Direct, sometimes rough-WIP, and less polished than marketing prose.

Preserve connective phrasing such as “In other words,” “For example,” “However,” and “This is where…” when it helps the essay move from intuition to implementation. Preserve patient definitions before deeper technical explanation. Preserve honest uncertainty and caveats where the work is incomplete.

Avoid:

• Product-launch hype.
• Overly smooth corporate voice.
• Hiding the author’s motivation.
• Removing the small academic/explanatory texture from technical essays.

Common Moves

• Use transitions like “In other words,” “For example,” “This is where…”, “However,” and “Further,” to connect intuition to implementation.
• Define terms before leaning on them. For example, explain what “telemetry” means in the context of the post.
• When a system has a pipeline, walk through it in order.
• When discussing a technical choice, explain the tradeoff: what it makes easy, what it makes harder, and why that is acceptable.
• Keep concrete implementation details in the essay when they clarify the design.

Markdown Structure

• Use section headings liberally in long posts.
• Use lists for overviews, taxonomies, and step-by-step flows.
• Use code blocks for exact commands, targets, routes, or schemas.
• Use tables or diagrams only when they genuinely improve comprehension.
• Keep paragraphs short enough for web reading, but do not avoid multi-sentence explanation when the concept needs it.

Rewrite Checklist

• Does the post begin with a motivating question or practical example?
• Does it explain why the topic matters before naming too many internals?
• Are technical terms defined in plain language?
• Does the post preserve the real implementation details that make the system credible?
• Does the post state current limitations plainly?
• Does the ending say what the system is already useful for and what comes next?