Categorias

10 vícios que você precisa largar para se tornar um desenvolvedor melhor

Ano Novo, vida nova. É o momento de olhar para trás, para as escolhas do passado e refletir sobre as escolhas do futuro. Todo mundo deseja melhorar e qualquer momento é um bom momento para largar os vícios e buscar o aperfeiçoamento.

Não importa quantos anos de profissão nos temos, sempre existe espaço para melhoria. Em 2017, o site Techrepublic ouviu diversos desenvolvedores e elaborou uma lista dos 10 vícios do desenvolvimento que precisam ser abandonados por quem deseja uma longa e proveitosa carreira em TI:

1) Permanecer estagnado

Em qualquer área profissional, se manter atualizado é fundamental. Na área de Tecnologia da Informação essa verdade é ainda mais poderosa, com as mudanças acontecendo em velocidade vertiginosa. Esse é o conselho de Eugene Brodsky, gerente de desenvolvimento de software da SaferVPN:

Sempre se concentre no aprendizado, acompanhando as últimas notícias e lendo pelo menos cinco artigos por dia sobre o que está acontecendo no setor. Certifique-se de escolher as áreas que você gosta, bem como algo que você está menos familiarizado, a fim de obter uma ampla gama de informações

2) Acreditar que os desafios do ambiente de trabalho serão iguais aos do ambiente anterior

Um erro comum de quem está começando na profissão é acreditar que experiência é tudo: frequentemente as práticas, políticas e necessidades de uma nova empresa não correspondem àqueles da sua empresa anterior. Em desenvolvimento, abordagens diferentes podem estar sendo empregadas e as lições do passado podem não ser aplicáveis.

Para Gene Richardson, COO de Experts Exchange:

Cada empresa é diferente e cada empresa implementará ou codificará suas próprias soluções tecnológicas. Essencialmente, você precisa abandonar todos os velhos hábitos e abordar o trabalho com a mente aberta enquanto tenta abraçar e entender por que eles fazem o que fazem. Quando estiver lá por pelo menos 90 dias, você poderá começar a fazer sugestões sobre como as coisas poderiam ser melhoradas. Tenha certeza de que você sabe do que está falando e pode apoiar sua posição com os fatos.

Christopher Mendy, CTO da Evus Technologies, reforça essa dica:

Não pense jamais que você dominará alguma coisa – o desenvolvimento nos dias de hoje é apenas educação continuada. Se você estiver em um escritório com outros desenvolvedores, ouça primeiro e depois fale. É a maneira mais rápida de aprender.

3) Trabalhar isolado

Da mesma forma, você deve aproveitar ao máximo a sinergia que brota dentro de um ambiente de trabalho. Colaboração é importante tanto para desenvolvedores iniciantes quanto para desenvolvedores veteranos e sempre há algo a aprender da experiência dos outros e da cooperação. O conselho de Megan Leese, diretora de estratégia web e desenvolvimento da The James Agency é cristalino sobre trabalho em equipe:

A maioria dos desenvolvedores seniores prefere que um novo desenvolvedor faça muitas perguntas em vez de quebrar a própria cabeça e não pedir ajuda. Da mesma forma, trabalhar sozinho e não fazer o check-in com os membros da equipe pode levar a um desperdício de esforços quando um problema em potencial poderia ter sido solucionado por outros no início de um projeto.

4) Pressupor que o usuário ou o ambiente onde o produto será utilizado são conhecidos

Desenvolvedores tem o péssimo hábito de culpar os usuários pelo mal uso de suas soluções ou pelo fracasso de seu produto. Para evitar esse tipo de abismo cognitivo entre quem produz software e quem o utiliza, existe todo um trabalho de comunicação que precisa ser realizado. É necessário ter uma compreensão real das pessoas do outro lado da tela ou do sistema. Para Karen Panetta, decana da Escola de Engenheria da Universidade de Tufts, pressupor errado o usuário ou os cenários de uso “é a pior coisa que um desenvolvedor pode fazer”.

E ela completa:

Se houver uma especificação funcional para o produto não totalmente especificada para cada cenário, suposições erradas podem matar o produto. Em alguns casos, as pessoas que financiam o desenvolvimento de um produto podem não ser experientes em tecnologia e é por isso que pagam aos especialistas que podem antecipar suas necessidades. A coleta dessas informações só acontece por meio de excelentes habilidades de comunicação e apresentação e da capacidade de transmitir seus conceitos a qualquer nível de público-alvo.

5) Subestimar medidas de segurança

Já não é de hoje que segurança se tornou um elemento fundamental no desenvolvimento de produtos de tecnologia e não dá mais para tapar o sol com a poeira ignorando as ameaças sempre presentes. Mike Ahmadi, diretor global de segurança de sistemas críticos da Synopsys Software Integrity Group faz um alerta muito sério:

