Quatro anos como engenheiro de software em uma startup de alto crescimento, aprendi algumas lições muito valiosas sobre as quais reflito aqui. Esta é uma lista crescente e continuarei acrescentando a ela.

O trabalho está sempre mudando . Principalmente quando a empresa é pequena. Quando comecei na OpenGov como o 180º funcionário, não sabia dizer se estaria fazendo o mesmo trabalho que fazia na época, um mês depois. As coisas estão mudando rapidamente, a empresa está tentando encontrar seu lugar no mercado e isso vem com requisitos em constante evolução.
Você é a cultura . Quando uma empresa é pequena, cada coisa nova, processo ou melhoria técnica introduzida por você pode ser adotada por toda a organização de engenharia. (ou, em alguns casos, toda a empresa) e pode se tornar parte da cultura à medida que a empresa cresce. Isso, na minha opinião, é muito gratificante e nem todo mundo tem essa oportunidade. Sempre procure coisas que você pode melhorar e tente iniciar uma discussão. Você não precisa fazer todo o trabalho pesado sozinho; identificar o que poderia ser melhorado e dar o primeiro passo é um longo caminho.
Toque em cada parte da pilha . Em uma startup que trabalha como engenheiro, as funções raramente têm um limite claro das “coisas” nas quais você pode ser solicitado a trabalhar, especialmente como engenheiro júnior. Você pode esperar trabalhar no front-end, back-end, infraestrutura, bancos de dados e muito mais. Desde a preparação de um backlog do JIRA para um recurso até a implantação do código relacionado, tudo faz parte do trabalho.
As coisas quebram. Você implanta um trecho de código que quebra o sistema ou não se comporta como em um ambiente de pré-produção. Às vezes, a infraestrutura quebra e você não consegue implantar nada! Todas essas são oportunidades para aprender e melhorar. No opengov, embora tivéssemos uma equipe devops dedicada para lidar com questões como essas, nós, como engenheiros, também fomos expostos ao lado operacional da engenharia de software.
A documentação é importante. Como estamos ocupados escrevendo e enviando o código, a documentação tende a ficar em segundo plano. Vale a pena dedicar algum tempo, em cadência regular, para criar nova documentação e manter atualizados os existentes. Uma boa documentação é, na minha opinião, o sinal de uma equipe de alto desempenho. À medida que as pessoas vão e vêm, especialmente no caso de startups, a documentação é o que ajuda a integrar novas pessoas e a espalhar o conhecimento de vários sistemas e domínios entre os membros da equipe existentes.
A comunicação é difícil . Para obter a adesão de diferentes partes interessadas para um projeto técnico, você precisa explicar como ele agrega valor ao seu cliente. Você deseja passar os próximos sprints refatorando o gerenciamento de estado do seu aplicativo? Bem, prepare-se para explicar ao produto ou ao seu EM (que por sua vez precisará explicar aos superiores) por que isso é importante. Às vezes, há um benefício direto para o usuário final, como tempos de carregamento mais rápidos do aplicativo, melhor UX etc. Outras vezes, o benefício seria uma melhor experiência do desenvolvedor, o que aceleraria o desenvolvimento de recursos no futuro. Seja o que for, formar essa narrativa corretamente pode ser complicado e, mesmo que você não esteja envolvido nessas negociações, sugiro sempre diminuir o zoom e olhar para o seu trabalho pelas lentes do usuário.
Encontrar o mentor certo. Como em outras disciplinas, a orientação pode mudar o jogo de um jovem engenheiro. Um mentor não precisa segurar sua mão para lhe ensinar algo, mas sim empurrá-lo na direção certa. Eles têm vasta experiência na área, são profissionais experientes e estão dispostos a compartilhar seus aprendizados com você. Entre em contato com as pessoas em sua equipe/empresa que você admira e discuta um problema que está resolvendo, um documento de design técnico que está escrevendo ou qualquer coisa sobre a qual precise de orientação.

memórias de engenharia de software