Na minha primeira função de engenharia de software em uma marca de comércio eletrônico, muitas vezes trabalhei secretamente em tarefas fora das minhas responsabilidades principais. E muitas vezes me senti isolado dos meus colegas de equipe.

Portanto, quando fui convidado a participar de um curso baseado em projetos para melhorar minhas habilidades de comunicação, aproveitei a oportunidade.

Para o programa, fui designado para uma equipe com dois outros engenheiros e um líder de equipe para criar um aplicativo de pilha cheia usando React, Python e Flask. Agora que o curso terminou, pensei em compartilhar as lições que aprendi sobre como ser um melhor jogador de equipe.

Lição 1: Não subestime o nível de dificuldade potencial de um projeto

Como o curso foi destinado a engenheiros iniciantes, achei que teria uma vantagem, pois já tinha alguma experiência profissional com o Node.js. É verdade que nossa pilha de tecnologias usaria um back-end do Python Flask, mas imaginei que o Python e o Flask não seriam muito difíceis de entender.

No primeiro dia do nosso projeto, foi-nos mostrado o que estaríamos construindo. Uau, de repente me senti muito despreparada. Nosso projeto foi significativamente mais desafiador do que eu esperava.

Meus outros dois colegas de equipe pareciam pegar o material facilmente. No final de nossa primeira semana, eu era o membro menos colaborador da nossa equipe.

Eu conhecia o React muito bem, então nosso front end não foi muito difícil para mim. Mas nosso back-end estava usando PostgresSQL e Python, nenhum dos quais eu conhecia bem. Logo ficou claro que as tarefas esperadas de nós seriam particularmente desafiadoras para alguém com pouca experiência em Python.

Lição 2: solicitar feedback sobre o trabalho em andamento

Inicialmente, muitas vezes me vi perdendo tempo fazendo trabalhos desnecessários. Por exemplo, uma vez eu estava criando um formulário de perfil de usuário editável, sem perceber que meu colega de equipe estava no meio da criação de um componente reutilizável da caixa de diálogo Material UI que eu poderia ter usado.

Outra vez, passei um tempo lendo um tutorial sobre como obter a identidade de um usuário autenticado, sem perceber que meu colega de equipe já havia descoberto.

Percebendo quanto tempo gastava em trabalhos desnecessários, comecei a postar em nosso quadro de mensagens do Slack o que estava trabalhando e solicitando feedback. Meus colegas de equipe foram rápidos em responder. Ao fazer com que meus colegas contribuíssem com meus projetos inacabados, fui capaz de evitar a duplicação de trabalhos.

Lição 3: quando pressionado pelo tempo, priorize o que evitar aprender

Dado que lutei para acompanhar a carga de trabalho, precisava priorizar melhor meu tempo. Sempre que alguém criava um novo recurso, ele criava um Git Pull Request (PR) para solicitar a revisão do código. No começo, revi todas as relações públicas e dei a cada uma delas minha total atenção. No entanto, isso logo se mostrou impraticável.

Lembro-me de passar muito tempo revisando o PR para adicionar cookies e tokens para autenticação. Para fazer uma revisão adequada, primeiro li muitas informações básicas sobre problemas de segurança, como cookies, armazenamento local e ataques de script entre sites. Quando terminei toda essa leitura, li o PR, apenas para descobrir que todo o código fazia sentido e não havia nada para comentar.

Em retrospectiva, dado o quão atrasado eu estava com minhas próprias tarefas, eu deveria ter ignorado grande parte da documentação dos cookies e feito apenas uma rápida revisão de relações públicas para economizar tempo.

Ganhar um conhecimento profundo do funcionamento interno de nossa autenticação de cookies foi de pouca utilidade para minha produtividade geral. Por outro lado, outros PRs, como o que configurou o React Context para passar o estado pelo aplicativo, afetaram diretamente quase todos os recursos em que trabalhei.

Priorizar a compreensão profunda desse PR teria sido um uso muito mais valioso do meu tempo.

Lição 4: crie novos recursos, indo de um pedaço para outro

