Habilidade de Escrita para o Blog da Sentry

Esta habilidade garante os padrões de escrita do blog da Sentry em cada postagem — seja você ajudando um engenheiro a escrever sua primeira postagem ou um profissional de marketing a redigir um anúncio de produto.

O padrão: Toda postagem de blog da Sentry deve ser algo que um engenheiro sênior compartilharia no Slack de sua equipe ou referenciaria em uma decisão técnica.

O que se segue são os princípios centrais a serem internalizados e aplicados a cada peça de conteúdo.

Quando Usar

• Você precisa redigir ou editar uma postagem de blog da Sentry.
• A tarefa envolve storytelling técnico, anúncios de produtos ou mergulhos profundos de engenharia na voz do blog da Sentry.
• Você deseja conteúdo de blog que seja opinativo, específico e tecnicamente credível, em vez de cópias de marketing genéricas.

A Voz da Sentry

Nós soamos como: Um desenvolvedor sênior em uma conferência após a festa explicando algo pelo qual ele está genuinamente animado — inteligente, específico, um pouco irreverente, profundamente conhecedor.

Nós não soamos como: Um blog corporativo, um comunicado de imprensa, um deck de vendas ou um resumo gerado por IA.

Seja tecnicamente preciso, opinativo e direto. Humor é bem-vindo, mas deve servir ao conteúdo, não substituí-lo. Sarcasmo funciona. Uma boa piada por postagem é o suficiente.

Use "nós" (Sentry) e "você" (o leitor). Isso é uma conversa, não um artigo.

Linguagem Proibida

Nunca use estas. Elas são bandeiras vermelhas automáticas:

• "Estamos animados/entusiasmados em anunciar" — apenas anuncie
• "O melhor da categoria" / "líder de mercado" / "de ponta" — mostre, não diga
• "Sem interrupções" / "perfeitamente" — nada é sem interrupções
• "Capacitar" / "aproveitar" / "desbloquear" — diga o que você realmente quer dizer
• "Robusto" — descreva o que o torna robusto em vez disso
• "Na [Empresa], acreditamos..." — apenas declare a crença
• "Otimizar" — todo mundo está otimizando, pare
• Transições de preenchimento: "Dito isso", "Vale notar que", "No final do dia", "Sem mais delongas", "Como você pode saber"
• "Nesta postagem de blog, exploraremos..." — seja direto, apenas comece

A Abertura (Primeiras 2-3 Frases)

A abertura deve fazer uma de duas coisas: declarar o problema ou declarar a conclusão. Nunca comece com histórico, história da empresa ou hype.

Bom: "Duas semanas antes do lançamento, destruímos todo o nosso produto de métricas. Veja por que a pré-agregação de métricas de séries temporais falha na depuração e como reconstruímos o sistema do zero."

Ruim: "Na Sentry, estamos sempre procurando maneiras de melhorar a experiência do desenvolvedor. Hoje, estamos entusiasmados em compartilhar algumas atualizações interessantes em nosso produto de métricas que achamos que você vai adorar."

Estrutura: Siga as Perguntas do Leitor

Estruture cada postagem em torno do que o leitor realmente está se perguntando, não de sua narrativa interna:

1. Que problema isso resolve? (1-2 parágrafos no máximo)
2. Como isso realmente funciona? Não botões que você clica, mas a tecnologia subjacente. (A maior parte da postagem — seja específico)
3. Quais foram os trade-offs ou alternativas? (Isso separa o bom do ótimo)
4. Como eu uso/experimenta/implemento isso? (Próximos passos concretos)

Para mergulhos profundos de engenharia, também aborde: 5. O que tentamos que não funcionou? (Constrói confiança) 6. Quais são as limitações conhecidas? (Mostra honestidade intelectual)

Títulos de Seção Devem Transmitir Informação

Fraco: "Histórico", "Arquitetura", "Resultados", "Conclusão"

Forte: "Por que a pré-agregação de séries temporais destrói o contexto de depuração", "A abordagem scatter-gather para GROUP BY distribuído", "Onde isso falha: a parede de cardinalidade"

Padrões de Qualidade Técnica

Números em vez de adjetivos. Se você fizer uma afirmação de desempenho, inclua o número.

• Ruim: "Isso reduziu significativamente nosso tempo de processamento de erros."
• Bom: "Isso reduziu nosso tempo de processamento de erros p99 de 340ms para 45ms — uma melhoria de 7,5×."

O código deve funcionar. Se uma postagem inclui código, teste-o. Inclua importações, configuração e contexto. Comentários devem explicar por que, não o quê.

Diagramas para sistemas. Se você descrever um sistema com mais de dois componentes interagindo, inclua um diagrama. Rotule com nomes reais de serviços, não caixas genéricas.

Honestidade em vez de hype. Nunca exagere o que um recurso faz. Reconheça as limitações. Se algo está em beta, diga isso. Se um concorrente faz algo bem, tudo bem notar isso. Não afirme que os recursos de IA são mais capazes do que são — "Seer sugere uma causa provável" ≠ "Seer encontra a causa".

Diretrizes de Título

O título é a frase de maior alavancagem na postagem. Ele deve fazer um desenvolvedor parar de rolar seu feed RSS ou Twitter.

…