Conselhos para novos desenvolvedores de software que já leram todos os outros ensaios de conselhos
(buttondown.email)- No início da carreira, em vez de seguir ao pé da letra até mesmo conselhos famosos de desenvolvedores, é preciso primeiro avaliar se eles se encaixam na sua situação; no campo do software, muitas afirmações não têm evidências conclusivas
- Ideias que parecerem boas podem ser testadas na prática, e passar por tentativa e erro sem atrapalhar os colegas faz parte do processo de aprendizado
Debugging: The 9 Rulesé recomendado como um livro introdutório acessível sobre a importante habilidade de depuração, que livros para iniciantes costumam deixar de lado- O “jeito certo” ou as “boas práticas” muitas vezes surgem de casos específicos de fracasso e de trajetórias históricas, então é preciso distinguir a técnica em si da forma como ela é divulgada
- Explorar cedo recursos ocultos das ferramentas, o trabalho de outras áreas e vários tipos de programação ajuda a encontrar o tipo de trabalho em software que combina com você
Postura ao aceitar conselhos
- Conselhos de desenvolvimento amplamente lidos às vezes se espalham não porque o autor seja um programador excepcional, mas porque escreve bem
- Não é preciso rejeitar automaticamente todo conselho, mas vale analisar com cuidado como ele se aplica à sua realidade
- Afirmações sobre “verdades objetivas” em software devem ser recebidas com cautela; há pouca coisa estudada cientificamente, e os resultados das pesquisas em geral não são tão conclusivos
- Não é necessário se preocupar demais com o risco de aprender “do jeito errado”
- Se a ideia de alguém parecer boa, você pode testá-la por conta própria
- Desde que não atrapalhe ativamente os colegas, mesmo olhar para trás depois e achar que deveria ter feito diferente pode acabar virando aprendizado
- Debugging: The 9 Rules é um livro recomendado para desenvolvedores iniciantes
- É fácil de ler e trata de depuração, uma habilidade importante que quase todos os outros livros para “programadores iniciantes” deixam de fora
- Também dá para pegar na biblioteca ou pedir para a empresa comprar
Limites do “jeito certo” e das boas práticas
- Em algum momento, você pode achar que encontrou o “Right Way” da programação e se convencer de que, se todo mundo seguisse esse caminho, a área melhoraria
- São citados como exemplos desenvolvimento orientado a testes, programação funcional, Lisp e métodos formais
- É difícil evitar se empolgar com esse tipo de abordagem, e isso pode até ser uma experiência prazerosa, mas é importante não transformar sua identidade na de um “cara do Right Way”
- Com o tempo, você aprende que qualquer abordagem pode tornar a programação frustrante e bagunçada, e que ainda é possível criar software excelente sem usar aquela abordagem
- Quando você conhece vários “Right Ways”, pode misturá-los conforme o problema
- O primeiro “Right Way” que você conhece geralmente vem de alguém completamente obcecado por ele
- Depois, é melhor não culpar essa pessoa demais e evitar confundir a técnica em si com a maneira como ela a promove
- Muitas ideias precisam ser ajustadas em algum grau para funcionar junto com outras, em vez de serem usadas em sua forma pura
- Como diz Julia Evans, “por trás de toda boa prática existe uma história de terror”
- Se houver uma boa prática que você não entende, pode procurar o caso de fracasso que a originou
- Se esse caso não tiver relação com a sua situação, tudo bem escolher outro caminho
- Muitas boas práticas e convenções são dependentes de trajetória
- Você pode segui-las porque seu mentor fazia assim, e ele também porque o mentor dele fazia do mesmo jeito
- Métodos criados para resolver problemas do passado podem ser menos relevantes hoje
- Convenções que parecem uma explicação plausível inventada depois podem realmente ser isso mesmo, e com pesquisa dá para reconstruir como elas surgiram
Como ampliar a percepção prática
- Caminhar é sugerido como um hábito que ajuda a organizar as ideias
- As ferramentas que você usa quase sempre têm profundidades escondidas
- Não é necessário dominar no nível de especialista toda linguagem de programação, Git ou ferramentas como JIRA
- Ainda assim, vale investir 5 a 10 minutos para descobrir o que mais elas podem fazer
- Conversar com pessoas de outras áreas dentro da empresa amplia sua compreensão do trabalho
- Você pode falar com times de suporte, domínio de negócio, vendas etc.
- Se tiver tempo e for fácil pedir, também é sugerido acompanhar o trabalho delas de perto
- No começo da carreira, é melhor experimentar vários tipos de programação sempre que possível
- Isso não significa necessariamente trocar de emprego; a maioria das empresas faz vários tipos de programação ao mesmo tempo
- Em uma empresa de desenvolvimento web, por exemplo, você pode tentar frontend, backend, operações e trabalho com banco de dados
- Isso ajuda no aprendizado, mas, mais importante, aumenta a chance de descobrir de que tipo de trabalho com software você realmente gosta
- Há um relato pessoal de que o primeiro emprego foi em frontend e foi difícil, mas depois, ao migrar para backend, a pessoa ficou mais feliz
- Como a área de software continua mudando, há motivo para o conselho de não se deixar levar por modas de frameworks e focar em competências fundamentais
- Por causa da internet, do open source, de conferências etc., as informações da área de software se espalham muito rápido
- Como a barreira para compartilhar ideias é baixa, até um projeto pessoal usado por uma única pessoa pode parecer algo que muita gente conhece
- Uma parte considerável das tecnologias sobre as quais você ouve pode ter uma base de usuários pequena e nunca ser amplamente adotada
- Se seu interesse for grande, tudo bem ser um early adopter; caso contrário, também não há problema em esperar alguns anos para ver se aquilo realmente se sustenta
- Ninguém consegue prever o futuro, e o presente também é resultado de caminhos que eram difíceis de prever
- O necessário é fazer o melhor possível, viver de acordo com seus valores e manter uma atitude de aproveitar o processo
1 comentários
Opiniões no Hacker News
Em um projeto recente por hobby, trabalhei com um desenvolvedor júnior e outro menos júnior, e os dois eram obcecados pelo “jeito certo”.
Para um bot de Discord + código Rust de cerca de 300 linhas, que só nós iríamos rodar, eles queriam documentação completa, VMs separadas para QA e “produção”, deploy com systemd, um sistema de templates para algumas strings e até uma camada de ORM para quatro consultas SQL.
Era um projeto que, no máximo, umas 10 pessoas usariam, e isso era só metade dos requisitos da versão “0.3”; como eles já estavam planejando uma arquitetura ainda mais exagerada, acabei me afastando do projeto.
No começo da minha vida como programador eu também fui assim por alguns anos, mas aprendi que há muito mais profundidade em ciência da computação além de boas práticas ou estilo de código, e que, no fim, o que importa é código que funciona.
Ou seja, dedicar uma quantidade desproporcional de atenção a detalhes insignificantes em vez do problema central; há a metáfora de um comitê de aprovação de uma usina nuclear que deixa a usina de lado e discute só a cor do bicicletário ao lado.
Neste caso também, focar em separar VMs de QA/produção, deploy com systemd, templates para algumas strings e ORM para algumas consultas SQL em um projeto para 10 usuários parece um exemplo clássico da lei da trivialidade.
Essas partes são especialmente fáceis para desenvolvedores júnior entenderem e discutirem, então eles tendem a se intrometer mais nelas, enquanto as funcionalidades centrais, mais difíceis, acabam sendo negligenciadas.
Dito isso, documentar bem as partes significativas do projeto não me parece obsessão por trivialidades.
Coisas como escrever uma unit do systemd ou usar um ORM não levam tanto tempo quanto se imagina, mas ajudam bastante depois, quando alguém for olhar o projeto ou outra pessoa quiser contribuir.
É mais fácil fazer isso enquanto o contexto ainda está fresco na cabeça; depois que o projeto cresce, essas tarefas chatas quase nunca são resolvidas.
Por ser um projeto por hobby, talvez eles quisessem justamente fazer tudo direito para aprender as ferramentas e ter satisfação.
No começo há uma cena em que eles precisam comprar um roteador de US$ 50; quando um personagem sugere tentar consertar o roteador antigo, os outros respondem “já tentamos” quase antes de ele terminar a frase.
Isso mostra que eles se conhecem tão bem e passam tanto tempo juntos que quase parecem ler os pensamentos uns dos outros.
Mas, quando alguém diz “yes” para comprar o novo roteador, outro responde que é preciso dizer “aye”.
Ou seja, a regra sobre a palavra a ser usada nas votações de decisão do negócio paralelo é muito rígida; não importa se eles são próximos o bastante para completar as frases uns dos outros, se é um roteador de US$ 50 ou se a renda do bico é insignificante.
A regra exige aye.
Algumas pessoas obcecadas pelo “jeito certo” parecem ter tido sucesso copiando o conhecimento armazenado na inteligência coletiva social, mas sem entender muito bem o que de fato acontece dentro da própria cabeça.
Há a vantagem de herdar metodologias comprovadas sem ter de descobri-las com dificuldade por conta própria, mas há a desvantagem de literalmente não entender em quais situações esse método levará ao fracasso.
No comentário do diretor, ele diz que colocou essa cena de propósito para mostrar que alguns personagens levam as regras a sério demais, enquanto outros não as levam a sério o suficiente.
O motivo para recomendar aos outros essas práticas de culto à carga parece parecido: quanto mais gente as seguir, maior a chance de que, quando a prática fracassar de forma desastrosa, a pessoa que fracassa não seja você.
Tenho visto esse caso com frequência demais hoje em dia, e chamo essas pessoas de júniores inteligentes. Não importa se têm 1 ano ou 20 anos de experiência.
O júnior inteligente conhece a maioria dos design patterns e leu The Mythical Man-Month, mas quer experimentar uma nova tecnologia, linguagem ou framework e sai correndo com um martelo novo e brilhante procurando algo que pareça prego.
Aí acaba tomando decisões estranhas por não entender a força que um banco de dados antigo e bem otimizado pode oferecer.
Com 20 anos de experiência, já vi muitas vezes como esses projetos acabam 5 a 10 anos depois, quando mais da metade da equipe original já saiu; mantenho as partes que têm valor real e corto a metade inútil.
Não estamos administrando uma creche de desenvolvedores que querem se divertir a qualquer custo; trabalhamos para empresas que pagam e esperam resultados estáveis e relativamente rápidos.
Tentar coisas novas por causa de tecnologia de ponta ou para evitar o tédio, no longo prazo, quebrou mais coisas do que consertou.
Devemos adotar tecnologias que a equipe inteira consiga entender e dominar, não trazer uma tecnologia que só um superstar entediado conhece.
Se você quer encher o currículo de itens técnicos, faça isso em uma empresa desse tipo; esses lugares também têm seu valor.
Mas essas pessoas muitas vezes nem ficam muito tempo mesmo, então o valor adicional total também é questionável. Pode parecer entediante para alguns, mas eu chamo isso de jeito experiente.
Se o objetivo de um projeto paralelo é fazer empresas olharem para o seu GitHub, isso também parece mais plausível.
Documentação é muito importante. Tenho projetos bem simples com menos de 300 linhas, incluindo bots e web scrapers, mas hoje não consigo executá-los porque não documentei nada.
O Raspberry Pi em que eles rodavam morreu, e não faço ideia de como consertar o framebuffer virtual headless nem de como depurar um erro desconhecido que não retorna resultados úteis nas buscas.
Se eu tivesse conteinerizado, ou pelo menos documentado o processo de configuração, não teria esse problema.
É um bom texto, e queria que mais gente o lesse
Trabalhando 15 anos com software, especialmente na área de gerenciamento de dados, aprendi exatamente isso
O Kesamutti Sutta, que conheci a partir de um contexto do budismo Theravada, também ajudou muito
Ele diz para não seguir algo só porque foi ouvido repetidas vezes, porque é tradição, boato, está nas escrituras, é uma conjectura, um axioma ou uma lógica plausível, por viés em relação a uma ideia pensada por muito tempo, porque alguém parece competente, ou porque foi dito por um mestre
O conselho de aceitar algo quando você mesmo sabe que “isto é bom, não é repreensível, é elogiado pelos sábios e, quando praticado, leva a benefício e felicidade” foi muito útil na minha vida, mesmo depois de eu ter me tornado ateu no ensino fundamental
Há quem diga que alguém distorceu a tradução para fazê-la parecer ter um sentido mais racionalista
Se for verdade, é uma pena. Eu queria acreditar que Buddha era uma pessoa tão “iluminada” assim
https://fakebuddhaquotes.com/do-not-believe-in-anything-simply-because-you-have-heard-it/
Concordo com a parte de não se preocupar demais por ter sido “enganado” ou por ter “aprendido algo errado”
Aprendi TDD quando estava na moda? Sim. Uso TDD hoje? Não. Mesmo assim, TDD me ensinou a escrever código melhor? Sim
O mesmo vale para linguagens que deixei de usar profissionalmente. Tudo ensina alguma coisa
Não dá para encontrar um bom meio-termo sem passar um pouco do ponto para os dois lados
Se já existe código e você quer estendê-lo, faz sentido escrever alguns testes em torno de como ele é usado
Se ainda não existe código, mas você tem uma estrutura na cabeça e consegue separar as partes que pode criar e testar primeiro, também faz sentido
Não é TDD no sentido puro; está mais para desenvolvimento auxiliado por testes, mas é uma forma de aproveitar o espírito do TDD
Aprender coisas ruins também é uma parte importante de entender quais abordagens são melhores ou piores
Não quer dizer que TDD em si seja ruim, mas ele pode ficar ruim quando há apego excessivo
No fim, isso também se conecta à ideia comum de que “erros são o caminho do aprendizado”
Diretrizes e princípios assim geralmente são bons de conhecer, mas o problema começa quando as pessoas os tratam como religião
Na nossa indústria, os ideólogos são realmente um transtorno
É curta, adequada e bate na hora
É um bom texto e um bom conselho
No fim, quando a lua de mel acaba, você aprende que, seja qual for a “forma correta” usada, programar é frustrante e bagunçado, e que dá para criar software excelente mesmo sem seguir esse método
Com o tempo, você aprende dezenas de outras “formas corretas” e passa a misturá-las conforme o problema
Mas, nos últimos anos, parece que muitos desenvolvedores ficaram presos à obsessão pela forma correta e não conseguem ampliar seu conhecimento e sua perspectiva
Se isso for verdade, é triste, e não sei bem qual é a causa
Talvez a capacidade de atenção mais curta de hoje dificulte expandir conhecimento de forma eficiente, ou talvez a posição atual tenha ficado confortável demais
Ou talvez as recompensas por aprender apenas um framework específico sejam grandes demais, e faltem incentivos para aprender o conhecimento básico de como as coisas funcionam por dentro
Por isso, não há tempo para aprender lições no trabalho atual, e, quando essas lições finalmente chegam, é bem provável que a pessoa já tenha ido embora
Ao mesmo tempo, também não há folga para deixar de focar na nova tecnologia da moda
Esse fluxo atrapalha muito o crescimento
Meu conselho de 1 centavo é este: estado é o inimigo. Você deve reduzir estado em todos os lugares possíveis
Isso inclui não só o estado dentro do código, mas também a quantidade de coisas que você precisa manter na memória de curto prazo para trabalhar, e até detalhes específicos do projeto que precisa lembrar
Estado é o inimigo. Se algo puder ser derivado a partir de primeiros princípios, você deve sempre tentar fazer isso
Parte disso vai além de conselhos só para programadores
O primeiro item é algo que todos deveriam ponderar. Muitos autores e ensaístas são lidos não por serem especialistas no assunto, mas porque escrevem bem
Também é preciso caminhar
É bom experimentar vários tipos de trabalho e aprender outras funções dentro da empresa
Especialmente em empresas grandes, aquilo que eu faço pode ser algo que precisa ser corrigido de novo ou contornado em algum lugar, e uma mudança minha pode facilitar a vida de todos
O primeiro item também é um motivo para desconfiar do que se aprende em serviços de compartilhamento de vídeo como o YouTube
Quando alguém fala com confiança e apresenta ideias de forma profissional, as pessoas levam essas ideias a sério mesmo quando elas têm falhas
Num mundo em que alguns “ensaístas” acabaram se revelando basicamente pessoas lendo artigos da Wikipedia e posts do Reddit, é preciso tentar separar a aparência convincente da apresentação da precisão
Também gostaria de expandir o item 10. Conversar com as pessoas envolvidas deixa mais claro qual problema o software ou o trabalho de desenvolvimento está tentando resolver, e também ajuda a encontrar pontos de dor que você não tinha percebido
Com pouquíssimas exceções, software não é escrito por si só, mas para resolver problemas
Eles podem ter lido, em algum lugar da internet ou do treinamento, uma resposta “certa” e repeti-la de forma plausível sem considerar se ela é realmente verdadeira
Gosto tanto do livro de depuração recomendado no texto que comprei vários exemplares para distribuir
Dei para amigos, estagiários, cientistas de dados e até executivos, e todos que leram agradeceram
Ele traz algumas técnicas simples e boas para resolver problemas em grandes sistemas técnicos, úteis para praticamente qualquer pessoa
É fácil de ler e interessante, e também tem muitas “histórias de guerra” que dão cor e contexto a conselhos que poderiam acabar secos
https://debuggingrules.com/
A frase “as pessoas me ouvem não porque sou um bom programador, mas porque sou um bom escritor” não significa apenas que devemos ficar atentos ao ler textos de bons escritores; ela também se aplica à forma como abordamos nosso trabalho.
Quem escreve bem geralmente também melhora na capacidade de lidar com outras pessoas.
Para desenvolvedores de software, escrita e comunicação são parte central do trabalho.
Se você é iniciante, recomendo escrever sobre as dificuldades que enfrentou, os experimentos que fez e seu processo de pensamento.
Se possível, também escreva ensaios. Isso se torna uma habilidade realmente útil mais adiante na carreira.
Há uma frase difícil de explicar direito a iniciantes: “seu trabalho não é escrever código”.
Usamos código como ferramenta para resolver problemas.
Código é um meio para atingir um objetivo, não o objetivo em si.
Se você programa pelo código em si, acaba produzindo resultados ruins.
É preciso focar em resolver problemas e, se você não tem certeza de que problema seu código resolve, deve parar de programar e descobrir isso primeiro.
Dependendo da empresa, pode ser e-mail.
Responder perguntas, colaborar e influenciar a direção da equipe e da organização pode parecer o trabalho em si, mas a comunicação, assim como o código, é uma ferramenta para criar algo útil; ela não é útil por si só.
A maior parte do código, até mesmo código escrito como “código pelo código”, resolve algum problema.
Muitos programadores sabem disso, ao menos inconscientemente, e por isso escrevem esse tipo de código.
O verdadeiro problema é que outras pessoas, por exemplo o pessoal de negócios de terno, querem que aquele código resolva outro problema.
Mas esse código precisa ser o código certo.
De forma mais geral, eu explicaria como “aplicar sistemas de software para resolver problemas de negócio”.
Dizer isso a um júnior o faz focar nas necessidades do negócio e permite avaliar criticamente o que MBAs, gestores ou PMs dizem, para então fazer a coisa certa.
Mas o simples fato de haver software para vender a VCs tem valor.
Por isso, às vezes você realmente é pago para escrever código.