Para ficar mais organizado, tive que aprender a percorrer a documentação técnica. Liguei para um amigo meu sênior de engenharia, Sean Ellison-Chen, e pedi ao seu processo que resolvesse um novo recurso que requer uma tecnologia que é totalmente nova para ele.

Ele explicou que primeiro tenta entender no máximo 70% do que está acontecendo e, em seguida, começa imediatamente a criar o recurso em pedaços. Cada pedaço é comprometido com o git.

Por exemplo, digamos que ele precise configurar soquetes da Web, ele pode configurar uma estrutura básica de esqueleto para soquetes da Web, comprometê-la com git e, em seguida, trabalhar na próxima parte da configuração dos eventos de soquete corretos e assim por diante.

Ao trabalhar em blocos, ele garante uma progressão suave, desde o mínimo necessário até o final de um recurso totalmente funcional.

Lição 5: solicite feedback do seu líder de equipe

No meio do programa, recebi feedback do líder da nossa equipe, Shums Kassam. Disseram-me para pedir mais ajuda, vasculhar a documentação e alavancar meus colegas de equipe.

Tomei o conselho de coração e aumentei a quantidade de vezes que postei em nosso quadro de mensagens. Comecei a ter videochamadas com colegas de equipe para revisar os recursos que eu estava criando. Percorri a documentação técnica mais rapidamente e evitei as áreas menos críticas. Ao implementar essas mudanças, minha taxa de contribuições acelerou.

Lição 6: Evite fazer um trabalho perfeito em tarefas cujos requisitos possam mudar

Por pura sorte, aprendi a importância de procrastinar em tarefas cujos requisitos podem mudar.

Uma das minhas primeiras tarefas foi criar um formulário front-end que permita aos usuários alterar suas informações de perfil. Quando enviei meu código para revisão, disseram-me que a aparência do formulário precisava ser corrigida, pois alguns dos comprimentos de entrada não correspondiam.

Normalmente, eu teria gasto 45 minutos para consertá-lo naquele momento. Mas eu estava muito atrasado em minhas contribuições, então, em vez disso, apenas comentei um “todo” sobre a correspondência dos comprimentos de entrada e mesclei meu código.

Uma semana depois, um colega de equipe apontou que seria uma melhor experiência do usuário combinar as entradas ‘rua’, ‘cidade’, ‘estado’ e ‘país’ separadas em uma única entrada de ‘endereço’. Quando ele simplificou as entradas, meu comentário “todo” não era mais aplicável.

Ao procrastinar com o trabalho no formulário, eu me salvara de fazer um trabalho desnecessário.

Lição 7: fique à vontade para enviar código não refatorado

Perto do final do nosso projeto, nossa equipe corria para concluir todos os nossos recursos antes de uma data fixa, quando apresentávamos nosso projeto a um público. Planejamos enviar todos os recursos com bastante antecedência para nos dar tempo suficiente para praticar e ensaiar.

Mas acabei enviando meu recurso final com apenas uma hora para nossa demonstração e tivemos que nos apressar para adicioná-lo. Embora nossa apresentação tenha corrido bem, fiquei incomodado por ter submetido o recurso tão tarde, pois reduziu severamente a capacidade de nossa equipe de ensaiar. nossa demo com antecedência.

Em retrospectiva, percebo que, em vez de enviar código otimizado e limpo, eu poderia ter economizado pelo menos duas horas de tempo simplesmente adicionando comentários sobre refatoração posteriormente.

Nos últimos meses, aprendi muitas lições sobre como ser um melhor jogador de equipe. Mais importante, aprendi que o trabalho em equipe é uma habilidade que pode ser aprimorada como qualquer outra.

O programa em que participei foi administrado por Hatchways, uma empresa que ajuda engenheiros de software a conseguir seus primeiros empregos. No momento da redação deste artigo, eles prestam serviços de manutenção a engenheiros e empresas na América do Norte. Se você é um empregador que procura contratar estagiários ou engenheiros iniciantes, consulte Hatchways – Empregadores.

Sou da cidade de Nova York e atualmente estou procurando uma nova posição em engenharia de software. Aqui está meu resumo. Meu email é [email protected]



Fonte