O décimo ano chegará em breve, pois estou profissionalmente envolvido em programação. Dez anos de idade! Além do trabalho formal, quase dois terços da minha vida criei algo na Internet. Eu mal me lembro dos anos em que eu não conhecia HTML: é até estranho se você pensar sobre isso. Algumas crianças estudam música ou balé e, em vez disso, criei mundos mágicos, codificando no meu berçário.

Pensando nesta primeira década de receber regularmente dinheiro para inserir caracteres estranhos no terminal, gostaria de compartilhar algumas observações sobre como meu pensamento mudou ao longo dos anos de trabalho .

Talvez os juniores atuais encontrem aqui algumas de suas crenças e olhem para eles do outro lado. Ou eles percebem que já se livraram disso, então foram muito mais longe do que eu estava no seu estágio.

Os idosos atuais também podem compartilhar histórias engraçadas (e um pouco humilhantes) sobre quais lições foram aprendidas com sua experiência júnior.

Para maior clareza, enfatizo que os juniores são incríveis : apenas aparecer no trabalho para aprender coisas novas - isso já exige muita coragem. Este artigo é sobre minha própria experiência e treinamento. Não generalizo de forma alguma que todos os desenvolvedores juniores pensam ou se comportam dessa maneira.

Espero que você goste do post e lembre-o de algo do passado ou do presente.

Agradecimentos a Artyom e Sarah pelo feedback!

Verdades absolutas do júnior, das quais foi necessário desaprender

1. Sou desenvolvedor sênior

Quando tentei arrumar um emprego, eu tinha 19 anos. O trabalho foi chamado de "webmaster do aluno". Esse é um nome bastante surpreendente para o trabalho, porque você é considerado um "aluno" e um "mestre" ao mesmo tempo. Atualmente, todo mundo quer ser "engenheiro", porque parece mais elegante, mas para mim, "mestre" é uma palavra melhor para este ofício. De qualquer forma, meu trabalho era escrever PHP e MySQL e manter nosso site no Drupal, além de criar algumas ferramentas internas.

Desde antes que eu estava codificando por vários anos no meu quarto, eu tinha certeza de que esses anos contavam como “anos de experiência”. Portanto, quando perguntado sobre quanta experiência eu escrevi em PHP, respondi com confiança: "3 ou 4 anos!"

Eu pensei que sabia muito sobre SQL porque posso fazer junções externas (junções externas).

E quando pesquisei no Google, descobri que três a quatro anos de experiência significam muito dinheiro.

Vamos para o meu último trabalho, que obtive após cinco anos de experiência “combinada” de estudantes e profissionais (que eu considerava uma experiência normal). Naquela época, meu código quase nunca passava por uma revisão de código. Eu executei o ssh no servidor e git pull. Tenho certeza de que nunca vi uma única solicitação pull. Não me entenda mal, nos dois primeiros trabalhos aprendi muitas coisas incríveis, nunca trabalhei com outros desenvolvedores na mesma base de código. No entanto, solicitei o cargo de “engenheiro sênior de front-end”, recebi uma oferta e a aceitei.

Então, eu me tornei um desenvolvedor sênior na idade madura de 24 anos.

Afinal, eles não me dariam essa posição se eu realmente não fosse um desenvolvedor sênior, certo ?! É claro que minha experiência impressionante me levou a esse pico, então as pessoas deveriam me ouvir !!! Estou no auge da minha carreira técnica, enquanto o mais jovem no escritório.

Assim como um chefe.

O que eu finalmente entendi

Nem toda experiência é a mesma . Minha experiência em codificação no quarto, o trabalho de um programador de estudantes é diferente da pesquisa científica em ciência da computação e do trabalho em uma startup em crescimento. Esta é uma experiência diferente. Por um ano de trabalho em suporte técnico no início de sua carreira, você pode aprender dez vezes mais de cinco anos em projetos individuais (ou com feedback mínimo). Se o seu código nunca é visualizado pelos colegas, o treinamento é muito mais lento.

É por isso que os mentores são tão importantes , e sua equipe é muito mais importante do que a diferença de alguns dólares em salário. Não aceite uma posição júnior, onde você trabalhará sozinho! E não escolha seu primeiro emprego (ou, francamente, qualquer emprego) apenas com base no salário. Equipe é onde está o valor real.

