DEV Community: Yuri Souza

Pensar demais nem sempre ajuda e o que eu aprendi com isso

Yuri Souza — Sat, 01 Aug 2026 10:57:53 +0000

Às vezes, a maior barreira para começar um projeto não é a complexidade do problema, mas a busca por uma solução perfeita antes mesmo da primeira linha de código.

Na semana passada decidi criar um pacote Laravel para integrar a API do Asaas.

A ideia parecia simples: construir algo reutilizável para projetos futuros e, de quebra, aprender mais sobre desenvolvimento de pacotes.

Foi então que eu:

Abri a IDE e comecei a criar um cliente HTTP simples para a API da Asaas.
15 minutos depois, eu já estava pesquisando sobre arquitetura de pacotes open source.
Pensei em DTOs.
Pensei em interfaces.
Pensei em Services

O que eu entendia por "perfeito"?

Na minha cabeça, um projeto bem feito precisava nascer parecido com os grandes projetos open source que eu admirava.

Antes mesmo de validar a ideia, eu já pensava na arquitetura, na escalabilidade e em como aquele pacote pareceria para quem abrisse o repositório. E em outros cenários como:

pensar na mesma arquitetura que grandes projetos usam antes de ter o primeiro caso de uso funcionando;
tentar abordar todos os pontos da API da Asaas logo no começo, mesmo sem saber quais eu realmente ia usar;
imaginar os atrativos que meu pacote teria para outros quererem usá-lo, antes de ele fazer qualquer coisa útil.

No papel, parecia que eu estava pensando como alguém mais experiente, mas na prática, eu estava:

apenas adiando a parte mais importante que era escrever código que resolvesse um problema real.

O custo disso na prática

O curioso é que eu terminava o dia com a sensação de que tinha trabalhado bastante. Tinha lido sobre arquitetura, desenhado camadas, esboçado interfaces.

Só que, olhando para o projeto, praticamente nada tinha sido construído: nenhuma requisição enviada, nenhum teste rodando, nenhuma prova de que qualquer uma daquelas decisões fazia sentido.

Com o tempo, isso começou a gerar um padrão:

Mais tempo buscando a estrutura "perfeita" do que resolvendo o problema real;
Código difícil de entender por estar "bem arquitetado" demais, cedo demais;
Medo de refatorar algo que ainda nem tinha provado valor;
Uma frustração crescente por sentir que eu não estava evoluindo, só girando em torno da mesma decisão de design.

Não era falta de qualidade. Era complexidade antecipada.

O que eu estava realmente evitando?

Foi só depois que comecei a me perguntar outra coisa: por que eu estava tão preso nisso?

Algumas hipóteses:

Eu estava evitando escrever código que eu soubesse, de antemão, que ia precisar refatorar depois?
Eu tinha medo de escrever algo "ruim" e isso aparecer publicamente num repositório open source?
Eu queria provar, pra mim mesmo, que conseguia arquitetar "como um sênior" antes mesmo de ter o problema resolvido?

A resposta provavelmente era um pouco de cada uma. E nenhuma delas tinha relação com o problema que o pacote deveria resolver.

Só bem depois entendi que, no fundo, eu confundia complexidade com maturidade técnica.

O aprendizado que começou a aparecer

Enquanto refletia sobre isso, lembrei de uma frase que minha mãe repetia desde que eu era pequeno:

"Antes feito do que perfeito."

Sempre achei que essa frase servia para tarefas do dia a dia, como arrumar o quarto, terminar um trabalho da escola. Nunca imaginei que ela fizesse tanto sentido ao escrever software.

Junto com ela, veio outra ideia:

Bons sistemas não nascem perfeitos. Eles evoluem.

Nenhum dos projetos open source que eu admirava nasceu com a arquitetura que tem hoje; todos passaram por versões mais simples, mais cruas, que foram se modificando à medida que o uso real foi aparecendo.

Qualidade não está em prever todos os cenários.

Qualidade está em escrever código que consiga mudar quando esses cenários realmente aparecerem.

Foi só quando parei de procurar a arquitetura perfeita que finalmente escrevi minha primeira requisição de verdade para a API.

Antes mesmo de escrever a primeira integração, era assim que eu imaginava o pacote:

CustomerService
        ↓
AsaasClient
        ↓
CreateCustomerDTO
        ↓
Response

Mas não comecei com uma arquitetura cheia de camadas. Comecei com algo assim:

$asaas->customers()->create([
    'name' => 'Yuri Souza',
    'cpfCnpj' => '12345678909',
]);

Desde então, passei a repensar algumas atitudes:

