10 min de leitura ·

65 coisas que aprendi sendo um bom desenvolvedor.

Antes de mais nada, queria dizer que este post é grandemente inspirado neste post do r/experiencedDevs, porém traduzido para o português, adaptado a minha realidade de arquitetura, atividades open source e amplamente discutido com todos os programadores que já conheci em minha curta vida.

Li este post interessante no r/experiencedDevs quando foi escrito (~2y) e desde então venho conversado muito sobre ele e tenho feito algumas reflexões sobre essa vida de garoto de programa. Sempre anotava coisas relacionadas a este texto e adicionava minhas próprias modificações. Hoje, finalmente, decidi escrever meu próprio post.

Do mesmo modo que flipstables escreveu suas ideias em tópicos, eu também farei o mesmo. Pois este artigo será meu ponto de referência por muitos tempos.

A vida não está escrita em um livro de regras, e muito menos este post tenta padronizar todos os comportamentos existentes. Portanto, aproveite o que quiser, mas não espere aproveitar tudo e nem leve os exemplos ao pé da letra.

Nota do editor: Recebi vários feedbacks e vou anexar deixar um 🗨️ em todos os pontos que recomendo ler os comentários para entender melhor meu ponto.

Vamos lá?

🗨️ Se por algum motivo qualquer eu cogitar ser o mais inteligente de uma sala qualquer, está na hora de sair.
🗨️Não conheça quem está no seu pedestal. Paguei, uma vez, 5K USD para ter um curso com um dos meus heróis, para, no final das contas, descobrir que ele está seguindo sua vida assim como todos nós.
🗨️ Existe uma razão do porque pessoas recomendam sempre ficar no linkedin a procura de oportunidades. No momento que se sentir insatisfeito, está na hora de ir para a próxima.
🗨️ Para iniciantes, a """"linguagem de programação"""" mais lucrativa é aprender SQL. Dane-se todas as outras """"linguagens"""", se você sabe SQL e nada além, você FAZ dinheiro. Trabalha com suporte? Talvez 2K/mês, trabalha com suporte e sabe SQL? 5k/mês. Quer trabalhar como PO? 5k/mês. Quer trabalhar como dono de produto e sabe SQL? Se auto-entitule gerente de projeto e faça 10k.
🗨️O melhor modo de avançar de carreira é trocando de empresa. Esta imagem descreve melhor
Stacks de programação raramente importam na sua carreira. Deve ter por volta de uns 20 patterns de arquitetura que se aplicam à tudo. Todas as bibliotecas só tentam fazê-las mais simples, não se desespere com os 9 trilhões de frameworks lançados todos os dias no npm.
Eu já fiz várias duradouras amizades em empresas que trabalhei. Não preciso fazer disso um requisito para todos os meus empregos. Já fui feliz em empresas que não tive nenhuma amizade e já fui muito insatisfeito em empresas que fiz grandes amizades.
Não tenha medo de códigos/bibliotecas no NPM/Maven/Github/Etc, não são buracos negros escritos por Albert Einsteins. Foram escritos por alguém exatamente igual a você. Acreditar nisso é o maior passo que você pode ter para escrever códigos em geral.
Várias empresas inovadoras, principalmente as auto-intituladas startups, falam sobre seu "verdadeiro eu". Mas e se seu verdadeiro eu for de apenas assistir pornô? Sim, é completamente saudável manter uma barreira entre sua vida profissional e pessoal.
O número de projetos que um desenvolvedor pode ficar ao mesmo tempo são 2. Quando ele enjoa de um, pega uma task do outro e vice-versa. 1 é super aceitável, 3 projetos simultâneos e você já perdeu 50% de sua performance.
Se eu não aprendi nada de um júnior ou estagiário este mês, eu não estava prestando atenção o suficiente.
Seja grato e educado com todo mundo, você não sabe o que essa pessoa passou por essa semana/mês/ano. Não faça isso por que vai ajudar sua carreira (Com certeza vai), mas por que você também estará se agradecendo mais.
Crescimentos de título são boas, Júnior para Pleno, Pleno para Senior, Lead... Mais tarde em sua carreira, demoções de título são desejáveis, você acaba ganhando mais por ser uma promoção, porém consegue focar em um tópico. Em outras palavras, antes de chegar em Lead, alavancos de carreira te trazem dinheiro e responsabilidades, depois, apenas crescem seu salário.
Gerentes têm muito menos poder do que você pensa. Já se pegou pensando no porquê seu gerente não demite alguém? Simples, ele não pode.
Meu valor próprio não é uma correlação ou função com minha remuneração total. O capitalismo é uma maneira horrível de determinar meus valores.
Nunca trabalhei em uma FAANG, e por isso não posso dizer o que estou perdendo. Já trabalhei com muitos desenvolvedores ex-FAANG e eles também não sabem o que estão fazendo.
Trabalhar de casa é perfeito, porém a carência de brainstorms, whiteboarding e comunicações que temos em trabalhos presenciais fazem falta.
Eu sei o suficiente de websecurity para saber que não sei nada de websecurity.
Ser um bom desenvolvedor é conhecer as melhores práticas, ser um bom arquiteto é saber quando quebrar essas boas práticas.
Boa arquitetura de software não significa usar milhares de padrões, e sim usar a menor quantidade possível destes padrões sem engessar seu código.
Se você está em uma war room, e estão todos estão querendo colocar culpa uns aos outros do porque a algo está quebrado em prod, a culpa é unicamente e exclusivamente de TODO MUNDO.
Todo mundo ama um happy hour ou ir em um barzinho com o pessoal do trampo às sextas. Todo mundo, também, prefere muito mais passar esse tempo com amigos e família.
Nenhuma arquitetura pode ser horrível e continuar sendo horrível com a desculpa de ser mais performática, sem que métricas concretas comprovem a melhoria. Já com pedaços de código, qualquer mudança por velocidade é preferível.
🗨️ A melhor demonstração de liderança que você pode encontrar, é do líder que pega o esporro para ele, até de coisas que são 100% minha falta. Pode ter certeza que eu entraria debaixo em um caminhão por ele.
🗨️ Usar o terminal é melhor e mais eficiente que qualquer GUI já feito. Se você passa mais de 1 minuto tentando executar um comando no terminal, é melhor você voltar a usar um GUI.
Não é importante fazer o que eu amo, é importante eu não fazer o que eu odeio.
Nem todos os melhores empregos estão em grandes vales industriais, porém vários estão.
Ainda sobre líderes, os melhores que consegui trabalhar, faziam de tudo para advocar minhas opiniões e também faziam de tudo para me explicar opiniões conflitantes com a minha. Trabalhe duro para ser igual a eles.
🗨️ Algorítimos e estrutura de dados são importantes até um certo ponto. Não vejo entrevistas de emprego em farmácias terem provas sobre química orgânica. Temos várias premissas erradas em nossa indústria.
Problemas de visão e coluna são coisas seríssimas. Invista seu salário em bom equipamento. Temos problemas negativos em ser ratos de academia e programadores ao mesmo tempo.
Setups com múltiplos monitores são ótimos. 1 monitor e várias keybinds, te leva à uma maior produtividade. (Essa eu dedico ao ThePrimagen)
Disso tudo, saber escrever boas changes proposals é uma das maiores habilidades subestimadas.
Nunca é tarde para ajudar um projeto open source, você está pecando ao usar um OSS e não abrir issues para seus problemas.
Não importa qual é seu cargo, saber ter uma conversa altamente técnica, técnica, rasa, amigável, arquitetural e de produto, sendo todas sobre o mesmo assunto específico, te torna em alguém que os outros queiram ouvir e que facilmente terá suas ideias aceitas. Tudo corre com fundamentos em como você propõe uma ideia, e não sobre o que essa ideia se baseia.
TDD ou qualquer outro tipo de teste escrito demora e é custoso. Passar mais de 10 minutos no insomnia ou postman é mais custoso ainda.
Recrutadores externos são sanguessugas, mas se você achar algum bom, tenha uma boa relação com essa pessoa, ela claramente tem o poder de alavancar sua carreira.
Sabe como descobrir se um recrutador externo é bom? Se ele(a) passou mais de 3 anos como recrutador externo, provavelmente ele é ruim. Bons recrutadores sempre viram recrutadores de alguma grande empresa.
Eu nunca julguei uma linguagem de programação à fundo antes de virar altamente íntimo com ela. Hoje odeio java, porém trabalhei com java por um tempo. (Todo ódio ao GWT).
Uma tecnologia é boa e sobreviverá ao teste do tempo quando ela for ruim, mas mesmo assim você a recomendaria para um cliente.
Quanto mais perto estou do produto, mais perto estou da geração de receita e mais me sinto valorizado, independentemente de quão técnico seja o meu trabalho. Isso tem sido verdade até mesmo para as empresas mais progressistas.
Linux é importante até quando eu trabalhava apenas com Windows (WSL <3), pois eventualmente eu trabalhei com linux.
Todo desenvolvedor, independente do campo, deveria perder um final de semana tentando instalar arch linux no seu computador.
Bom código pode ser entendido por um júnior, ótimo código é entendível até por alguém na faculdade. O melhor código é não ter código nenhum.
Se você se encontra online em um war room às duas da manhã mais de uma vêz por trimestre, algo seriamente está errado. Procure consertar ou troque de empresa.
As qualidades de um bom gerente compartilham muitas qualidades de um bom desenvolvedor.
Aprendi a ser honesto com meu gerente. Não muito honesto, mas honesto o suficiente para que eu possa ser autêntico no trabalho. O que de pior pode acontecer? Se ele te demitir, terá mais trabalho com entregas e capacitação do que poupar um erro meu.
Quando você vai contratar alguém para montar bicicletas (Eu, aos 14 anos 🙂) em um bike shop, você não quer saber unicamente se essa pessoa sabe pegar em uma chave de fenda e montar uma bicicleta. Porque em desenvolvimento teria que ser apenas sobre escrever códigos?
Não importa o quão famosa ou superior uma linguagem seja, isso não importa se ninguém a usa. (Menos rust, aprenda o básico de rust.)
Se uma empresa for metade remota e metade presencial, é importante determinar se as pessoas remotas não são tratadas como cidadãos de segunda classe. Se as decisões importantes são tomadas em uma sala de reuniões, é melhor tentar mudar a cultura da empresa (difícil) ou mudar para uma empresa diferente que trate seus funcionários remotos como cidadãos de primeira classe.
Burnouts não acontecem quando você trabalha muito, eles aparecem quando o investimento emocional que você colocou em algo não gerou um retorno na mesma intensidade.
É totalmente OK você estar desconfortável com alguma tecnologia. No momento que você se tornar confortável com ela, outras 100 melhores apareceram e você provavelmente já deveria ter trocado de desafio (Mesmo conceito do tópico 1).
Se em algum momento acontece um "only works on my machine" no seu time, está na hora de atualizar o ambiente de desenvolvimento de TODO o time.
Não tenha medo de discutir, tenha vergonha de não conseguir admitir.
Entrei no mundo tech por ser meu hobby. Agora meu hobby é o mesmo que meu trabalho e agora meu trabalho arruinou meu hobby. Se eu quiser voltar a curtir tecnologia tenho que entender que ela não é mais meu hobby e achar um outro hobby.
🗨️ Se você entra em uma reunião com a solução para o problema à ser discutido já em mente, ou você é um péssimo comunicador ou seu cérebro te enganou em fazer você achar que é a melhor solução.
Eu disse o contrário antes, porém Tech Stack faz diferença. Se você escuta desenvolvedor python ou desenvolvedor C++, você imagina esteriótipos diferentes. Certas habilidades são melhores para certos trabalhos.
O mundo precisa de mais linguagens java. Java é uma péssima linguagem de programação que é quase boa em tudo.
Se o cliente soubesse exatamente do que ele precisa, ele não seria um cliente e sim um vendedor. Desça do seu pedestal de desenvolvedor e se imagine em uma quarta feira 3h50 da tarde tentando usar o sistema que você desenvolve. Entender o problema trará mais soluções do que ouvir vários usuários.
Deixe seus melhores desenvolvedores trabalharem em developer experience. Um artigo que sempre carrego comigo.
Dois sistemas iguais que resolvem os mesmos problemas não são razões para justificar uma arquitetura igual para ambos. Cada caso tem seu caso e NUNCA vai ter um livro de regras para seguir. Nossa vida é na engenharia de software e não somos pilotos de avião para seguir um manual de conduta.
Várias vezes encontro com pessoas querendo entrar no campo e me perguntam de onde tirei motivações. Simples, de nenhum lugar. Acredito em meritocracia até certo ponto, porém todos nós temos que entender que a maturidade de uma pessoa influencia muito na sua vida.
Os melhores programadores que conheci até hoje, se encontraram dentro da área depois que acabaram usando algum código besta para resolver algum problema ou fazer alguma modificação em algum joguinho. (Alguém aí conhece Spigot 1.8.8?) Primeiro se ganha a motivação e depois se executa a ação, raramente é ao contrário.
🗨️ Não existe sênior de CRUD. Se todas as empresas que você já trabalhou são CRUD com maquiagem, está na hora de buscar algo com desafios maiores.
O melhor lugar de aprender problemas reais são em blogs de grandes empresas relatando os motivos da queda de serviço ou de mudança de arquitetura. LuanRoger colocou uma boa lista aqui no tabnews.
Depois de certo nível de carreira, o melhor modo de aprendizado é lendo artigos/RFCs/blogs, há uma grande falta de conteúdo audiovisual avançado e provavelmente não mudará. Acostume-se com isso.

Escrevi a maioria que acho digna de aparecer neste blog. Fique feliz se você achou algum tópico como óbvio, pois isso marca que você está no caminho certo.

Provavelmente você discorda de algum conceito apresentado ou precise de explicação. Os comentários estão aqui e adoraria dissertar sobre este tema.

Obrigado :)

Se puder me seguir no github, adoraria muito :) Também publico alguns artigos interessantes no meu site, caso tenha interesse.