Backlog #7 - As 10 Lições Que Mudaram a Minha Vida como Dev

Mais um dia, mais um backlog! Hoje, trago algo diferente: As 10 lições mais importantes que aprendi em 13 anos como dev.

Muita gente já me perguntou sobre dicas e aprendizados essenciais na minha carreira. Confesso que deixei essa ideia de lado por um tempo, até que me deparei com um post no final do ano que me fez lembrar dessas perguntas.

Então hoje eu quero falar sobre as 10 lições mais importantes que eu aprendi em 13 anos de carreira como dev. Lembrando que essas lições estão só no âmbito de desenvolvimento, então tudo que eu falar por aqui é relacionado estritamente à isso.

1 - Seu código não é seu: Nada vai ser como você quer

A primeira (e, talvez, mais importante) lição é que o código nunca será exatamente como você quer. A única maneira de fazer tudo do seu jeito é trabalhando sozinho em um projeto pessoal. Mas, no trabalho em equipe, você sempre vai precisar ceder e se adaptar.

No começo, eu queria que tudo fosse do meu jeito. Quando alguém criticava meu código, eu achava que era um ataque pessoal. Com o tempo, percebi que estava errado.

O código não é só seu. Ele precisa ser fácil de entender para que outras pessoas possam mexer nele no futuro. O mais importante não é escrever do jeito que você gosta, mas sim garantir que toda a equipe consiga trabalhar bem com ele. Aprender a aceitar feedbacks, conversar sobre soluções e deixar o orgulho de lado são habilidades essenciais para um bom programador.

2 - Elegância é para moda, você precisa ser pragmático

Quantas vezes você já encontrou um código impossível de entender? Ou um código tão abstrato que parece tentar prever todos os casos de uso do mundo? Ou então aquele código "elegante" que só o autor compreende?

A realidade é que o código que a gente faz não é para a máquina, a gente já resolveu esse problema há muito tempo com compiladores. Eles otimizam seu código para que a máquina leia da forma mais eficiente possível. O seu trabalho é fazer código que outras pessoas vão ler e dar manutenção. Uma frase que me marcou muito foi:

A maioria dos sistemas não são bons o suficiente para se tornarem legados.

Isso é uma verdade brutal. Apenas sistemas bem projetados e robustos sobrevivem por anos ou décadas. Eu comento bastante sobre isso, mas um bom sistema, para mim, é composto de três pilares:

• Documentação bem escrita e código que seja legível e comentado
• Que segue as práticas atuais do time
• Não possui abstrações complexas e é simples o suficiente dentro do seu escopo

Já me crucificaram muito por falar de comentar código, ou então quando eu falo veementemente que não gosto de programação funcional porque eu acho que, além de difícil de ler e entender, exige um conhecimento prévio bem grande. Mas essas afirmações são fundadas em uma simples frase:

Nunca assuma que todas as pessoas são iguais a você

Nem todos vão entender imediatamente o código que você escreveu. Nem todos conhecem programação funcional. E, honestamente, você mesmo pode não compreender seu próprio código daqui a alguns meses se não deixá-lo claro.

Priorize sempre a facilidade de manutenção e o alinhamento com as práticas da equipe, ao invés de criar soluções "elegantes", mas difíceis de entender.

3 - Não existe planejamento

Quantas vezes já ouvi a frase: "Precisamos entregar isso amanhã, é urgente!" Mas quando tudo é urgente, nada é urgente, certo? Essa foi uma das lições mais importantes que aprendi trabalhando em startups:

O que importa é o que está acontecendo agora

Você pode planejar seu projeto e seu sistema o quanto quiser, mas se algo mais importante surgir no meio do caminho, sem dúvida, todo o planejamento será jogado de lado para perseguir esse novo objetivo. Startups são basicamente fundadas nessa ideia de serem barcos pequenos e rápidos, fáceis de virar e pegar o vento mais forte naquele momento. Por isso, um planejamento sólido raramente sobrevive por muito tempo.