Também aprendi que os cargos não significam nada por si próprios. A posição de CTO pode estar em uma equipe de 5 pessoas, 50 ou 500 pessoas. Este é um trabalho completamente diferente, embora o nome seja idêntico. Portanto, meu título de "sênior" não me transformou em um programador líder. Além disso, os títulos hierárquicos são inerentemente falhos e difíceis de comparar. Percebi que é importante não ficar preso nos nomes e você não deve usá-los como algum tipo de verificação externa.

2. Todo mundo escreve testes

Na primeira metade da minha carreira, trabalhei no campo de pesquisa. Em particular, três anos e meio em um projeto com financiamento estatal e, em seguida, um ano e meio na universidade, no departamento de processamento de linguagem natural. Posso dizer uma coisa: a programação no ambiente científico é completamente diferente da programação na indústria comercial .

Na maioria das vezes, você não está construindo aplicativos. Você trabalha em algoritmos ou analisa conjuntos de dados. Como alternativa, se você estiver criando um aplicativo, provavelmente o trabalho será financiado pelo estado. Isso significa que é gratuito para outras pessoas e geralmente é de código aberto. E quando algo é gratuito, significa que geralmente você não é responsável por garantir que ele esteja sempre disponível.

Porque ... bem, é grátis.

Você também não é responsável por receitas financeiras ou resultados específicos. No entanto, o trabalho de um programador em uma instituição científica é um tópico para um artigo completamente diferente.

Em resumo, deixei o instituto com grandes expectativas.

Expectativas sobre como o setor funciona. Implantações automáticas. Solicitações pull e revisões de código. Vai ser ótimo! Finalmente, a qualidade do código que eu sonhei! Mas, além do código de alta qualidade com os padrões e as melhores práticas apropriadas , eu acreditava firmemente que na indústria de software todos escrevem testes .

Hum ...

Imagine a minha surpresa quando, no primeiro dia útil de inicialização, não encontrei nenhum teste. Não há testes na interface. Não há testes no back-end. Sem testes.

Nda. Nada. Zero NaN. Os testes estão faltando como um fenômeno.

Não apenas não houve testes , mas ninguém parecia ter problemas por causa disso! Com alguma ingenuidade, sugeri que o motivo é porque as pessoas simplesmente não sabiam como escrever testes para o AngularJS. Se eu ensiná-los, tudo vai dar certo - e começaremos a realizar testes. Erro! Em geral, apenas alguns anos depois, implementamos testes automatizados no código, e não foi tão fácil quanto eu pensava.

Mas não porque as pessoas não sabem como escrevê-las.

Eles nunca tiveram problemas com a falta de testes ou com a presença de testes antigos . Duas coisas que eu nunca encontrei.

O que eu finalmente entendi

Muitas empresas e startups praticamente não têm testes . Ao lutar pelo mercado ou pela sobrevivência, muitas empresas negligenciam os testes nos estágios iniciais. Até empresas da moda que patrocinam conferências ou código aberto costumam fazer um grande monólito desajeitado com testes mínimos. Basta perguntar aos desenvolvedores sobre o estado da base de código.

Nenhuma empresa possui uma instalação técnica ideal . Cada empresa tem problemas, cada um tem uma dívida técnica. A questão é o que eles fazem com isso. Ao se candidatar a um emprego, você precisa entender claramente que nem tudo está em ordem, caso contrário eles não teriam aberto uma vaga.

Ser excessivamente autoconfiante em assuntos sobre os quais você não tem experiência real é bastante arrogante . Eu agi como um "tudo sabe", insistindo na implementação generalizada de testes, com quase nenhuma experiência em como realmente implementá-lo em larga escala. Não repita meus erros. É importante ter princípios, mas ainda é importante estar aberto e realmente interessado para perceber a experiência e os pontos de vista de outras pessoas.

3. Estamos muito atrás do resto (também conhecida como versão técnica da síndrome do lucro perdido )

Isso está intimamente relacionado ao tópico do teste de unidade. Minha empresa não realizou testes, mas, é claro, todas as outras empresas fizeram, certo?

Eu li várias postagens no blog. Eu assisti muitos discursos de conferência no YouTube. Droga, eu li “aquele site laranja” o tempo todo [provavelmente se referindo ao Hacker News - aprox. trans.]. Todo mundo parece estar escrevendo aplicativos super sofisticados e de alta qualidade com ótimo desempenho e animações da moda, enquanto eu apenas estou fazendo patches tentando cumprir o prazo.

