Existem muitas habilidades técnicas que um engenheiro de software deve dominar, mas outras apenas com a experiência do dia a dia no mercado de trabalho podem desenvolver. Vamos te dizer sete delas para você se tornar um profissional ainda mais preparado.

1. Aprenda a ler o código de outras pessoas

É uma grande habilidade, que possui vários benefícios,  poder seguir o código de outras pessoas.

Não importa o quão confuso ou mal pensado seja o código de um engenheiro anterior, você ainda precisa ser capaz de percorrê-lo. Afinal, é o seu trabalho. Mesmo quando você era esse engenheiro um ano antes.

Essa habilidade o beneficia de duas maneiras. Por um lado, poder ler o código de outras pessoas é uma ótima chance de aprender o que é um design ruim. Enquanto você olha o código de outras pessoas, aprende o que funciona e o que não funciona. Mais importante, você aprende que tipo de código é fácil para outro engenheiro seguir e que código é difícil de seguir.

Você precisa garantir o máximo possível de leitura ao ler o código de outras pessoas. Dessa forma, outros engenheiros entendem o quanto você é um engenheiro superior.

Lembre-se de mencionar a importância do código de manutenção e bons comentários. Isso mostra ainda mais seu domínio na área de programação.

Seu código deve ser tão bem projetado que não requer documentação. De fato, você não deve documentar nenhum código, se for um bom programador. Isso é apenas uma perda de tempo e você precisa gastar seu tempo codificando e em reuniões.

Ser capaz de ler o código confuso de outras pessoas também facilita a atualização quando necessário. Ocasionalmente, isso significa atualizar o código em que você não possui experiência. Por exemplo, uma vez seguimos um script de Powershell a Python e Perl. Tínhamos experiência limitada em Perl, mas ainda tínhamos contexto suficiente para descobrir o que estava acontecendo e fazer as alterações necessárias.

Isso ocorre por ter um entendimento decente de todo o código, além de poder ler os scripts Perl. A leitura do código de outras pessoas o torna valioso porque você pode seguir até sistemas com engenharia excessiva que podem surpreender os outros.

2. Senso para identificar projetos ruins

Existem muitas habilidades que levam tempo para aprender. Uma das habilidades que acreditamos que vale a pena conhecer é entender quais projetos não valem a pena ser realizados e quais são claramente marchas da morte.

As grandes empresas sempre têm muito mais projetos em andamento do que provavelmente jamais serão concluídos ou impactantes. Existem alguns projetos que podem não fazer sentido nos negócios (pelo menos não para você) e outros que são mal gerenciados. Isso não quer dizer que você deva interromper uma ideia quando discordar do projeto. No entanto, se as partes interessadas não puderem explicar adequadamente o que farão com o resultado final, talvez o projeto não valha a pena.

Além disso, alguns projetos podem ser tão focados na tecnologia em vez da solução que pode ficar claro desde o início que não haverá muito impacto. Essa habilidade requer muitos projetos ruins antes que você tenha uma idéia do que realmente é um projeto ruim. Portanto, não gaste muito tempo cedo tentando discernir cada projeto.

Em algum momento de sua carreira, você terá apenas um bom senso.

3. Evitando reuniões

Seja você um engenheiro de software ou cientista de dados, as reuniões são uma necessidade, porque você precisa estar na mesma página com seus gerentes de projeto, usuários finais e clientes. No entanto, também há uma tendência para as reuniões assumirem repentinamente toda a sua agenda. É por isso que é importante aprender a evitar reuniões desnecessárias. Talvez uma palavra melhor para usar seja gerenciar e não evitar. O objetivo aqui é garantir que você gaste seu tempo em reuniões que conduzam decisões e ajudam sua equipe a seguir em frente.

O método mais comum é simplesmente bloquear um bloqueio de duas horas todos os dias, que é uma reunião constante. Geralmente, a maioria das pessoas marca uma reunião recorrente em um momento que considera benéfico. Eles usarão isso como um tempo para acompanhar seu trabalho de desenvolvimento.

Outra maneira de evitar reuniões para que você possa realizar o trabalho é aparecer antes de qualquer outra pessoa. Pessoalmente, gostamos de aparecer cedo porque, em geral, o escritório é mais silencioso. A maioria das pessoas que aparece cedo é como você, apenas querendo fazer o trabalho para que ninguém o incomode.

Isso é importante para colaboradores individuais, porque nosso trabalho exige momentos em que nos concentramos e não conversamos com outras pessoas. Sim, há momentos em que você pode resolver problemas em que pode querer trabalhar com outras pessoas. Mas assim que você passar pelos problemas de bloqueio, precisará codificar. É sobre entrar nessa zona em que você está constantemente segurando muitas idéias complexas sobre o trabalho que está fazendo. Se você estiver constantemente parado, pode ser difícil continuar de onde parou.

