Vitor's Blog
Published on

O que aprendi como fullstack?

Authors
image

Fullstack

Um desenvolvedor fullstack vai muito mais além que saber programar front e backend.

Para ser um bom desenvolvedor fullstack, você precisa entender o processo completo.

O discurso de ir contra a pessoa fullstack, como alguém que consegue fazer tudo, mas de forma medíocore, não faz sentido. Essencialmente, bons programadores já vão ter uma noção completa de um sistema. O conhecimento de front, back ou Devops não são opostos ou separados. Trabalhe em construir sua bola de neve do conhecimento. Tudo agrega, se conecta e é útil de alguma forma.

Excluir uma gama de conhecimentos de front, por ser backend, não é especialização. É ignorância.

Smart Copy and Paste

Um conceito importante é a capacidade de copiar e colar código de forma inteligente. Para fazer isso eficientemente, você vai precisar saber o que copiar, onde copiar, e o que o código que copiou está fazendo. Todos esses itens exigem um conhecimento prévio da code base. E tem algumas formas de conseguir isso:

  • Referências: meu tech lead costuma referenciar PR's e issues já resolvidas nas novas que são abertas. Isso ajuda com que os devs tenham um ponto de partida, comecem a conhecer e mapear a code base. Onde buscar o que querem, e começar a construir um modelo mental melhor. Isso também faz com que o time tenha a capacidade de referenciar algo que já tenha sido construído por eles nas próximas PR's e issues.

  • Codando: quanto mais você coda, mais vai conhecer a code base. Depois de resolver diversas issues, terá autonomia dentro da code base, saber onde buscar o que eu quero, códigos de referência etc.

  • Code review: mesmo que você não seja o tech lead, é importante revisar todas a PR's do seu time. Isso nem sempre é viável caso o time seja muito grande, tente revisar algumas, se for o caso.

Revisar PR's, mesmo se não estiver entendendo o que foi feito, vai fazer com que você entenda o que os outros devs do time estão trabalhando, melhorando, e a forma com que eles inicialmente pensaram em resolver X problema. O ideal é tentar entender o motivo das mudanças. O que faz ela ser melhor que outra?

Copiar e colar código também vai te ajudar a não ter erros já corrigidos, conseguir entregar mais rápido, e codar o que realmente importa, invés de algo que já existe e alguém já resolveu antes de você.

Perguntas e comunicação

Comunicação assíncrona: conseguir montar uma pergunta de forma clara, objetiva, com exemplos, links úteis, e possíveis soluções ou tentativas, é importante.

Todo mundo está ocupado. Se você conseguir montar uma boa pergunta, você será ajudado de forma mais rápida. Como refência, recomendo fortemente a leitura desse artigo.

Feedbacks

Feedbacks são importantes. Saiba receber feedbacks, até mesmo os negativos. Procure entender a causa. Tão importante quanto entender a causa é saber como não cometer o mesmo erro. Isso é evolução constante. Para manter a evolução, é necessário criar um ciclo de feedbacks e melhorias. Se você trabalha em uma equipe que não possui a cultura de feedbacks, converse com a liderança e comece a engajar o time a criar essa cultura. Fique atento caso essa mudança não ocorra. Pode ser uma red flag.

Resolução de tasks

Quando o degrau vai subindo, as tasks nem sempre são tão claras e você vai precisar pensar um pouco mais e ter mais organização.

Parte desse processo é conhecimento tácito. Quanto mais problemas tentar resolver, mais você vai ficar bom em resolver problemas.

Conseguir resolver problemas é a bola de neve gerada pelos tópicos anteriores.

Conclusão

As pessoas mais inteligentes estão nas startups. Tentar aprender o máximo com elas é o ideal. É um ambiente dinâmico, com comunicação rápida, e time reduzido. Você vai aprender muito sobre tudo, e nem sempre relacionadas com desenvolvimento.

Se você está começando como desenvolvedor, é Junior ou está buscando pela sua primeira oportunidade, startup não é redflag. Vai ser o local onde você mais vai aprender.