founder-who-codes-why-i-still-code.html
< BACK O Fundador Que Programa: Por Que Ainda Abro o Editor — ilustração em arte linear

O Founder que Programa: Por Que Ainda Abro o Editor

Todos me disseram para parar.

Não com crueldade, genuinamente, de forma bem pensada, com aquele tipo de preocupação que as pessoas reservam para alguém que acham que está perdendo tempo. "Você é um fundador agora, Gautam. Delegue o código." Meu co-fundador na Seahawk Media disse algo semelhante por volta de 2018 quando ultrapassamos cem projetos de clientes ativos simultaneamente. A lógica era sólida: fundadores deveriam pensar em sistemas, contratações, pipeline. Não em pull requests.Seahawk Media said something similar around 2018 when we crossed a hundred active client projects simultaneously. The logic was sound: founders should think about systems, hiring, pipeline. Not pull requests.

Ignorei esse conselho. E fico feliz que fiz isso.

---

O Momento em Que Quase Parei de Programar (E Não Parei)

Em 2019, um cliente me passou um briefing que ainda me faz rir. Uma marca de e-commerce de médio porte, não vou nomeá-la, queria uma reconstrução completa de WooCommerce, um configurador de produtos personalizado, tudo. Prazo apertado. Atribuí o projeto a um desenvolvedor do time, confiante de que era exatamente o tipo de coisa do qual eu deveria estar me afastando.

Três semanas depois, o desenvolvedor saiu. Razões pessoais, completamente compreensível. Mas tínhamos um configurador semi-pronto, um cliente me pressionando, e uma codebase que só uma pessoa havia entendido completamente.

Abri o VS Code naquele domingo às 7 da manhã e só fechei ao meio-dia. Consegui fazer. Não porque sou um herói, mas porque realmente lembrava dos padrões de código, da arquitetura de hooks do WooCommerce, do jeito que woocommerce_before_add_to_cart_button se comporta quando você tem um custom post type alimentando variações de produtos. Não tinha esquecido. Tinha só fingia que tinha avançado.woocommerce_before_add_to_cart_button behaves when you've got a custom post type feeding product variations. I hadn't forgotten. I'd just been pretending I had moved on.

Esse projeto reformulou completamente a forma como penso meu papel.

---

O Que "Founder Who Codes" Realmente Significa

Isso não significa que estou construindo cada feature. Não estou. Seahawk tem desenvolvedores muito melhores que eu em coisas específicas, animação, gerenciamento complexo de estado em React, otimização de banco de dados em escala. Isso não é falsa modéstia. É verdade.

Mas programar como fundador significa que nunca perco a sensibilidade do trabalho. Existe uma diferença entre gerenciar um projeto e entendê-lo. Quando um desenvolvedor me diz "isso vai levar duas semanas," posso fazer a pergunta certa: "são duas semanas porque a autenticação da API é genuinamente complexa, ou porque estamos reconstruindo algo que já existe em um plugin do WordPress?"feel of the work. There's a difference between managing a project and understanding one. When a developer tells me "this will take two weeks," I can ask the right question, "is that two weeks because the API authentication is genuinely complex, or because we're rebuilding something that already exists in a WordPress plugin?"

Você não consegue fazer essa pergunta de 10 mil metros de altura. Simplesmente não consegue.

O Problema da Estimativa

A coisa sobre estimativas de software é essa: são histórias que desenvolvedores contam para si mesmos tanto quanto contam para clientes. Já vi um dev sênior cotar quatro dias para um endpoint custom de WordPress REST API que levou seis horas uma vez que sentei com ele e escopei corretamente. Não porque ele fosse preguiçoso. Porque nenhum de nós tinha investigado o que o endpoint realmente precisava fazer.WordPress REST API endpoint that took six hours once I sat down with them and scoped it properly. Not because they were lazy. Because neither of us had dug into what the endpoint actually needed to do.

Quando você programa regularmente, seu detector de BS para estimativas melhora. Dramaticamente.

---

Isso Me Faz um Cliente Melhor, Internamente

Uma coisa que ninguém te conta sobre rodar uma agência: seus desenvolvedores são seus clientes internos. Você tem que convencê-los de boas decisões assim como convence clientes externos. E você perde essa capacidade no momento em que para de falar a língua deles.