resolver o problema atual com clareza antes de pensar no próximo;
manter o código simples, legível e testável;
criar abstrações apenas quando um padrão se repete de fato, não quando eu imagino que ele vai se repetir;
aceitar que refatorar faz parte do processo, não uma falha dele.

Não se trata de abandonar boas práticas, mas de aplicá-las no momento certo.

O equilíbrio que estou buscando hoje

Hoje tento encontrar um equilíbrio entre dois extremos: nem escrever código sem critério, nem criar uma arquitetura complexa antes que ela seja necessária.

No próprio pacote do Asaas isso já mudou a forma como estou trabalhando.

Hoje, a decisão que tomei foi outra: começar pelo caminho mais curto possível.

Primeiro quero que o pacote consiga conversar com a API e validar os casos de uso mais importantes. Só então vou descobrir quais abstrações realmente fazem sentido.

Em vez de tentar prever a arquitetura que o projeto terá daqui a um ano, prefiro deixar que ela se desenvolva à medida que novos problemas surgirem.

Foi aí que entendi uma coisa importante:

Arquitetura não é algo que eu preciso descobrir antes de começar. É algo que o próprio projeto vai mostrando à medida que cresce.

Conclusão

Ainda estou no começo desse pacote, e ainda estou aprendendo isso na prática, errando e ajustando no caminho.

Mas entender que "perfeição antecipada" pode virar um problema já foi um passo importante na minha evolução como desenvolvedor. O projeto do pacote Asaas não precisa da arquitetura perfeita logo de início; precisa apenas da primeira implementação. O resto vai aparecer conforme o uso real for mostrando o caminho.

Hoje prefiro um código simples que aceite mudanças a uma arquitetura impecável que resista a qualquer alteração.

Se você também já caiu nessa armadilha da arquitetura perfeita antes da hora, quero saber: como você percebeu e o que fez para sair dela?

A discussão continua nos comentários. Quero muito conhecer outras experiências e perspectivas sobre esse tema.

Agradecimentos: obrigado a @vitoriazzp pelo feedback sincero e pelas sugestões que ajudaram a tornar este artigo mais claro e útil.

Por que eu começo 10 projetos e não termino nenhum?

Yuri Souza — Sun, 05 Apr 2026 23:48:52 +0000

Você já passou uma tarde inteira configurando um projeto novo, escolhendo a stack, criando o repositório, estruturando as pastas e sentiu que estava voando? Aquela sensação de que dessa vez vai ser diferente, que essa ideia é boa demais pra morrer na gaveta? Eu também. O problema é que dois dias depois eu estava fazendo exatamente a mesma coisa, só que com outra ideia.

Se você se identificou, esse artigo é pra você. Não porque eu tenho a solução mágica, mas porque finalmente entendi o mecanismo por trás disso. E entender já muda muita coisa.

O prazer de começar
O momento em que tudo desmorona
O objeto brilhante
A culpa que ninguém fala
Não é preguiça. É neurologia.
Conclusão

O prazer de começar

Tem algo muito específico que acontece quando você começa um projeto novo.

O problema ainda não existe de verdade. Tudo é possibilidade. Você ainda não encontrou o bug impossível de reproduzir, ainda não percebeu que a arquitetura que escolheu não escala, ainda não chegou na parte chata de fazer o CRUD de usuário pela décima vez na vida.

Nessa fase, o cérebro libera dopamina. Bastante. A antecipação de uma recompensa futura ativa os mesmos circuitos que uma conquista real. Ou seja: só de imaginar o projeto funcionando, você já sente parte da recompensa.

Isso explica o prazer visceral do setup. Escolher o nome do repositório, montar a estrutura de pastas, escrever o README antes de ter uma linha de código que funciona... tudo isso alimenta aquela sensação.

O problema? É que ela passa.

O momento em que tudo desmorona

Existe um ponto específico em todo projeto onde a magia some. Eu chamo de o vale do tédio.

É quando você já sabe o que precisa fazer, mas o trabalho deixou de ser estimulante. As decisões arquiteturais foram tomadas. O setup tá pronto. Agora é só... executar. Implementar a feature chata. Escrever o teste. Lidar com o caso que você não previu.

Para a maioria das pessoas, esse momento é desconfortável mas passável. Você empurra, entrega, segue.

Para alguns cérebros, incluindo o meu, esse momento é quase fisicamente doloroso. Não é falta de vontade. É que o sistema de recompensa do cérebro simplesmente não libera o combustível necessário pra continuar uma tarefa que deixou de ser nova.

E aí começa o ciclo de autos sabotagem mais clássico do mundo do dev:

"Antes de continuar, vou refatorar essa parte aqui."

"Preciso repensar a arquitetura antes de avançar."

