1. Reserve um tempo para ler dois livros sobre engenharia de software todos os anos
Cada vez que passo um tempo lendo lenta e cuidadosamente livros de engenharia de software recomendados por outras pessoas, fico aprimorado. Ao ler com atenção, quero dizer fazer anotações, conversar com outras pessoas, escrever e desenhar, tentativas práticas e voltar e ler novamente.
Espero ter lido livros relacionados a software nos primeiros anos de me tornar um desenvolvedor. Mas só comecei a fazer isso por volta do 5º ano de carreira. Livros como "C # em profundidade", "Código limpo" e "Javascript: as partes boas" me ajudaram a melhorar minhas habilidades. Não estou recomendando títulos de livros específicos - alguns deles estão desatualizados de qualquer maneira. Minha sugestão é procurar livros mais aprofundados do que seu conhecimento atual, que podem ser livros sobre tecnologias específicas ou práticas de engenharia de software.
Não sei ler esses livros. Na verdade, eu assisti bem devagar. Normalmente sento e leio apenas um ou dois capítulos de cada vez. Ao ler, farei anotações ou destacarei os pontos-chave; depois de ler, revisarei e freqüentemente discutirei com outras pessoas. Também comecei a escrever algumas resenhas de livros no meu blog pessoal.
Principalmente para refletir sobre o que aprendi. Nos últimos anos, desenvolvi esses hábitos. Esses hábitos me ajudaram a crescer rapidamente como gerente técnico: eles também são muito benéficos para os engenheiros. Procurando uma lista de livros recomendados? Aqui está uma lista de livros que li e estou lendo no momento.
Por que os livros são melhores do que postagens de blogs, vídeos ou discursos? Na verdade, acho que os livros são melhores do que os outros juntos. Não importa qual seja o conteúdo do assunto, em comparação com os livros, outros formatos serão superficiais. O conhecimento nos livros é mais profundo e bem organizado. Eu só preciso gastar algumas horas para escrever um post como este, mas gastei quase um ano neste livro sobre o crescimento dos engenheiros de software. Acho que a leitura pode digerir o conhecimento de forma mais lenta, mas profunda.
Não seja ganancioso: ler um livro a cada seis meses é ótimo. Escolha um bom livro e passe mais tempo lendo-o. Depois de ler um ou dois livros, também recomendo que você leia "Como ler um livro: um guia clássico para uma leitura inteligente", que é altamente recomendado.
2. Domine a principal linguagem de programação em seu trabalho e aprenda a camada inferior
Quando comecei, usei principalmente PHP e também escrevi algum JavaScript elementar. Aprendi C e C ++ na universidade e não gostei deles. Meu primeiro emprego em tempo integral foi C #. Eu conheço muitos idiomas, mas nenhum deles é muito bom.
Dois anos depois, comecei a ter alguns problemas e tive que pedir ajuda a desenvolvedores seniores para depurar código C #. Um deles é um engenheiro sênior que sempre me ajuda a depurar programas. Ele parece conhecer muito bem essa linguagem. Ele me recomendou um livro "Aprendizado profundo em C #" para eu ler. Então eu assisti. Eu aprendi threading, coleta de lixo e métodos de trabalho genéricos por todo o caminho.Estes são o conhecimento de baixo nível. Passei horas incontáveis para entender covariância (covariância), variância inversa (contravariância) e outros tópicos difíceis.
Uma das melhores decisões que tomei foi estudar a língua principal do meu trabalho. No meu primeiro emprego, esse tipo de pesquisa foi feito sem querer, e tive que contar com a orientação do engenheiro sênior, porém esse conhecimento se tornou uma vantagem no trabalho e nas entrevistas para outros empregos. Na última parte da minha carreira, mergulhei deliberadamente em novas linguagens e estruturas. Entrei no Skype como programador C #, mas precisamos mudar para JavaScript e WinJS. Portanto, aprendi JS em profundidade e dominei o WinJS para poder iniciar um curso sobre Pluralsight.
Quanto mais idiomas você conhece, mais entende seus pontos fortes e fracos. Quando mudei para o iOS, já era proficiente em vários idiomas. Quando o Swift apareceu, eu simplesmente acompanhei e participei das discussões sobre o idioma e sugeri adicionar a capacidade de leitura e escrita de reflexão ao planejamento futuro do Swift. Depois de entender as características da linguagem, será mais fácil descobrir a melhor estratégia para minha equipe migrar de Objective-C para Swift. E, quanto mais idiomas você souber, mais fácil será dominar um novo idioma - e aprender mais facilmente quando você precisar.
3. Emparelhe a programação com outros
Acho que a programação em par se tornou obsoleta recentemente. Quando começamos, o Extreme Programming emparelhado, o Test Driven Development e a programação mob eram todos populares. Depois de fazer par com alguém, tive alguns dos maiores saltos da minha carreira. Esses saltos são mais importantes do que ler.
Certa vez, tive uma experiência inesquecível de programação em par com um desenvolvedor. Ele conduziu uma revisão rigorosa do código em todos, incluindo eu. Um dia, eu estava farto dos comentários sobre a ferramenta de revisão de código e decidi não responder, mas sentar ao lado desses comentaristas e pedir que explicassem seus comentários para mim. Acabei aprendendo muito - e também disse a eles que achava seus comentários injustos. Eles perceberam isso e sugeriram que eu emparelhe a programação sempre que isso acontecer. Então eu fiz. Este desenvolvedor sabe algo sobre desempenho.Eu aprendi sobre os prós e contras de gargalos de desempenho potenciais emparelhando a programação com ele - e então lhes ensinei sobre sustentabilidade em troca.
A experiência de desenvolvimento orientado a testes com outro engenheiro é outra boa lembrança da minha programação em pares. Nós nos revezamos escrevendo código e testando o código. Fizemos isso por dois dias e percebemos uma parte complicada do sistema. Essa experiência realmente abriu meus olhos. No processo de verificação de todos os valores de limite, até mudamos completamente o método de implementação ao contrário. Também estabelecemos um forte vínculo com o desenvolvedor que durou vários meses.
4. Escreva casos de teste de unidade e execute-os em integração contínua
Engenheiros seniores costumam falar sobre a importância dos testes de unidade. Mas o teste de unidade parece muito contra-intuitivo: por que gastar mais tempo escrevendo testes que parecem simples? Esta é minha opinião sobre o teste de unidade em um determinado momento.
Para apreciar o valor do teste de unidade, você precisa ter o momento "Aha!" - quando você escreve um teste de unidade que economiza um dia, esse é o momento "Aha!". Antes de chegar a esta etapa, você precisa ter os pés no chão, escrever bem esses testes e fazê-los funcionar em integração contínua. Além disso, você pode precisar fazer isso por vários meses antes de ter um momento "Aha!".
Eu tenho dois desses momentos. O primeiro aconteceu quando eu estava construindo um mecanismo de back-end (como um projeto auxiliar) para um pequeno cassino online. A API está gerenciando dinheiro de verdade e cobri todo o código com testes de unidade porque tinha medo de cometer erros. O projeto foi entregue mais tarde do que eu esperava, em parte devido aos testes, que demoraram muito. Mas isso está correto. Entreguei o projeto ao cliente no final do contrato, dois anos depois, eles me disseram que esses testes salvaram a equipe muitas vezes - se não fosse pelas falhas nos testes, as vulnerabilidades do código se espalhariam pelo ambiente de produção.
Meu outro momento "aha" é construir o Skype na web. Criamos um novo concorrente para o Google Hangouts em web.skype.com. Nossa equipe é forte, com cobertura de unidade completa e testes de integração rígidos. Três meses depois de entrar no projeto, o engenheiro decidiu reconstruir a estrutura de todo o projeto. Esta é uma refatoração muito arriscada e todos nós votamos contra ela.
O engenheiro ressaltou que, com base na cobertura de teste existente, essa refatoração deve ser moleza, pois, desde que o teste seja aprovado, a refatoração estará bem. Eu duvido. Mas esse é exatamente o propósito dos casos de teste. Depois de uma semana de reconstrução, ele promoveu uma grande mudança ... nem tudo foi interrompido, nem na hora, nem desde então. Todos os testes foram aprovados. Naquele momento, percebi as garantias de segurança fornecidas por um poderoso conjunto de casos de teste e o fato de que ele pode nos fazer não ter medo de refatorar.
5. Desenvolva hábitos de refatoração e ferramentas mestre de refatoração
Por muitos anos, quando trabalhei com a equipe, tendia a fazer as menores mudanças possíveis na base de código. Para meus próprios projetos pessoais, fiz muitas refatorações - mas nunca faço esse tipo de coisa em uma base de código que não controle totalmente.
Então, conheci um engenheiro no Skype que continuaria a fazer pequenas ou grandes refatorações. Todos eles fazem sentido e o código sempre fica melhor. E eles nunca bagunçam as coisas. Como eles fizeram isso?
Quando eu emparelhei a programação com eles, descobri que eles conheciam seu IDE muito bem e adicionei plug-ins para refatoração. Método de extração, alteração do nome da quantidade, extração para constante ... só precisam de um segundo.
Percebi que tinha medo de refatorar e sentia falta da prática e das ferramentas que poderiam me ajudar a refatorar. Então, quando comecei a desenvolver o hábito de refatorar uma vez por semana, melhorei em ambos os aspectos. Esse hábito me ajudou muito mais tarde - como eu gostaria de ter começado a fazer isso muitos anos atrás.
6. Aprender uma boa experiência em engenharia de software, o que me beneficiou muito
Quando comecei como engenheiro de software, fui enganado por engenheiros seniores. Eles viram erros que eu não vi, eles sabiam as respostas que eu não sabia. Achei que eles eram mais espertos do que eu e aceitei tudo isso.
Agora, trabalhei em estreita colaboração com muitos engenheiros de software conhecidos e servi como mentor para vários outros, e não achei que estava blefando. Os melhores engenheiros de software combinarão o conhecimento que aprenderam com a experiência prática - conhecimento, você pode aprender; experiência, você precisa praticar.
Procure oportunidades de trabalhar em diferentes pilhas de tecnologia, diferentes campos e projetos desafiadores. Levei sete ou oito anos para atingir o que considero o nível "avançado". Eu vi algumas pessoas ingressarem em uma empresa de alto crescimento como a Uber, e isso levou três ou quatro anos. Qual é a diferença entre isso? Essas pessoas trabalham em projetos desafiadores, tentam acompanhar as outras pessoas ao seu redor e, muitas vezes, mudam de equipe na metade e reiniciam. Eles participam voluntariamente de novos projetos e são os primeiros a experimentar novas tecnologias na equipe. Embora eu tenha acabado por me tornar tal pessoa, foi mais tarde, não nos primeiros anos.
7. Ensine o que você aprendeu aos outros
A melhor maneira de aprender certas coisas é ensiná-las a outras pessoas. Eu encontrei isso por acidente. Em 2010, comecei a fazer apresentações nos grupos de usuários .NET e Windows Phone. Minha fala não surtiu efeito, mas aprendi muito na fase de preparação.
Agora, quando quero aprender algo bom, me inscrevo para uma discussão pública. Um ano depois de entrar no Uber, me ofereci para fazer um discurso sobre como o Uber implementou mudanças de back-end em grande escala em 2017. Na época, eu não entendia totalmente como fazíamos isso - antes disso, eu estava principalmente envolvido no desenvolvimento de dispositivos móveis e no gerenciamento de uma equipe móvel. Por meio da palestra, não tenho escolha a não ser aprender todos os detalhes. Estou sob pressão para fazer isso: cerca de 100 desenvolvedores locais se inscreveram para ouvir minha palestra.
Muitos outros também disseram que essa abordagem é eficaz - Shawn "Swyx" Wang é um excelente representante da abordagem #LearnInPublic. Sua história de crescimento é muito mais impressionante do que minha experiência: depois de mudar de carreira, ele assumiu o cargo de engenheiro sênior na Netlify e na AWS em quatro anos e escreveu um livro sobre sua experiência de aprendizado. Você só se beneficiará ensinando outras pessoas. Você não só pode aprender ensinando, mas também pode ajudar e inspirar outras pessoas.
E todos os desenvolvedores de modelos experientes que conheço são professores e mentores qualificados. Quanto mais cedo você começar a retribuir e ensinar, mais naturalmente você se tornará um desenvolvedor.