Um hábito muito ruim é incorporar cegamente bibliotecas de terceiros com vulnerabilidades conhecidas na base de código, seja por meio de transmissão herdada, que é muito comum, ou por não avaliar a segurança no momento da seleção de novas bibliotecas. Isso, assim como o desenvolvimento de código sem um entendimento básico dos princípios da construção de código seguro, leva a uma proliferação de software inseguro que se espalha por toda a cadeia de suprimentos de software, deixando cada desenvolvedor sucessivo e, em última instância, o usuário final, com uma grande bagunça para limpar, se possível, ou terminar vivendo com ela.

6) Não testar o código

Se erros escapam mesmo quando um software ou sistema é testado, imagine o que acontece quando os testes não são realizados ou são insuficientes? Existe um velho equívoco que imagina que, se um produto funciona nas condições do ambiente do desenvolvedor, ele irá funcionar em qualquer lugar e isso gera problemas. A recomendação é testar todos os elementos de todas as formas possíveis exaustivamente, inclusive em cenários para os quais o produto não foi designado.

Karen Panetta, decana da Escola de Engenheria da Universidade de Tufts, volta a ressaltar:

Essa é uma das maiores reclamações que ouço de empregadores sobre desenvolvedores recém-contratados. Entender testes robustos e testes de regressão é essencial. Se você consertar alguma coisa, como você sabe que não quebrou outra coisa?

Tom Coughlin, membro senior do Instituto de Engenheiros Eletricistas e Eletrônicos dos Estados Unidos e fundador da Coughlin Associates, reforça o conselho:

Quebre um problema em pedaços, depois construa e teste-os separadamente e juntos.

7) Não documentar o trabalho

Ninguém gosta de documentar um projeto mas essa é uma etapa essencial para a realização de testes, para trabalho cooperativo e para assegurar a manutenção futura de tudo que já foi realizado. É um requisito básico e sinal de profissionalismo elaborar uma documentação estruturada para outras pessoas.

Megan Leese, diretora de estratégia web e desenvolvimento da The James Agency é direta sobre o tema:

Na escola, é fácil acompanhar o trabalho que você fez e relembrar toda a história de um projeto ou tarefa. Trabalhando profissionalmente em um ambiente de desenvolvimento acelerado, é fácil esquecer por que você desenvolveu algo do jeito que você fez e passar horas imaginando o que você fez para fazer uma edição em um trabalho concluído.

Sua bronca é acompanhada da mesma opinião de Mark Tuchscherer, presidente da Geeks Chicago:

Nós nos deparamos com tantos desenvolvedores, ou pessoas que querem se tornar desenvolvedores, que acham que tudo que precisam fazer é escrever código. Eles não querem lidar com a documentação do código em que trabalharam e foi enviado para o servidor. Isso pode transformar qualquer projeto em um pesadelo. Tivemos que abandonar muitos grandes desenvolvedores que tornaram o trabalho de todos os outros três vezes mais difícil, porque eles não poderiam quebrar esses maus hábitos

8) Alterar mais de um elemento de cada vez

Completando a catástrofe, muitas vezes influenciados pela limitação de tempo, desenvolvedores poderem alterar elementos demais de seu produto em uma única investida. Some a isso os vícios anteriores de não testar e não documentar o projeto e temos a receita certa para problemas graves. John Chapin da Capital Technology Services dá um conselho bastante útil:

Os desenvolvedores têm que olhar para cada mudança, como subir um único andar de cada vez – qualquer um sentiria que subir 10 andares e saltar do topo seria um movimento de alto risco. O mesmo se aplica a fazer várias alterações em um sistema de software. Faça as pequenas alterações seguras e integre-as novamente na base de código o mais rápido possível.

Fazer pequenas alterações e confirmar alterações em arquivos individuais também torna mais fácil rastrear qual alteração em um sistema é responsável por qualquer comportamento indesejado.

9) Assumir tarefas em excesso

É comum que desenvolvedores acreditem ser capazes de lidar com múltiplas tarefas ao mesmo tempo, assim como também é comum que empregadores sobrecarreguem seus profissionais com responsabilidades em excesso que sequer estão conectadas. Esse vício prejudica a produtividade e afeta a qualidade do trabalho.

Dmytro Moroz, estrategista de marketing digital da Kanbanize, explica um problema que é comum na indústria da tecnologia:

Em um trabalho que requer concentração mental total e foco extremo, você não pode permitir quaisquer interrupções. O custo da mudança de contexto para sua mente e seu efeito sobre sua produtividade é muito mais sério do que você imagina. Tornar-se um grande desenvolvedor significa aprender “singletask” e dizer não a distrações externas ou a novas solicitações de trabalho durante a conclusão de um projeto.

10)  Escrever funções imensas

Esse é um vício comum entre iniciantes, que escrevem linha após linha de código gerando funções que deveriam ser um “canivete-suíço” para qualquer situação, mas acabam sendo úteis somente para ambientes e cenários muito específicos, prejudicando sua usabilidade, sua compreensão para outros membros da equipe e atrapalhando o fluxo dos testes. Andrew Magee, gerente de desenvolvimento da Enigma Digital decreta:

Uma função deve fazer uma coisa e apenas uma coisa. Se faz mais de uma coisa, falta foco.