"Deixa eu criar um boilerplate melhor pra usar nos próximos projetos."

Você não está sendo preguiçoso. Você está inconscientemente procurando a dopamina do recomeço dentro do próprio projeto.

O objeto brilhante

E então aparece. Uma ideia nova.

Pode ser um problema que você viu no trabalho, uma conversa no Twitter, um repositório no GitHub que te inspirou. De repente, aquela ideia nova parece muito mais interessante do que o projeto que você abandonou no vale do tédio.

E ela realmente é, pelo mesmo motivo que o projeto anterior era interessante no início. Ela ainda não tem o peso da implementação. Ainda não tem os bugs, as decisões difíceis, o trabalho repetitivo.

Esse fenômeno tem um nome informal: Síndrome do Objeto Brilhante. E ele é mais intenso em cérebros que têm dificuldade de regular dopamina naturalmente.

O que acontece na prática? O projeto antigo não morre oficialmente. Ele só vai pra uma pasta chamada projetos/ e fica lá, acumulando poeira junto com outros oito projetos que passaram pelo mesmo ciclo.

A culpa que ninguém fala

Aqui está a parte que eu não via ninguém discutir: a culpa.

Porque quando você abandona um projeto, você não apenas perde o projeto. Você coleciona evidência contra si mesmo.

"Eu nunca termino nada."
"Eu começo cheio de energia e nunca entrego."
"Por que eu deveria começar esse projeto se vou abandonar igual aos outros?"

E essa narrativa é perigosa por dois motivos.

Primeiro, porque ela não é completamente verdadeira. Você provavelmente termina muita coisa, no trabalho, em tarefas com prazo real, em situações onde tem alguém esperando. O problema não é terminar em si. É terminar coisas que dependem 100% da sua motivação interna, sem deadline, sem stakeholder, sem pressão externa.

Segundo, você começa a acreditar que não é capaz de terminar, então para de tentar de verdade, e aí realmente não termina. O ciclo se fecha.

Não é preguiça. É neurologia.

Vou ser direto: se você se reconheceu em tudo que eu escrevi acima, há uma chance real de que seu cérebro simplesmente funciona de um jeito diferente da média.

Tem um tipo de cérebro que odeia repetição mas ama coisa nova. Não é fraqueza, é como ele funciona. O problema é que todo projeto tem uma fase nova e uma fase chata — e esse cérebro simplesmente apaga na segunda.

Não é falta de disciplina. É que o combustível que o seu cérebro usa pra manter o foco não funciona igual ao de todo mundo.

A diferença entre entender isso e não entender é enorme. Quando você não entende, você passa anos se achando preguiçoso, incompetente, incapaz de terminar o que começa e quando entende você começa a fazer perguntas diferentes:

"Como eu estruturo esse projeto pra ter recompensas menores e mais frequentes?"

"Como eu crio pressão externa pra compensar a falta de pressão interna?"

"Qual é o menor projeto possível que ainda entrega valor?"

Não são perguntas fáceis de responder. Mas são as perguntas certas.

Conclusão

Eu ainda começo projetos demais. Provavelmente sempre vou começar. Mas aprendi a parar de tratar isso como um defeito de caráter e passei a tratar como uma característica que precisa de estratégia.

O problema nunca foi a quantidade de projetos que eu começo. Foi a narrativa que eu construí em volta dos que eu não terminei.

Se você chegou até aqui e se reconheceu em alguma parte desse texto: você não está sozinho. E você provavelmente é melhor em começar coisas do que 90% das pessoas. Isso não é pouco, é uma habilidade real, que só precisa de direção.

O próximo projeto vai começar. A questão é o que você vai fazer diferente dessa vez.

Escrito por alguém que tem pelo menos dez pastas projetos/ abertas no VS Code agora mesmo.

[Boost]

Yuri Souza — Tue, 24 Mar 2026 02:07:01 +0000

Construí um gerador de playlists no Spotify com Claude - DEV Community

Eu queria digitar “noite chuvosa, meio melancólica” e receber uma playlist perfeita. Então eu...

dev.to

DEV Community: Yuri Souza

Pensar demais nem sempre ajuda e o que eu aprendi com isso

O que eu entendia por "perfeito"?

O custo disso na prática

O que eu estava realmente evitando?

O aprendizado que começou a aparecer

O equilíbrio que estou buscando hoje

Conclusão

Por que eu começo 10 projetos e não termino nenhum?

Table of contents

O prazer de começar

O momento em que tudo desmorona

O objeto brilhante

A culpa que ninguém fala

Não é preguiça. É neurologia.

Conclusão

[Boost]

Construí um gerador de playlists no Spotify com Claude - DEV Community