Algumas formas de evitar o sofrimento autoimposto em tecnologia

Tecnologia é uma área incrível pra se trabalhar com diversas áreas possíveis de atuação para todos os tipos e gostos.

Mas também podem haver alguns problemas comuns que nos causam sofrimento de diversas formas, como estresse e incertezas.

Nesse artigo vamos discutir algumas formas em que profissionais de TI causam o próprio sofrimento por meio de suas ações — e como contorná-las :)

Muitas dessas coisas são conceitos simples de entender e aplicar, mas que por muitas vezes são deixadas de lado pelas pessoas profissionais.

Ah, vale lembrar que muito disso vem do livro do Codificador Limpo, de Bob Martin, com algumas outras referências conectadas :)

#1 — Code review falho

Pense no seguinte cenário: uma pessoa da equipe manda um código para review que possui testes unitários. Eu reviso esse código e aprovo imediatamente, sem baixar o código na minha máquina e testar. Logo, fazemos o merge pra sandbox/produção e BOOM — algo quebra.

O que deu errado aqui?

• Primeiro, que haver testes unitários não garante que as peças se encaixam e funcionam corretamente, então precisamos sempre verificar que a solução proposta funciona de fato (rodando o projeto na nossa máquina local) e que a solução atende os requisitos propostos na tarefa inicial.
• Um pull request é uma solicitação de mudança. Só devemos aprovar essa mudança quando tivermos certeza que ela funciona.

E qual o sofrimento?

Depois que o código é integrado no ambiente de sandbox ou produção, muito provavelmente vamos causar impactos no mundo real.

Clientes irão ver os problemas, avisar o time de suporte, que depois irá avisar o time de desenvolvimento. Disso, naturalmente temos um estresse a mais por ter algum impacto rolando no mundo e causando danos.

Como melhorar?

Code review, testes e qualidade de software precisam ser uma premissa. Se algum bug escapar pra produção, que seja por conta de algo pouco detectável ou condições muito específicas, e nunca por negligência.

Referências

• My personal guide to code review — Marcelo Theodoro
• [PyBR2021] Code Review — André Girol
• Martin Fowler — Refinement Code Review

#2 — Não entender o problema a ser resolvido

Entender o problema que precisa ser resolvido é fundamental para que possamos chegar numa solução que resolva de fato o problema. Ao entendermos o problema que precisa ser resolvido, conseguimos validar se a solução proposta funciona.

O que pode dar errado?

Ao propor soluções que não resolvem de fato o problema, podemos muitas vezes acabar tendo que refatorar muito código, perder o tempo oportuno de uma feature. Além disso, não entender o problema pode causar um over-engineering, que é quando criamos soluções mais complicadas do que o necessário para resolver o problema, e com isso temos mais complexidade pra lidar.

E qual o sofrimento?

Ao propor soluções que não funcionam, caimos no mesmo sofrimento do item #1: mais estresse, mais complicação e mais tempo oportuno perdido.

Como melhorar?

• Aplicar o Princípio da falseabilidade em tecnologia: como tomar decisões mais assertivas
• Sempre racionalizar a partir dos princípios fundamentais/básicos da situação. Referência: Reasoning from first principles
• Cuidado com o Over engineering — É muito simples tornar as coisas complicadas, e muito complicado tornar as coisas simples.
• Cuidado com o hype based development — Pode ser que uma tecnologia famosa não atenda suas necessidades.
• Não ter receio de fazer perguntas: The Truth about Being the “Stupidest” in the Room | Simon Sinek

#3 — Falta de documentação e clareza no código

Escrever uma boa documentação para processos aumenta muito a autonomia do time, pois ao invés de perguntar algo para uma pessoa, podemos simplesmente pegar na base de conhecimento e seguir a vida.

E qual o sofrimento?

Se somos a única pessoa na equipe que detém um determinado conhecimento, é mais estressante nos ausentarmos (férias, folgas…), pois a equipe será deixada sem referências pra continuar o trabalho adequadamente.

E como melhorar?

• Eu tento sempre seguir a filosofia de ser o mais substituível possível no meu trabalho. Eu sei que isso assusta, mas o efeito disso é extremamente positivo. Ao se fazer substituível, não preciso gastar meus dias apagando incêndios ou fazendo tarefas que poderiam ser automatizadas ou resolvidas com uma boa documentação.
• Posso passar meus dias trabalhando em soluções eficientes, melhorando a saúde da equipe em geral, me aprimorando tecnicamente e muito mais. Em outras palavras quando somos substituíveis, diversas portas se abrem.

Referência:

• [PyBR2021] A importância da documentação no trabalho distribuído — Vinicius Mendes
• [PyBR2021] Desafios do Home Office — Equilíbrio entre vida pessoal e trabalho — Thiago Ferreira

Conclusão

Muitas vezes a área de tecnologia se mistura com outras áreas da ciência e filosofia e parte da ideia que eu quis passar hoje vem do estoicismo, que nos diz que muito do nosso sofrimento é autoimposto, ou seja, nós mesmos causamos nossos problemas em certos aspectos.

Com isso, eu tentei abordar essa filosofia dentro da tecnologia de uma forma prática, deixando vários exemplos e recomendações de como contorná-los.

É importante lembrar que muitas vezes os problemas dentro de uma equipe de tecnologia afetam não só o indivíduo que faz uma determinada ação, mas todas as outras pessoas envolvidas. Por isso, é importantíssimo levar todos esses pontos pra discussão com o time pra que possam ser feitos acordos & podermos trabalhar com paz e tranquilidade no dia a dia.

Como sempre, dúvidas, sugestões & críticas são muito bem vindas nos comentários 👇