Fim de semana. Você abre o VS Code, coloca um lo-fi, e em 4 horas implementa um sistema de autenticação com OAuth2, JWT refresh tokens, rate limiting, e ainda faz deploy com CI/CD.
Segunda-feira. Você passa o dia inteiro tentando adicionar um campo no formulário porque precisa de aprovação de 3 times, o banco é gerenciado por outro departamento, e o deploy só roda às quintas.
O código que você escreve em casa
# Side project às 2h da manhã class PaymentProcessor: async def process(self, payment: Payment) -> Result: validated = await self.validate(payment) charged = await self.gateway.charge(validated) await self.notify_user(charged) return Result.success(charged)
Clean. Simples. Funciona. Você escolheu a stack, desenhou a arquitetura, e não teve que explicar pra ninguém por que não usou o framework interno que ninguém gosta.
O código que você escreve no trabalho
# Trabalho às 15h, depois de 2 reuniões class PaymentProcessorV2LegacyBridgeAdapter: def process(self, payment_dict, legacy_flag=True, use_new_gateway=False): # TODO: remover quando migrarmos (2019) if legacy_flag and not use_new_gateway: return self._old_process(payment_dict) # João pediu isso, não sei por quê elif legacy_flag and use_new_gateway: payment_dict['__hack_mode'] = True return self._hybrid_process(payment_dict) # Isso nunca vai rodar else: return self._new_process(payment_dict)
E olha que você nem queria escrever assim. Mas tem o sistema legado. E a API do fornecedor que não segue padrão nenhum. E o requisito que mudou no meio do sprint.
Por que isso acontece?
1. Restrições vs liberdade
Em casa: "Vou usar PostgreSQL porque é o melhor pro meu caso." No trabalho: "A empresa tem contrato com Oracle, então..."
2. Escopo controlado
Em casa: Você constrói exatamente o que precisa. No trabalho: Você herda 7 anos de decisões que outras pessoas tomaram.
3. Perfeccionismo seletivo
Em casa: "Vou refatorar isso até ficar perfeito." No trabalho: "Funciona? Ship it. Tem mais 15 tickets no backlog."
4. A audiência é diferente
Em casa: Você mesmo (e talvez 3 pessoas no GitHub). No trabalho: Product managers, clientes, compliance, e aquele dev que vai manter isso daqui a 2 anos.
O plot twist
Aqui está o segredo que ninguém fala: seu código de trabalho provavelmente é mais valioso.
Seu side project lindo e bem arquitetado? Serve 0 usuários e gera $0.
Aquele código feio no trabalho com 47 flags e comentários em português misturado com inglês? Processa milhões de transações e paga seu salário.
O equilíbrio
Não estou dizendo pra aceitar código ruim. Estou dizendo pra entender o contexto.
- Side projects são seu playground. Experimente, erre, refatore 10 vezes. É assim que você aprende.
- Trabalho é onde você aplica pragmatismo. Às vezes "bom o suficiente" é a resposta certa.
O dev experiente sabe quando lutar por qualidade e quando aceitar trade-offs. Nem todo código precisa ser obra de arte, às vezes ele só precisa resolver o problema e não quebrar em produção.
TL;DR
Seu código pessoal é "melhor" porque você controla todas as variáveis. No trabalho, você é uma variável no sistema de outra pessoa.
E tá tudo bem. Continua fazendo seus side projects lindos. Eles te mantêm afiado pra sobreviver ao código legado de segunda-feira.
Agora, se você achar um emprego onde consegue codar igual em casa... me avisa.