Eu literalmente idolatrei todas as outras empresas sobre as quais li e fiquei desapontado com o quanto minha empresa e o projeto ficaram para trás.

O que eu finalmente entendi

Muitas apresentações de conferências cobrem provas de conceito, e não cenários da vida real . Apenas uma história em uma conferência sobre uma tecnologia não significa que a empresa use essa tecnologia em seu trabalho diário ou que todo o seu código esteja em perfeitas condições. Os palestrantes da conferência geralmente apresentam aplicativos de brinquedo em vez de aplicativos reais: é importante distinguir entre eles.

Trabalhar com o Legacy é completamente normal . Não, sério, é fácil imaginar que alguma outra empresa não tenha um legado. Mas, depois de passar um tempo em conferências, conversando com pessoas que trabalham nas principais empresas, fica claro que estamos todos no mesmo barco. Tente encontrar uma empresa que NÃO possua um monólito enorme em PHP ou Ruby que esteja tentando domar (ou deveria ter domado em algum momento)? O código legado é comum e trabalhar com ele geralmente ensina mais do que criar aplicativos do zero, porque você trabalha mais com conceitos que ainda não entende.

4. A qualidade do código é muito importante.

Antigamente, eu podia fazer uma revisão de código muito difícil .

Pelo menos eu era muito exigente com estilo. Meu estilo acabou sendo uma versão modificada do estilo de guia de estilo JavaScript do Airbnb, mas ele se encaixa no meu gosto pessoal. Coisas como recuo, formatação, nomeação - Deus não permita, você fará isso de maneira diferente. Era completamente impossível passar por uma revisão de código sem um único comentário meu: você precisaria aprender as habilidades de ler pensamentos e, além disso, ganhar na loteria.

Envie mais de 50 comentários para sua solicitação de recebimento, que lista todos os pontos e vírgulas que você perdeu!

Porque tenho olhos como uma águia - e essa águia deseja obter todos os seus pontos e vírgulas de alta qualidade!

(Felizmente, depois de muitos anos trabalhando no computador, a visão como a de uma águia desapareceu, então agora você não precisa se preocupar com - piadas engraçadas)

O que eu finalmente entendi

Bom o suficiente - é o suficiente . Ao se aproximar do código ideal, aplica-se a lei dos retornos decrescentes. O código não deve ser perfeito, mas limpo o suficiente para funcionar e não um desastre completo para suporte. Frequentemente, código repetitivo demais ou muito detalhado é mais fácil para outras pessoas entenderem. Além disso, "código bom" não é o mesmo que "código que parece que eu mesmo escrevi".

A arquitetura é mais importante do que nitpicking . Embora algumas linhas possam ser melhoradas, os principais problemas são a ordem da arquitetura. É melhor se concentrar imediatamente na estrutura do aplicativo, em vez de em pequenos pedaços individuais de código.

A qualidade do código é importante , não me interpretem mal. Mas a qualidade do código não é o que eu pensava. Esse não é o estilo, formatação ou estilo descrito no último artigo que li.

5. Tudo deve ser documentado !!!

Quando cheguei à minha primeira empresa de verdade, pela primeira vez me deparei com um código estranho pela primeira vez. Obviamente, trabalhei um pouco com o código de outra pessoa no primeiro emprego, mas nunca tive que entrar na base de códigos existente e descobrir o que diabos estava acontecendo aqui. A única vez que isso aconteceu, reescrevi todo o código, em vez de tentar entender como ele funciona.

De qualquer forma, o fato de ser o código AngularJS escrito pelos desenvolvedores do Ruby não ajudou em nada a situação, e eu era um júnior que se imaginava sênior.

Então, como eu lidei com o fato de 300 linhas de código desconhecido me fazer sentir como se estivesse me afogando?

JSDOC. EM TODA PARTE.

Comecei a comentar tudo para tentar fazer sentido. Anotações para todos os recursos que eu pude acessar.

Aprendi toda essa sofisticada sintaxe JSDoc específica do Angular. Meu código sempre teve o dobro do comprimento, porque tinha muita documentação e comentários.

O que eu finalmente entendi

