Taina Costa

Posted on Jun 16

Por que todo dev deveria participar de um writing challenge (e como vencer)

#javascript #beginners #tutorial #webdev

Acabei de ver os vencedores do Google I/O 2026 Writing Challenge no dev.to. Enquanto scrollava os artigos premiados, percebi um padrão: os que ganharam não são necessariamente os devs mais seniors ou com mais seguidores — são os que sabem transformar conceitos complexos em narrativas que grudam na cabeça.

Por que writing challenges importam agora

O mercado está saturado de tutoriais genéricos gerados por IA. Documentação oficial melhorou muito, mas ainda falta o "como eu uso isso de verdade". Challenges de escrita forçam você a:

Provar que entende o que está usando (não dá pra enrolar)
Construir portfólio público (recrutadores leem, sim)
Solidificar conhecimento — você só entende de verdade quando consegue explicar

Três devs da minha timeline conseguiram job offers depois de artigos viralizarem. Não é sobre viralizar, mas sobre demonstrar que você pensa, não só copia.

O que funciona (com exemplos reais)

Analisei 15 artigos vencedores de challenges anteriores. O padrão:

Estrutura vencedora:

# Título: promessa específica, não vaga
"Como evitei 3 horas de debug com React DevTools"
vs
"Guia completo de React DevTools" ❌

## Problema real primeiro
Mostre o erro, o stack trace, a dor.

## Solução progressiva
Do jeito errado → melhor → ideal
Cada passo explica *por que*, não só *como*

## Code que roda
Sem `// ... resto do código`
Sem `import { magicFunction } from 'somewhere'`

## TL;DR brutal
3-5 bullets, zero fluff

Exemplo prático — antes vs depois:

Antes (genérico):

// Use async/await para chamadas assíncronas
async function getData() {
  const data = await fetch('/api/data');
  return data;
}

Depois (mostra o problema real):

// ❌ Isso quebra silenciosamente em prod quando a API retorna 404
async function getData() {
  const data = await fetch('/api/data');
  return data.json(); // TypeError se response.ok === false
}

// ✅ Agora você sabe *quando* explode
async function getData() {
  const response = await fetch('/api/data');

  if (!response.ok) {
    throw new Error(`API error: ${response.status}`);
  }

  return response.json();
}

Comentários em código ficam em inglês (padrão da indústria), mas a explicação ao redor é pt-BR.

Armadilhas que matam suas chances

1. Code sem contexto
Você colou um snippet de 50 linhas sem explicar o setup. Ninguém vai copiar pro projeto deles só pra testar se funciona.

Solução: crie um repo mínimo ou use CodeSandbox/StackBlitz embeddable. Link no artigo.

2. "Aqui está tudo sobre X"
Artigos que tentam cobrir tudo ficam superficiais. Melhor: pegue UM caso de uso, vá fundo.

Exemplo:

❌ "Guia completo de React Hooks"
✅ "useCallback está te deixando mais lento — veja quando NÃO usar"

3. Escrever pra impressionar, não pra ensinar
Jargão técnico sem necessidade. Abstrações sem exemplo concreto. Se você precisa de 3 parágrafos pra chegar no código, corte 2.

4. Ignorar o "por que agora"
Challenges normalmente pedem artigos sobre features recentes. Se você escrever sobre React Server Components, tem que mencionar:

Por que isso existe (Suspense, data fetching, bundle size)
O que mudou da última versão
Quando você não deve usar

Como eu abordo um writing challenge

Meu processo quando decido participar:

Leio a documentação oficial da feature + issues no GitHub

Issues revelam dores reais, edge cases, o que confunde as pessoas.
Reproduzo o problema antes da solução

Crio um repo pequeno, quebro tudo, documento cada erro. Isso vira a primeira seção do artigo.
Escrevo o TL;DR primeiro

Se não consigo resumir em 5 bullets, o artigo não tem foco suficiente.
Code funcional, sempre

Testo cada snippet. Se não roda standalone, adiciono o setup mínimo. npm create vite@latest, instala dependências, mostra onde colar o código.
Releio como se fosse um dev com pressa

Você tem 2 minutos antes da daily. O artigo resolve seu problema ou você fecha a aba?

Ferramentas que uso

Grammarly (tem versão pt-BR) pra pegar typos que passam no revisor
Carbon ou ray.so pra screenshots de código bonitinhos
Excalidraw pra diagramas rápidos quando preciso explicar fluxo
StackBlitz pra embeds interativos — leitor testa sem sair do artigo

TL;DR

Challenges premiam clareza + código funcional, não firulas
Estrutura vencedora: problema real → código progressivo → caveats
Uma ideia funda > dez ideias rasas
Code sem contexto de setup = artigo que ninguém usa
TL;DR no final (estilo este) fecha bem e facilita skimming

DEV Community