Saúde mental em desenvolvimento de software

Photo by Santiago Lacarta on Unsplash

Ano passado eu fui a um evento sobre desenvolvimento de software, e em uma das trilhas havia uma palestra sobre saúde mental. Para mim, o tema se tornou uma área de interesse pessoal e profissional nos últimos anos, e fui assistir.

A apresentação era um relato de um desenvolvedor que passou por um burnout seguido por uma crise de depressão. Ouvir um relato como esse é sempre tocante, mas aquilo mexeu comigo porque eu conseguia ver amigos muito próximos que passaram ou estão passando por situações parecidas. Eu conseguia ver que aquilo poderia ter acontecido comigo em algum momento.

Temos falado muito sobre saúde mental ultimamente. O Brasil apareceu como o país mais ansioso do mundo em relatório publicado pela OMS em 2019, e tentamos entender como as dinâmicas de trabalho afetam nosso estado mental, e vice-versa.

Eu não sou a pessoa mais preparada para comentar sobre esses temas, mas eu sei o que faz um programador perder o sono a noite.

Por exemplo:

• Incertezas inerentes da atividade de desenvolvimento;
• Quanto tempo eu preciso para implementar essa funcionalidade?
• Quantos acessos esperamos nesse end-point?
• A performance será boa o suficiente?
• Qual a decisão correta de arquitetura considerando o futuro do produto?
• Será que essa atualização de dependência pode quebrar alguma coisa?
• Quanto tempo de downtime teremos nessa migração?
• Mudanças frequentes na organização e no produto;
• Atualizações em tecnologias;
• Interrupções excessivas.

Enfim, todas essas questões em uma organização que não compreende (ou não considera) como funciona o ciclo de desenvolvimento de um produto, frequentemente levam programadores ao esgotamento.

Entretanto, percebi que nós já sabemos o que fazer para mitigar muitas dessas ansiedades. Nós, como comunidade de desenvolvedores(as) de software, já estamos falando sobre isso há décadas. Muitas das práticas ágeis e do modelo lean tem como objetivo principal mitigar problemas relacionados à incerteza e permitir que lidemos melhor com mudanças, mas normalmente falamos sobre esses temas focando em produtividade.

Nesse texto pretendo fazer o exercício de revisitar algumas dessas ideias, mas do ponto de vista da saúde mental de quem está programando ou gerindo projetos. Eu acredito que melhorar nossa forma de trabalho para permitir que tenhamos uma vida mais saudável, presente e feliz é uma causa justa, assim como produzir mais e de forma mais efetiva.

Esse texto será dividido em três partes:

1. Revisitando fundamentos;
2. Reconsiderando organizações;
3. Reflexões sobre a relação com o trabalho.

PARTE 1) Revisitando fundamentos

Extreme Programming não é apenas sobre produtividade

Como Kent Beck em “Extreme Programming Explained: Embrace Change”, o surgimento do XP aconteceu quando ele fazia um trabalho de consultoria na Chrysler, que naquele momento estava com um time arrasado. Era uma equipe qualificada, mas com um projeto sem esperança. Seu trabalho inicialmente foi levantar a moral das pessoas e depois criar mecanismos para que o time de desenvolvimento se comunicasse melhor e entregasse de forma incremental.

A ideia central do XP é aceitar as condições de mudanças em que a atividade de desenvolver software está submetida, e propor boas práticas nesse cenário.

No XP, os resultados excepcionais são buscados celebrando e atendendo as necessidades humanas das pessoas envolvidas. As demandas dos usuários e clientes são importantes, mas as preocupações dos desenvolvedores também precisam ser ouvidas.

“XP is my attempt to reconcile humanity and productivity in my own practice of software development and to share that reconciliation.”, Kent Beck

Ao revisitar os valores do XP, isso já é percebido com clareza:

1. Comunicação;
2. Simplicidade;
3. Feedback;
4. Coragem;
5. Respeito.

Comunicação porque programadores(as) não trabalham de forma solitária. Estamos a todo momento fazendo acordos e precisamos nos comunicar de forma absolutamente efetiva para fazermos progresso na resolução do problema. Simplicidade porque precisamos aceitar que não temos de antemão todas as informações necessárias para construir uma solução robusta. Feedback porque precisamos construir uma melhor compreensão do problema a ser resolvido enquanto entregamos o software. Coragem porque os desenvolvedores muitas vezes precisam trazer notícias ruins e assumir decisões difíceis. Respeito porque somos todos humanos.

Todos esses valores se traduzem em práticas como implementação de testes automatizados, sistema de integração contínua e organização do trabalho em pequenas partes.

