Tem uma mentira confortável que a gente conta pra si mesmo: que dev bom nasce pronto. Que existe um talento mágico separando quem escreve código limpo de quem escreve espaguete. Passei tempo demais acreditando nisso — até cair na Software Craftsmanship Brasília (SCCB) e perceber que o negócio é ofício. Ofício se treina.
Programar é ofício, não dom
Software craftsmanship é encarar programação como artesanato: um trabalho que você melhora com prática deliberada, não com sorte. A SCCB é uma comunidade que faz exatamente isso — junta gente em encontros presenciais e remotos síncronos pra resolver katas juntos e compartilhar as soluções depois.
Não é filosofia de LinkedIn. É gente sentada resolvendo o mesmo problema, comparando abordagens e discutindo por que a sua ficou melhor que a minha.
O que raios é um kata
Kata é um termo emprestado das artes marciais: um exercício que você repete pra afiar o movimento. Em código, é um probleminha bem delimitado que você resolve de novo e de novo — não pra 'terminar', mas pra praticar como você resolve.
A gente puxa katas de fontes como o kata-log.rocks e a Codurance. O ponto não é a resposta certa. É reparar nas suas decisões: onde você complicou, onde pulou o teste, onde deu pra simplificar. Repetir o básico com atenção é o que separa quem tem cinco anos de experiência de quem tem o mesmo ano repetido cinco vezes.
Praticar junto vence o grind solitário
Estudar sozinho tem um teto. Você não enxerga seus próprios vícios, ninguém questiona seu 'tá bom assim', e o feedback demora semanas — quando vem.
Na comunidade, o feedback é na hora. Alguém olha seu código e pergunta 'por que você fez assim?'. Às vezes você defende, às vezes percebe que nem sabia por quê. Esse atrito é o aprendizado acontecendo. Praticar em grupo transforma erro em conversa, e conversa em padrão compartilhado — coisa que nenhum tutorial no YouTube entrega.
Os princípios que a gente vive (e não só cita)
A SCCB codifica um conjunto de princípios que aparecem em toda kata. Não como decoração de slide — como coisa que a gente cobra um do outro na prática:
- YAGNI e KISS: não construa o que ninguém pediu, e mantenha simples.
- DRY: não repita conhecimento espalhado pelo código.
- Red-Green-Refactor (TDD): teste que falha, código que passa, código que melhora — nessa ordem.
- SOLID e Clean Code: design que aguenta mudança e código que a próxima pessoa entende.
- AAA (Arrange-Act-Assert) pra estruturar teste, e Given-Should-Then pra nomear teste de um jeito que conta uma história.
São siglas que viram hábito quando você as pratica em comunidade, com alguém do lado apontando quando você as ignora.
Como a DW-Corp vira isso em treino de verdade
Na DW-Corp a gente não trata isso como hobby de fim de semana — é como formamos e nivelamos profissional. A lógica é direta: se craftsmanship se aprende praticando junto, então a gente monta o ambiente pra isso acontecer.
Na prática significa quatro coisas. Katas recorrentes, pra todo mundo manter o movimento afiado. Pareamento, porque duas cabeças no mesmo problema aprendem mais rápido que quatro olhos em telas separadas. Code review de verdade, onde a pergunta é 'por que' e não só 'aprova'. E padrões compartilhados — os princípios acima viram o vocabulário comum do time, então 'isso aqui tá DRY?' é uma frase que todo mundo entende igual.
O resultado é gente júnior que evolui em meses o que levaria anos sozinha, e gente sênior que continua afiada porque ensinar é a melhor forma de não enferrujar.
Se você tá em Brasília e cansou de estudar sozinho batendo cabeça, aparece. A gente compartilha as soluções, o Instagram tá aberto, e a real é que ninguém vira bom de código no isolamento. Ofício se aprende no coletivo — e o melhor dia pra começar a praticar foi ontem. O segundo melhor é o próximo encontro.
