Olá, desenvolvedor, tudo bem? Alguém já te perguntou hoje como foi o seu dia? Para ser um engenheiro de software competente, você se vê diante de um oceano de habilidades exigidas pelo trabalho: cada empresa tem o seu stack, o seu jeito de trabalhar e a sua cultura. Em quais habilidades focar? Quais você precisa ter?
De modo geral, as habilidades são divididas entre “Hard Skills” e “Soft Skills” e a avaliação normalmente considera uma combinação das duas. Às vezes é difícil enxergar como as soft skills aparecem na prática, ainda mais quando o engenheiro não tem o hábito de prestar atenção nelas. Neste artigo, mostro alguns atributos, métodos e ferramentas que um engenheiro pode aplicar para conectar melhor soft e hard skills no dia a dia.
Enxergue além da tarefa
Cada atividade, cada tarefa e cada story de desenvolvimento estão inseridas em um contexto muito mais amplo. Elas não chegaram até você apenas para serem “codadas” e nunca mais vistas. Para ajudar a entender isso melhor, desenhei uma linha de raciocínio ideal em oito passos. Você pode tratá-la como um método ou como uma referência simples.
Entenda e compre a ideia
O primeiro passo deve ser sempre entender, mas, além disso, é fundamental que você concorde com a forma como a tarefa será desenvolvida. Desenvolver contra a própria vontade dificilmente traz um bom resultado.
Levante os critérios de aceite
Esse é um dos passos mais ignorados do desenvolvimento. Afinal, você já sabe o que fazer, então por que perder tempo escrevendo os critérios? A resposta é simples: como você garante que o seu entendimento é o mesmo dos outros stakeholders?
Abstraia e materialize
É normal fazer algumas modificações na ideia original ao transformá-la em código, por uma série de motivos: facilidade de entendimento, performance e viabilidade. Então, nesse passo, você resolve coisas como modelar os dados no banco, montar os modelos lógicos no código, definir como eles interagem e como inserir e consultar as informações que a aplicação exige.
Planeje e arquitete
Você provavelmente já ouviu que existe mais de um jeito de resolver o mesmo problema. Esse passo é o momento de escolher qual solução será aplicada e seguida. Documente, desenhe e compare soluções diferentes para chegar ao melhor resultado.
Desenvolva (código e testes)
Agora sim é hora de escrever código de verdade: siga os padrões de desenvolvimento, faça os testes necessários e aplique o seu conhecimento.
Revise e analise
Fazer code review é uma prática excelente, não só para aumentar a qualidade do código, mas também para compartilhar conhecimento com os colegas. Preste atenção em complexidade cognitiva e redundância, e envolva outras pessoas do time.
Aprove
Agora que está tudo certo, você precisa buscar a aprovação do PO ou do cliente. É muito importante corrigir e ajustar o que for necessário antes de considerar a tarefa concluída. Mesmo que nada te impeça de começar outra tarefa, tente deixar as tarefas aprovadas, ou melhor ainda, liberadas, e não acumule coisas esperando aprovação, porque isso pode virar um refactoring grande lá na frente.
Olhe o projeto inteiro
Tenha sempre em mente como está o backlog: o que já foi feito, o que ainda falta e qual é o prazo. É aqui que você avalia se o planejamento está indo como o previsto ou se precisa de ajuste.
Com esse fluxo em mente, fica mais fácil pensar nas características que um desenvolvedor precisa ter para entregar melhor.
Seja autêntico
Tecnologia é uma área em evolução constante, então as ferramentas que os programadores escolhem e o que se aprende ao longo da carreira pesam bastante. Bons engenheiros entendem o que é bom para eles e o que é bom para o projeto; não aceitam qualquer coisa, mas também não negam tudo; são criteriosos e conscientes das próprias escolhas. Ainda assim, alguns comportamentos aparecem com muita frequência e me chamam a atenção:
- Achar que biblioteca e framework novos são responsáveis por um código melhor: estrutura de pastas, separação de responsabilidade e uso de Design Patterns são alguns dos itens que deveriam governar a qualidade do que você escreve. Eu uso bibliotecas e frameworks com critério, como ferramenta e não como ditador;
- Biblioteca externa para cada feature simples: com uma comunidade open source cada dia mais forte, existem bibliotecas de sobra à disposição. Isso não quer dizer que você deva adaptar cada parte do seu código para encaixá-las. Legibilidade, escalabilidade do código e exposição a vulnerabilidades importam. Pese benefícios e ressalvas, e não deixe uma biblioteca guiar a estrutura do seu código. Usar uma biblioteca de terceiros não terceiriza a responsabilidade. Tenha clareza dos impactos que ela traz;
- Curso é didático e só isso: muitas videoaulas e cursos disponíveis passam a impressão de que se desenvolve tudo de forma rápida e fácil com “novas tecnologias”, mas não esqueça que desenvolver é muito mais do que “digitar as palavras certas em um editor”, como foi dito no começo do artigo. Então, ao fazer um curso, aprenda o conteúdo, mas aprenda também a encaixá-lo no seu mundo, e não o contrário;
Seja rigoroso com o que você entrega
Muitos engenheiros não enxergam todas as bordas do que está sendo desenvolvido, e às vezes é preciso tentar sabotar o próprio trabalho para descobrir esses limites. Ao desenvolver, é comum considerar apenas os critérios de aceite levantados antes e esquecer de avaliar as formas diferentes com que um usuário pode interagir com a aplicação. Não pense só no caminho ideal, pense também em todos os caminhos alternativos que um usuário pode testar.
Tem quem argumente que isso seria trabalho do designer de UX/UI. Entregar um produto de altíssima qualidade é esforço de time. Ainda que requisitos e especificações iniciais sejam o guia principal da implementação, muitos detalhes só aparecem no caminho. Então preste atenção, tenha a cabeça aberta e seja rigoroso com o que entrega.
Entenda conceitos de gestão de projetos
Coordenar, planejar e executar um projeto é trabalho do gerente de projetos. Você deve estar pensando que um desenvolvedor não precisa nem se preocupar com isso, e você tem alguma razão, mas, mesmo que não seja a sua preocupação principal, você é corresponsável. É bem ingênuo não saber sequer o que um PM faz.
Na relação entre PMs e engenheiros, há momentos em que o engenheiro deve delegar funções ao PM e vice-versa. Só que como fazer isso sem saber o que a outra pessoa faz? Ou se ela está disponível para você? Pergunte. Ajude. Você também consegue apoiar o PM ou até delegar tarefas que ajudem o projeto.
Habilidades de gestão de release e de time aparecem dentro do seu código: nome de branch, formato de commit, fluxos de git e por aí vai. Saiba usar isso a seu favor.
Controle o seu tempo
Ao longo de anos de trabalho, percebi como é difícil controlar o tempo: “preciso ignorar as pessoas para manter o foco e bater o prazo”, ou “nem vi o tempo passar”.
Tenha sempre em mente que você precisa dividir o seu tempo entre todos os passos do desenvolvimento, e não só o tempo de “escrever código”. Cada pessoa é diferente, então funciona melhor quando você encontra o seu próprio jeito, seja definindo metas, seja usando ferramentas de time tracking. Use a criatividade. Não concentre todo o seu tempo em uma coisa só, senão as outras vão virar os seus pontos fracos.
Adapte-se
A tecnologia evolui muito rápido. É impressionante o quanto o desenvolvimento de software mudou em tão pouco tempo, então vale aceitar que o jeito de trabalhar hoje pode não ser o jeito de trabalhar amanhã.
Mas tenha em mente que nem toda novidade vira o novo padrão. Tenha consciência das ferramentas que você escolhe para trabalhar, aplique pensamento crítico sobre prós e contras e evite escolher algo só porque é novo.
Se precisamos nos adaptar às ferramentas que escolhemos, por que não adaptar também o uso do que escolhemos? Aqui na Cheesecake Labs, por exemplo, queríamos seguir o gitflow junto com o rastreamento feito pelos smart-commits do Jira. Nesse caso, mudamos a forma de nomear as branches e também desenvolvemos uma ferramenta open source para ajudar a adicionar a informação do smart-commit de um jeito mais ágil. Isso não quer dizer que estejamos certos ou errados, nem que não sigamos as diretrizes do gitflow ou do smart-commit, mas sim que adaptamos à nossa realidade e ao que acreditamos para que aquilo funcione da melhor forma.
Dê um passo à frente
Todos os pontos acima são soft skills. Quis destacar como elas impactam diretamente as tarefas do dia a dia, e até as entrevistas, e como muitos engenheiros não levam isso em conta. Resolução de problemas, visão sistêmica, adaptabilidade, resiliência e paciência são as palavras que mais aparecem, mas nem sempre alguém explica o que elas significam na prática.
Fazer acontecer depende só de você. Evolução nunca é repentina. Para crescer, basta dar um passo pequeno por dia, e com o tempo você fica melhor. Dê sempre um passo à frente.