Uso Figma para handoffs de design. Uso Git (especificamente GitHub, movemos tudo para lá do Bitbucket em 2021). Escrevo tickets reais no Linear com especificidade suficiente para um desenvolvedor começar o trabalho sem uma reunião de kickoff. Só esse último salvou a gente de uns 40 minutos por projeto, e a gente roda muito projeto.Figma for design handoffs. I use Git (specifically GitHub, we moved everything there from Bitbucket in 2021). I write actual tickets in Linear with enough specificity that a developer can start work without a kickoff call. That last one alone has saved us probably 40 minutes per project, and we run a lot of projects.

Nada disso é possível se você foi totalmente para "big picture." Você precisa saber o que um desenvolvedor precisa em um ticket. Você só sabe isso se já sentou do outro lado.

A Code Review Que Ninguém Espera do Chefe

Ocasionalmente deixo um comentário em um PR. Não para microgerenciar, deixo isso explícito. Mas uma nota como "esse filter está rodando em cada page load, conseguimos cachear o resultado?" sinaliza algo importante: estou prestando atenção no nível que importa.

Desenvolvedores respeitam isso. Alguns ficam surpresos com isso. E honestamente, os que se incomodam com isso, isso também me diz algo útil.annoyed by it, that tells me something useful too.

---

As ferramentas que eu realmente uso em 2024

Minha stack é vergonhosamente pouco elegante para um tech founder. VS Code com um punhado de extensões (Prettier, GitLens, PHP Intelephense). Um ambiente de desenvolvimento local rodando LocalWP, mudei de MAMP em 2020 e nunca olhei para trás. Terminal para tudo relacionado a Git porque nunca confiei totalmente em nenhuma GUI.LocalWP, I switched from MAMP in 2020 and never looked back. Terminal for everything Git-related because I never fully trusted any GUI.

Quando estou trabalhando em projetos de clientes, ainda recorro ao WordPress. Construímos em Webflow, Shopify, Laravel customizado, mas WordPress é onde sou mais rápido, e velocidade importa quando você está entrando e saindo em vez de fazer sessões focadas de 8 horas.

Usei Coolors.co na terça passada para puxar uma paleta de marca para um ajuste rápido na landing page de um cliente. Levou quatro minutos no total. Teria levado uma hora para briefar um designer, esperar e revisar. Essa é a vantagem do founder codando em miniatura.

---

O que você realmente perde quando para

A maioria dos founders que se afastam do editor se convence de que vão permanecer técnicos por osmose. Vão absorver através de stand-ups e threads no Slack. Não vão.

Aqui está o que realmente acontece:

  • Seu vocabulário vai derivando. "API", "webhook", "cache invalidation", você começa usando essas palavras sem saber o que significam no contexto específico da sua stack.
  • Você perde a capacidade de fazer protótipos. Uma sessão de codificação de duas horas consegue responder uma pergunta do produto que três reuniões com stakeholders não conseguiram.
  • Você fica dependente da disponibilidade dos desenvolvedores para pequenas decisões. Algo que costumava levar 20 minutos agora requer agendamento.
  • Os desenvolvedores percebem. Nem todos vão dizer, mas há uma mudança sutil em como eles se engajam com um founder que claramente não mexe no trabalho há anos.

Vi isso acontecer com pessoas que respeito. Pessoas boas que construíram agências genuinamente técnicas, depois gradualmente se abstraíram de sua própria expertise. No quinto ano estavam gerenciando o negócio inteiro e eram bons nisso, mas tinham perdido algo que não conseguiam nomear com precisão.

---

O Contraargumento (E Por Que Discordo Dele)

O caso mais forte contra founder-coding é o custo de oportunidade. Paul Graham escreveu sobre isso em várias formas, a ideia de que founders devem fazer coisas que não escalam, mas também que foco é a única vantagem real que uma operação em estágio inicial tem.Paul Graham has written about this in various forms, the idea that founders should do things that don't scale, but also that focus is the only real advantage an early-stage operation has.

Justo. Genuinamente justo.

Mas acho que esse argumento se aplica mais claramente a founders de produto em startups backed por VC do que a founders de agência e freelancers. Nosso contexto é diferente. Não temos um problema de runway que coding distrai. Temos um problema de qualidade e confiança, e coding é parte de como resolvemos isso.

