Produtividade que parece errada (mas funciona para dev)

Semana passada cancelei três reuniões, commitei código com TODOs de propósito e fechei o VS Code às 15h numa terça-feira. Entreguei mais naquela semana do que no mês anterior.

Por que isso importa agora

O burnout em tech está em alta. A cultura do "sempre produtivo" nos empurra pra fazer mais code review, mais commits, mais horas. O problema? Produtividade não é linearmente proporcional a esforço. Às vezes, fazer menos é o atalho.

Aqui vão sete táticas que usei e que soam completamente erradas — mas que mudaram como entrego software.

1. Commite código ruim (de propósito)

Não estou falando de commitar qualquer porcaria em main. Mas parar de buscar o commit perfeito logo de cara libera momentum.

// First pass - just make it work
function processUserData(users) {
  let result = []
  for (let i = 0; i < users.length; i++) {
    if (users[i].active === true) {
      result.push({
        id: users[i].id,
        name: users[i].name,
        // TODO: add email normalization
        email: users[i].email
      })
    }
  }
  return result
}

Commita isso. Funciona. Depois você refatora:

// Second pass - clean it up
const processUserData = (users) => 
  users
    .filter(u => u.active)
    .map(({ id, name, email }) => ({
      id,
      name,
      email: normalizeEmail(email)
    }))

Tentar escrever a versão "certa" de primeira paralisa. O código ruim te dá tração. Refatoração vem depois.

2. Batch seu code review (não faça na hora)

Toda notificação de PR é uma context switch. Eu costumava revisar na hora — achava que era ser "bom colega de time". Resultado? Zero deep work.

Agora tenho dois slots de code review por dia: 11h e 16h. Reviso tudo de uma vez. Meu time sabe disso. Urgências vão pro Slack.

// .github/workflows/review-reminder.yml
# Automation: remind me only at review time
on:
  schedule:
    - cron: '0 11,16 * * 1-5'  # 11 AM and 4 PM, Mon-Fri
jobs:
  notify:
    runs-on: ubuntu-latest
    steps:
      - name: Check pending PRs
        run: gh pr list --assignee @me

Batch processing reduz sobrecarga cognitiva. Você entra no "modo revisor" e sai dele — não fica pingando entre contextos.

3. Não resolva o bug agora

Achei um bug no meio de uma feature? Anoto e não conserto. Parece irresponsável, mas:

// Instead of fixing immediately:
function calculateTotal(items) {
  // BUG: breaks with empty array - fix in #1234
  return items.reduce((sum, item) => sum + item.price, 0)
}

Crio uma issue, linko no comentário, volto pra feature. Consertar bugs no meio de outra coisa é garantia de:

• Commit misturado (feature + bugfix)
• Perder o fio da meada na feature
• Gastar 20min num rabbit hole

A não ser que seja critical, o bug espera. Foco > multitarefa.

4. Deixe TODOs no código (intencionalmente)

TODOs têm má fama. Mas eu uso como marcador de iteração:

// components/UserProfile.tsx
export function UserProfile({ userId }: Props) {
  const { data } = useUser(userId)

  // TODO: add loading skeleton
  // TODO: add error boundary
  // TODO: add avatar upload

  return (
    <div>
      <h1>{data.name}</h1>
      <p>{data.email}</p>
    </div>
  )
}

Entrego a versão mínima funcionando. Os TODOs viram tasks depois. Isso evita over-engineering na primeira passada. Você descobre o que realmente precisa quando a feature está rodando.

Automatizo a coleta:

# List all TODOs in current branch
git diff main --name-only | xargs grep -n "TODO" || echo "No TODOs"

5. Não leia a doc inteira (scan até achar o exemplo)

Gastei anos lendo documentação de ponta a ponta. Descobri que 80% do que preciso está num example de quickstart.

Quando preciso integrar uma API nova:

1. Vou direto pro "Getting Started"
2. Copio o exemplo
3. Rodo
4. Quebrou? Aí leio a seção específica do erro

// I don't read all of Stripe docs. I copy this:
const stripe = require('stripe')(process.env.STRIPE_KEY)

const paymentIntent = await stripe.paymentIntents.create({
  amount: 2000,
  currency: 'brl',
})
// Then I iterate from here

Aprender fazendo > aprender lendo. Você absorve a doc conforme precisa, não antes.

6. Faça menos reuniões (mesmo as "importantes")

Cancelei standups assíncronos. Trocamos por thread no Slack:

📅 Daily async - 24/08
@channel drop your update:
✅ Done yesterday
🚧 Doing today  
🚨 Blockers

Leva 2min pra escrever vs. 15min de call. Eu leio quando quero. Time remoto agradece.

Reunião só quando precisa de decisão síncrona ou pair programming. O resto? Assíncrono.

7. Pare de trabalhar no meio (não no final limpo)

Parece contra-intuitivo, mas parar no meio de uma função facilita retomar:

function migrateUserData(users) {
  const validated = users.filter(u => u.email && u.name)

  // STOPPED HERE - next: transform to new schema
  // const transformed = validated.map(u => ...)

  return validated
}

Quando volto no dia seguinte, sei exatamente onde estava. Se paro num "ponto limpo", gasto 10min relembrando contexto.

Hemingway fazia isso com escrita. Funciona com código também.

Caveats

Essas táticas não são universais:

• Código ruim intencional não funciona se você não tem disciplina pra refatorar depois
• Batch review só rola se o time concorda com a latência
• Bugs adiados precisam de tracking (senão somem)
• TODOs viram dívida técnica se ninguém cobra
• Pular doc é arriscado em sistemas complexos (tipo OAuth flows)
• Menos reunião exige comunicação assíncrona forte
• Parar no meio não funciona em pair programming ou prazos apertados

TL;DR

• Commite código ruim primeiro, refatora depois — tração > perfeição
• Faça code review em batch (2x/dia) pra preservar deep work
• Não conserte bugs no meio de features — anote e volte depois
• Use TODOs como marcadores de iteração, não vergonha
• Scan docs até achar exemplo, aprenda fazendo
• Troque reuniões por async quando possível
• Pare de trabalhar no meio pra facilitar retomada no dia seguinte