Já em grandes empresas, o problema é o oposto: Planejamento em excesso. Tudo leva meses para acontecer, mas, ao mesmo tempo, tudo é tratado como prioridade máxima. O resultado? Muitas vezes ninguém sabe exatamente por que algo precisa ser feito e, depois de entregue, ninguém sabe quem pediu ou para que serve.

No fim das contas, sempre achei mais eficiente focar nos objetivos em vez de um planejamento rígido. Em vez de tentar prever cada passo, o ideal é definir claramente "o que precisa ser feito" e manter uma visão de longo prazo. Isso gera resultados mais consistentes e evita desperdício de tempo com planos que logo se tornam obsoletos.

4 - As vezes menos é mais

Quantas vezes a gente não ficou empolgado com uma ideia ou com um framework novo ou com um novo conceito que queríamos tanto aplicar que acabamos fazendo um FizzBuzz Enterprise?

A grande lição aqui é que, muitas vezes, nosso projeto não é grande ou crítico o suficiente para justificar todas as tecnologias e padrões que queremos aplicar. Uma boa arquitetura é importante, mas será que você realmente precisa de K-anonymity e de todos os design patterns existentes para um simples sistema de to-do list? Aquele pequeno sistema com 10 clientes realmente precisa se proteger contra todas as CVEs já registradas, mesmo quando aplicar essas correções pode ser mais trabalhoso do que benéfico?

As vezes menos é mais, tirar coisas do projeto para que ele possa ir para frente é o caminho mais rápido para saber se você precisa ou não melhorar a arquitetura do seu sistema.

5 - Tecnologia é um trade-off

A clássica piada do desenvolvedor sênior que responde tudo com "depende" tem um fundo de verdade. Não existe uma bala de prata em tecnologia que resolva todos os problemas. Um professor meu na faculdade costumava dizer:

Toda decisão que melhora algo em uma parte, piora algo em outra parte

Ele comparava a programação a um pacto: Você sempre sacrifica algo para obter uma solução, porque qualquer escolha tem efeitos colaterais.

O importante é lembrar que você nunca vai tomar boas decisões, você sempre vai tomar decisões que são boas para algo e ruins para outro algo, um exemplo clássico disso é segurança: Quanto melhor e mais resistente o algoritmo de criptografia, mais lento ele vai ser. Ou então quando eu comentei no meu artigo sobre RSA, as chaves podem ser arbitrariamente grandes, mas existe um ponto onde ela é suficiente.

Os suecos tem uma palavra chamada lagom, que é uma forma de dizer "apenas o suficiente" ou "nem mais, nem menos". Esse conceito resume bem essa lição: A melhor escolha é aquela que equilibra necessidades sem excessos.

6 - Tecnologia vem e vai, bases ficam

Isso é algo que todo desenvolvedor aprende mais cedo ou mais tarde. É uma daquelas lições fundamentais da carreira.

Chega um momento em que você se cansa de aprender algo novo todos os dias, de estar sempre correndo atrás do framework da moda, da última inovação em IA ou do mais recente padrão de arquitetura. Se você baseia seu conhecimento apenas em ferramentas, é como um pedreiro que acredita que só pode martelar com um martelo, sem perceber que qualquer coisa pesada pode cumprir a mesma função.

A tecnologia funciona da mesma forma. As ferramentas vêm e vão. Eu comecei com Delphi e Visual Basic, que hoje quase não existem. Se meu aprendizado tivesse sido focado apenas neles, minha carreira já teria chegado ao fim. O que realmente importa é entender os fundamentos, porque eles continuam relevantes independentemente da tecnologia usada.

Preste atenção nas aulas de algoritmos, complexidade ciclomática e até no pseudocódigo. Talvez escrever código no papel, como os Maias e Astecas faziam, já te ajude muito a lembrar.

Porque, quando a hype da linguagem atual passar, você saberá como continuar para a próxima. Mas lembre-se:

O mercado sempre vai estar em hype com alguma coisa, isso não significa que você tem que surfar todas as ondas

7 - Feito é melhor do que perfeito?

Existia uma frase que um CTO meu falava que me deixava muito irritado: "Feito é melhor que perfeito". E isso acontecia por dois motivos:

1. Eu achava que tudo deveria ser perfeito (veja o item 1)
2. Eu não suportava a ideia de entregar as coisas sem estarem finalizadas

Depois de muito tempo eu entendo o que essa frase realmente significa. Não é que você precise entregar as coisas mal feitas e de qualquer jeito só para que o sistema vá para frente. Se alguém está te pedindo para fazer isso, então você está com toda a razão em recusar, mas é sobre saber dosar o quanto é "BOM O SUFICIENTE" (LAGOM).

Existe um manifesto muito legal que descreve tudo que eu estou falando aqui. Ele se chama The cult of done (video):

8 - Seja seu próprio oponente

Por muito tempo, eu via outras pessoas falando sobre os prêmios que ganharam e as conquistas que alcançaram. Eu olhava para tudo isso com admiração, querendo estar naquele mesmo lugar. Meu grande sonho sempre foi criar algo útil, algo que as pessoas realmente usassem e gostassem. Eu queria ser o Ken Thompson, o Dennis Ritchie ou, quem sabe, o Bill Joy da modernidade.

Com o tempo, percebi que me comparava demais com os outros, sempre me sentindo menos importante por não ter algo grandioso para mostrar. Isso me fazia mal. Mas quando parei para refletir, notei que as pessoas que fizeram coisas incríveis tinham apenas um verdadeiro adversário: Elas mesmas.

Você só precisa se comparar com quem você era ontem e buscar ser melhor do que essa versão. Ninguém mais importa nessa equação.

Faça algo que faça sentido para você. Todo o resto é consequência.

9 - Faça o que você gosta

Parece clichê até você ser forçado a fazer algo que não gosta. E isso aconteceu comigo durante um emprego que tive. Era uma empresa que eu queria muito trabalhar, mas quando entrei percebi que eu estava fazendo algo que estava cada vez mais distante do que eu gostava de fazer, da minha realidade, do que me deixava feliz. E isso impactou não só meu rendimento, mas também a forma como eu via meu próprio trabalho.

A verdade é que você precisa direcionar sua carreira para algo que realmente gosta. Não adianta insistir em front-end se sua paixão é back-end, ou se aventurar em infraestrutura quando o que realmente te empolga é banco de dados. Perseguir o que você gosta é essencial, mas isso não acontece do dia para a noite. Muitas vezes, será necessário passar por um período fazendo algo que não te satisfaz para dar o próximo passo. É o famoso "um passo para trás para dar dois para frente".

Mas também não se acomode demais nas coisas que você está fazendo e nem foque só em fazer as coisas que você gosta a todo momento, até porque nada de bom acontece dentro da sua zona de conforto.

10 - Talk is cheap

Durante todos esses anos, eu acabei notando que a máxima "Quem muito fala pouco faz" foi se tornando cada vez mais verdade (inclusive temos uma edição só falando disso). No mundo atual, isso se intensifica ainda mais com a explosão de influenciadores e o excesso de informações despejadas sobre nós. Não acredite em influenciadores, seja você a sua própria influência.

O ponto é que você não deve acreditar somente no que as pessoas falam pra você, muita gente fala demais, vende coisas demais mas nunca de fato coloca a mão na massa. A prova disso é que a maioria das pessoas que criaram coisas incríveis sequer tem rede social ou, se tem, mantêm um perfil super discreto.

Busque suas próprias conclusões. É válido se inspirar em outras pessoas, afinal, nada nasce do zero. Mas jamais permita que alguém guie todo o seu pensamento. Essa lição vale para tudo na vida, não apenas para o desenvolvimento.

Quero saber quais lições que você aprendeu ao longo da sua carreira! Comenta lá nas minhas redes!