Quando Seahawk apresenta uma migração complexa de WordPress para um cliente enterprise, o fato de um co-founder conseguir discutir estrutura de tabelas de banco de dados e constantes de wp-config em detalhe não é algo trivial. Muda a sala.

---

Como Protejo Meu Tempo de Código Sem Que Vire um Problema

Isso levou anos para eu descobrir. Genuinamente. Eu costumava codar reativamente, apenas quando algo quebrava ou um developer estava travado. Isso é o pior dos dois mundos. Você está no código mas estressado, nunca em flow.

Agora faço assim:

  1. Bloquei 90 minutos nas manhãs de segunda e quinta. Sem chamadas antes das 9:30am nesses dias. Inegociável, na agenda desde 2022. No calls before 9:30am those days. Non-negotiable, in the calendar since 2022.
  2. Mantenha um "founder's project" rodando o tempo todo. Algo pequeno, uma ferramenta pessoal, uma micro-feature de cliente, uma automação interna. Agora é um script Python que puxa nosso status de projeto do Linear e formata um digest semanal. 180 linhas, nada sofisticado. Something small, a personal tool, a client micro-feature, an internal automation. Right now it's a Python script that pulls our project status from Linear and formats a weekly digest. 180 lines, nothing fancy.
  3. Reviso pelo menos um PR por semana. Mesmo que seja só para ler. Fico no diff. Even if it's just to read. Stay in the diff.
  4. Reconstruo algo do zero uma vez por trimestre. Uma landing page, um plugin, uma pequena integração. O que for. O ponto é manter as habilidades aguçadas nos fundamentos. A landing page, a plugin, a small integration. Whatever. The point is staying sharp on fundamentals.

O tempo total é talvez 4-5 horas por semana. É isso. Ninguém está sugerindo que você faça sprints.

---

FAQ

Programar torna você um CEO ou co-fundador pior?

Apenas se você deixar isso ocupar o lugar de responsabilidades reais de liderança. O problema não é coding, é usar coding como estratégia de evitação para o trabalho mais difícil de founder: conversas difíceis, decisões de contratação, pensamento comercial. Se você está abrindo o editor quando deveria estar falando com um cliente saindo, isso é um problema. Mas 4 horas por semana numa quinta-feira de manhã não é negligência de liderança.avoidance strategy for the harder founder work: difficult conversations, hiring decisions, commercial thinking. If you're opening the editor when you should be talking to a churning client, that's a problem. But 4 hours a week on a Thursday morning isn't leadership negligence.

E se meu time me vê programando e pensa que não confio neles?

Seja direto sobre isso. Já falei explicitamente com meu time: "Quando escrevo código, não é um sinal de que acho que vocês estão errados ou lentos. É como eu mantenho os pés no chão no que realmente construímos." Essa conversa leva 90 segundos e na maioria das vezes só precisa acontecer uma vez.

Isso é realista para fundadores que comandam times maiores?

Honestamente, mais difícil com 50 pessoas do que com 15. Mas o princípio escala, mesmo que a prática mude. Em certo tamanho, "coding" pode significar revisar decisões de arquitetura, fazer um spike exploratório por trimestre, ou entender profundamente o que está dentro de um relatório de performance do Lighthouse em vez de escrever o fix você mesmo. O ponto é: não deixe sua fluência técnica atrofiar completamente.Lighthouse performance report rather than writing the fix yourself. The point is: don't let technical fluency atrophy entirely.

Quando um fundador deve genuinamente se afastar do código?

Quando coding está bloqueando alguém de crescer. Se um developer está esperando seu PR review para fazer merge do trabalho deles, e você é consistentemente o gargalo, esse é o sinal. Dê um passo atrás do caminho crítico. Você ainda pode escrever código, apenas não no main branch às 2 da manhã.critical path. You can still write code, just not on the main branch at 2am.

---

Programação me mantinha honesto. É a forma mais simples que conheço de expressar isso. Quando você ainda consegue ler um diff, estimar uma feature e colocar algo pequeno em produção por conta própria, você enxerga seu próprio negócio com mais clareza. Você sabe o que é realmente difícil e o que é apenas mal explicado. Essa clareza vale mais do que as quatro horas por semana que custa.

Ainda abrindo o editor. Provavelmente continuarei até não conseguir fisicamente.

< BACK