4. Esteja sempre com dicas de comando Git

Alguns especialistas em CS começaram a usar o Git no dia em que nasceram. Eles entendem todos os comandos e parâmetros e podem fazer círculos em torno dos profissionais.

Outros experimentam o Git pela primeira vez no primeiro emprego. Para eles, o Git é um cenário infernal de comandos e processos confusos. Eles nunca têm 100% de certeza do que estão fazendo (há uma razão pela qual as folhas de dicas são populares).

Não importa qual sistema de repositório sua empresa use, o sistema será útil se você o usar corretamente e um obstáculo se for usado incorretamente. Não é preciso muito esforço para se transformar em você gastando horas tentando desembaraçar alguma mistura de vários galhos e garfos. Além disso, se você esquecer constantemente de obter a versão mais recente do repositório, também estará lidando com conflitos de mesclagem que nunca são divertidos.

Se você precisar manter uma folha de dicas de comando Git, faça-o. O que quer que torne sua vida mais simples.

5. Escreva códigos de simples manutenção

Uma tendência que os engenheiros mais jovens podem ter é tentar implementar tudo o que sabem em uma solução. Existe esse desejo de entender sua programação orientada a objetos, estruturas de dados, padrões de design e novas tecnologias e usar tudo isso em cada pedaço de código que você escreve. Você cria uma complexidade desnecessária porque é muito fácil anexar-se excessivamente a uma solução ou padrão de design que você usou no passado.

Há um equilíbrio com conceitos de design complexos e código simples. Padrões de design e design orientado a objetos devem simplificar o código no grande esquema das coisas. No entanto, quanto mais um processo é abstraído, encapsulado e com caixa preta, mais difícil pode ser a depuração.

6. Aprenda a dizer não e priorize

Isso vale para qualquer função, seja você um analista financeiro ou um engenheiro de software. Mas, em particular, os papéis da tecnologia parecem ter todos precisando de algo deles. Se você é um engenheiro de dados, provavelmente será solicitado a fazer mais do que apenas desenvolver pipelines. Algumas equipes precisarão de extrações de dados, outras precisarão de painéis e outras precisarão de novos pipelines para seus cientistas de dados.

Agora, priorizar e dizer não podem realmente ser duas habilidades diferentes, mas elas estão intimamente ligadas. Priorizar significa que você gasta apenas um tempo de alto impacto para a empresa. Considerando que dizer não às vezes significa apenas evitar o trabalho que deve ser tratado por uma equipe diferente. Eles geralmente acontecem em conjunto para todas as funções.

Essa pode ser uma habilidade difícil de adquirir, pois é tentador aceitar todos os pedidos apresentados em seu caminho. Especialmente se você for direto para a faculdade. Você quer evitar decepcionar alguém e sempre recebeu uma quantidade considerável de trabalho.

Nas grandes empresas, há sempre uma quantidade infinita de trabalho. A chave é apenas assumir o que pode ser feito.

Existem muitas habilidades que não são testadas em entrevistas ou mesmo sempre ensinadas em faculdades. Muitas vezes, isso é mais uma limitação do ambiente do que uma falta de desejo de expor os alunos a problemas que existem em ambientes reais de desenvolvimento.

7. Design de Operação

Uma habilidade que é difícil de testar em uma entrevista e difícil de replicar quando você está fazendo cursos na faculdade é pensar em como um usuário final pode usar seu software incorretamente. Costumamos fazer referência a isso como pensar em cenários operacionais.

No entanto, essa é apenas uma maneira educada de dizer que você está tentando falsificar código de prova.

Por exemplo, como grande parte da programação é de manutenção, muitas vezes significa alterar código altamente confuso com outro código. Mesmo uma alteração simples requer o rastreamento de todas as referências possíveis de um objeto, método e / ou API. Caso contrário, pode ser fácil quebrar acidentalmente os módulos que você não percebe que estão conectados. Mesmo se você estiver apenas alterando um tipo de dados em um banco de dados.

Também inclui pensar em casos extremos e pensar em todo um projeto de alto nível antes de iniciar o desenvolvimento.

Quanto aos casos mais complexos em que você está desenvolvendo novos módulos ou microsserviços, é importante dedicar seu tempo e refletir sobre os cenários operacionais do que você está construindo. Pense em como os usuários futuros podem precisar usar seu novo módulo, como eles podem usá-lo incorretamente, quais parâmetros podem ser necessários e se existem maneiras diferentes de um futuro programador precisar do seu código.

Simplesmente codificar e programar é apenas parte do problema. É fácil criar software que funcione bem no seu computador. Mas há várias maneiras de implantar código pode dar errado. Uma vez em produção, é difícil dizer como o código será usado e que outro código será anexado ao seu código original. Daqui a cinco anos, um futuro programador pode ficar frustrado com as limitações do seu código.