Aprender a lidar com situações de incerteza é fundamental. A falta de habilidade leva à situações de ansiedade, perda de confiança entre as relações e sentimento de injustiça por todas as partes.

Pessoas e meses não são intercambiáveis

“Pessoas e meses são intercambiáveis apenas quando uma tarefa pode ser divida entre muitos trabalhadores que não se comunicam entre si (…)”

Essa é uma citação do livro “O Mítico Homem-Mês” de Frederick Brooks Jr, escrito em 1975.

Todo desenvolvedor(a) já tem a percepção que adicionar mais pessoas na equipe não escala a produtividade de forma linear imediatamente. Cada pessoa nova é mais uma pessoa para se comunicar e garantir alinhamento (que significa mais trabalho). Por isso, quanto maior a empresa, mais efetivamente ela tem que se comunicar para ganhar velocidade, e também por isso cada pessoa que entra acaba mudando a dinâmica da empresa de alguma forma.

Eu fiz questão de mencionar esse conceito porque vejo muitos líderes e gestores tendo que lidar com pressões para aumentar o time com a expectativa irrealista de ganho de produtividade imediato. É uma expectativa irreal, que já foi compreendida a décadas, mas que pela falta de compreensão de algumas pessoas, ainda continua gerando estresse e ansiedade nas empresas.

PARTE 2) Reconsiderando organizações

Na primeira parte quis olhar especificamente para práticas de desenvolvimento e gestão de projetos de software, e como elas se relacionam com saúde mental. Na segunda parte, vamos pensar mais sobre a cultura organizacional em que os programadores estão inseridos.

Não precisa ser uma loucura

A primeira referência que eu trago é um livro escrito por David Heinemeier Hansson e Jason Fried, que se chama “It Doesn’t Have to Be Crazy At Work”. De forma resumida, eles se posicionam contra o que se tornou o senso comum no mundo de startups, que é a loucura no trabalho (longas jornadas, interrupções excessivas, falta de tempo para pensar, agendas superlotadas, e etc…).

Culturalmente acreditamos que estar exaustos é um tipo de medalha de honra no trabalho, mas a verdade é que ninguém pode dar o seu melhor nessas condições.

O livro contém uma boa quantidade de provocações para a forma como trabalhamos, e muita coisa se relaciona com saúde mental. Nesse texto vou mencionar apenas alguns tópicos que gosto muito:

• Criatividade não é produzida com força bruta. Todo dia precisamos pensar de forma criativa para resolver problemas de engenharia, mas temos que aceitar que muitas vezes o que falta para chegarmos em uma solução é simplesmente ir para casa (ou continuar em casa, caso vocês esteja em meio à uma pandemia). Nada como “dormir sobre um problema” para dar clareza sobre como resolvê-lo depois de muita ponderação.
• Proteja seu tempo, e das outras pessoas. Antes de interromper uma pessoa, saiba que o trabalho dela é tão importante quanto o seu. Lembrar disso vai fazer a gente reconsiderar o que merece uma ligação, uma mensagem, ou apenas um email.
• Sua empresa não deve ser uma família, ela deve ser uma apoiadora de famílias. Isso significa que a empresa não deve apenas permitir, mas também incentivar que seus colaboradores passem um tempo de qualidade com suas famílias.
• Seja claro no que merece excelência e o que pode ser suficientemente bom. Gerenciar expectativas na construção de produtos digitais é fundamental.

A ideia central do livro é de que as empresas não precisam ser uma loucura para obterem sucesso. Reconsidere os valores da sua organização caso você esteja se privando de sono e de tempo de qualidade com as pessoas que você ama.

Segurança psicológica

O Google People Operation (o RH do Google) realizou uma pesquisa em 2015 buscando encontrar as principais características dos times bem sucedidos da empresa. Eles queriam entender qual seria o conjunto específico de conhecimentos técnicos e perfis comportamentais que proporcionavam maior chance de dar certo.

O que eles descobriram foi que de longe a característica mais importante para uma equipe funcionar bem, seria quão seguro psicologicamente ela é, ou seja, quão seguro as pessoas se sentem para se colocarem em situações de vulnerabilidade e assumir riscos.

Lembre-se das reuniões que evitou fazer uma pergunta porque considerou boba, e pensou “vou pesquisar sobre isso depois, eu provavelmente já deveria saber”, ou os momentos que evitou pedir ajuda, pelos mesmos motivos.

Ter uma atmosfera em que as pessoas se sentem à vontade para assumir riscos e fazer o trabalho que precisa ser feito é fundamental para o progresso de um time, e além disso, certamente é um ambiente que traz mais satisfação para as pessoas trabalharem.