A documentação às vezes mente . É fácil pensar que a documentação resolve todos os problemas. "Precisamos de docas!" Embora a documentação seja um trabalho árduo, ela precisa ser feita. Você só precisa documentar as coisas certas da maneira certa. A documentação excessiva de coisas desnecessárias, via de regra, impede as pessoas que estão tentando resolver um problema real.

Onde apropriado, concentre-se na automação, e não na documentação . Testes ou outras formas de automação têm menos probabilidade de perder relevância. Portanto, tento me concentrar em escrever bons testes com uma linguagem clara, para que outros desenvolvedores possam ver como o projeto funciona com o código em funcionamento. Outro exemplo é automatizar a instalação de um aplicativo com alguns comentários, em vez de um guia de instalação longo e detalhado.

6. Dívida técnica é ruim

Se após o último ponto você me considerou um neurótico, basta ler este! Por algum tempo em minha carreira, considerei qualquer código sujo como um dever técnico . Dívida técnica é um termo engraçado, porque se você pedir um exemplo, eles dizem coisas muito diferentes.

Como eu considerava qualquer código "desordenado" um dever técnico, tentei imediatamente eliminá-lo com a máxima severidade!

Uma vez, passei um fim de semana literalmente corrigindo manualmente 800 erros de fiapos.

Era assim que eu era neurótico.

(Aviso: isto foi antes das correções automáticas aparecerem).

O que eu finalmente entendi

Código desorganizado ou desarrumado não é o mesmo que dever técnico . Apenas uma condição imperfeita não significa que seja um dever técnico. Na verdade, a dívida técnica diminui a velocidade de algum modo ou dificulta ou pode causar certos tipos de alterações. Se o código estiver um pouco bagunçado, será um pouco bagunçado. A limpeza pode não valer o seu tempo.

Ter alguma dívida técnica é normal . Às vezes encurtamos o caminho, porque precisamos fazer o trabalho com urgência e, por isso, “emprestamos” parte do tempo no futuro. Ter trechos de código que são uma "dívida técnica" real é normal se você reconhecer que provavelmente precisará devolvê-lo. Se sua base de códigos, na sua opinião, está livre de dívidas técnicas, provavelmente você superestima a aparência em detrimento da entrega . E meu Deus, como eu o superestimei!

7. Quanto maior a posição de um programador, melhor ele programa

Tendo começado a programar em uma idade bastante jovem, tornei-me um verdadeiro profissional em loops, aprimorando o automatismo em 15 anos. Programar em si é como respirar para mim. Quando a solução é óbvia, posso imprimir o código sem parar, como texto em um blog ou e-mail. Posso codificar a solução mais rapidamente do que outros, e geralmente assumi projetos mais complexos.

Por um longo tempo, pensei que essa era a essência do desenvolvedor líder.

Tudo parece se encaixar? Afinal, a posição é chamada "desenvolvedor líder", e não "comunicador líder" ou "gerente de projeto líder". Eu realmente não entendi quantas mais habilidades precisavam ser desenvolvidas para se tornar um verdadeiro "líder".

O que eu finalmente entendi

Os engenheiros seniores terão que dominar muitas habilidades além da programação . Comparado ao início de uma carreira, tive que desenvolver uma quantidade astronômica de habilidades. Comunicação, gerenciamento de dependências, compartilhamento de contexto, gerenciamento de projetos, avaliando os prazos de entrega do projeto e colaborando com colegas que não são desenvolvedores. Essas habilidades são difíceis de quantificar e requerem muita tentativa e erro antes de serem aprendidas adequadamente.

Nem todo programador se tornará "sênior" . Este é o resultado de muitos anos de experiência acumulada. No entanto, muitos anos de experiência são uma condição necessária, mas não suficiente, para o senhor. Também deve ser a experiência certa em que você aprendeu as lições certas e é capaz de aplicar esse conhecimento com sucesso no futuro. Às vezes, lições importantes serão publicadas em um ano ou mais tarde - é por isso que anos de experiência ainda importam, mesmo se você for um bom programador.

Em algumas áreas, ainda somos juniores . Não importa quanta experiência você tenha, sempre há lugares onde você tem pouco conhecimento. Reconhecer sua incompetência em uma área específica é o primeiro passo para preencher essa lacuna e obter ajuda de camaradas mais experientes.

Bônus : Gostei muito do artigo "Ser um programador líder" . Grande coisa, se em que ponto você está se perguntando o que esse trabalho significa.