PARTE 3) Reflexões sobre a relação com o trabalho

Além das esferas da organização, que envolvem a cultura da empresa e as práticas de desenvolvimento, é claro que muito da saúde mental dos programadores está relacionado com suas próprias crenças e pensamentos.

Pessoas diferentes vão lidar com os desafios do dia-a-dia de forma diferente. A intenção aqui não é falar como as pessoas devem trabalhar, mas reconhecer alguns pensamentos comuns que podem prejudicar o trabalho e a qualidade de vida de forma geral.

Estudar faz parte do trabalho

Muitas vezes, quando recebemos algum desafio novo, algo que nunca lidamos antes ou que envolve alguma tecnologia diferente (e isso acontece com frequência), sentimos que estamos errados. Sentimos que já deveríamos estar preparados, e que deveríamos saber responder tudo. Porém, esquecemos de um pequeno detalhe: é impossível estar preparado para tudo.

Conviver com o cenário de “aprender fazendo”, e aceitar que muitas vezes vamos precisar parar e estudar assuntos do início, testar e errar muitas vezes, para entregar tarefas e seguir em frente, é fundamental. Isso vai continuar acontecendo para o resto das nossas vidas.

Aprenda a reconhecer sua “síndrome do impostor”

A “síndrome do impostor” descreve o padrão de comportamento em que a pessoa não se sente capaz o suficiente (mesmo com muita evidência demonstrando o contrário). Ela minimiza suas realizações, e não se expõe por medo de se revelar uma fraude.

Isso pode se manifestar de várias formas. Por exemplo:

• “Não vou enviar nenhuma proposta de palestra para esse evento, porque não tenho nada para ensinar” (mesmo com muitos anos de experiência e com cases legais implementados no último ano);
• “Resolvi esse problema, mas tive sorte, qualquer um conseguiria” (mesmo quando é um problema que ninguém do time conseguiu lidar);
• “Não vou me colocar à disposição para liderar esse projeto, porque não estou preparado” (mesmo quando não existe outra pessoa mais preparada na empresa).

Da próxima vez que se ver em pensamentos parecidos, avalie se não é sua “síndrome do impostor” agindo, e busque evidências concretas para sustentar seus pensamentos.

Segure seu perfeccionismo

Nós desenvolvedores adoramos falar sobre boas práticas, estudar abordagens diferentes para lidar com problemas, testar tecnologias, etc. Isso é incrível, realmente empolgante.

O problema é quando usamos tudo isso para criticar o próprio trabalho, ou de outras pessoas, e ao invés de serem conhecimentos que nos ajudam a caminhar em frente, acabam se tornando coisas que nos congelam.

Seja gentil ao avaliar o seu trabalho, e das outras pessoas. Muitas vezes esquecemos das condições em que um código foi escrito (prazos apertados, recursos limitados, requisitos nebulosos, etc).

PARTE EXTRA) Faça sua higiene mental

Assim como escovamos os dentes todos os dias para evitar problemas maiores, devemos fazer nossa higiene mental para cuidar da nossa mente. Isso pode significar coisas diferentes para cada um, como: praticar ioga, meditação, exercitar-se, ter contato com alguma forma de arte, dentre outros.

O ponto é que muitas vezes não percebemos quando estamos chegando no esgotamento, então não espere que as coisas piorem para reservar um tempo para cuidar de si mesmo.

Conclusão

Existem causas de estresse e ansiedade que são inevitáveis. O próprio processo de aprendizado do dia-a-dia do programador é naturalmente frustrante, porque errar é frustrante. Nesses casos, precisamos aprender a lidar com essas situações da forma mais saudável possível, entendendo nossas emoções.

Porém, muitos desafios relacionados à mudanças e incertezas já foram endereçados, e portanto tratam-se de escolhas que organizações podem fazer para construir uma empresa mentalmente saudável aceitando essas condições. Beirar o burnout não é um requisito para o sucesso, não precisa ser assim.

Muitas vezes o burnout acontece por falta de compreensão e confiança das outras áreas sobre como o trabalho técnico funciona, e o programador se sente na obrigação de atender expectativas irrealistas. Quando as pessoas não aceitam o tempo que os projetos precisam, e começam a gerar pressão para forçar acordos absurdos, seu trabalho não é lidar com essa infantilidade, é apenas comunicar da forma mais clara possível.

Um ciclo saudável de entrega de software, leva à relações saudáveis no trabalho, que permite uma boa saúde mental dos desenvolvedores.