Salve pessoal! Esse será o primeiro post em que irei, brevemente, lançar um "podcast" sobre lá no YouTube! A ideia é prover um contexto por escrito para deixar registrado e disponível para aquele que, como eu, não são fãs de ficar assistindo vídeos ou podcasts direto 😎️.

Antes de irmos para o post preciso deixar algo claro: Tudo que está escrito aqui é baseado na minha própria experiência como desenvolvedor, arquiteto e gerente na área de desenvolvimento, eu não sou e nem pretendo ser um psicólogo ou expert nessa área!

Mantendo a sanidade no mundo de Tecnologia

Não é novidade para ninguém que o universo de TI é uma loucura. São bugs explodindo, caminhão esperando nota fiscal pra sair, Injection na Sprint chegando à direita e esquerda e aquela constante demanda de descobrir (e conseguir usar) o que quer que seja a novidade daquele mês/trimestre/ano - não é a toa que burnouts sejam tão comuns no nosso universo.

Para complementar com a pressão do dia-a-dia também é comum em alguns casos sentirmos uma desconexão do trabalho do dia-a-dia e o impacto que chega a um usuário. Em pessoas focadas no backend isso é praticamente de praxe - são sprints a fio desenvolvendo alguma grande feature que irá entregar dados para vários clients ou vai permitir que vários outros sistemas se conectem com o nosso e no final é normal os "louros" irem para o frontend ou o mobile. Mas mesmo assim, nem tudo são flores para o frontend também, pois...

Ainda existe uma cultura de "proteger" desenvolvedores de feedback de clientes! Muitas vezes isso é feito com boas intenções em mente como "O cliente sempre quer demais" ou "O usuário nem olhou o tutorial" - como se o desenvolvedor não tivesse a capacidade de filtrar e extrair informações mesmo de feedback negativos - e no fim isso faz com que fiquemos cada vez mais desconectados da realidade do usuário e eventualmente fiquemos desmotivados e sem entender o porquê nosso trabalho é tão valioso!

Para a cereja no bolo da catástrofe temos também nós mesmos e nossa própria cobrança. Sempre olhamos para o colega, um YouTuber ou um post lá no StackOverflow e pensamos: "Como esse cara/guria é foda. Eu não sei metade disso..." - e nessas horas esquecemos uma realidade muito importante de programar em pleno século XXI: quase toda informação está a um Google/DuckDuckGo de distância, portanto memorizar os métodos e classes de uma biblioteca é opcional!. Na hora do pull request ou da review a gente esquece que aquele sênior pode ter passado por um processo enorme de ficar pesquisando e consolidando informações antes de chegar naquele código totalmente clean e 100% testável! (Não se espelhe em desenvolvedores que não testam o próprio código 😂️)

As ferramentas para manter a Sanidade!

A introdução já foi um wall of text falando sobre os problemas e como chegamos neles, portanto é hora de falarmos um pouco de como podemos usar algumas coisas para combatermos tudo isso! Cada sub-seção aqui vai abordar uma das "ferramentas" na caixa da sanidade.

Entenda que ninguém é perfeito

Primeiro passo que eu costumo fazer comigo mesmo é me lembrar que perfeição é impossível. Todos nós temos pontos fortes e fracos, através do nosso auto-conhecimento podemos entender e nos planejar com isso em mente!

Por exemplo eu sei que sou fraquíssimo quando a questão é UI. Mesmo com um UX Designer me cantando tudo que precisa ser feito para a interface ficar bonita eu sei que eu sou travado ali e respeito essa limitação. Vou até onde eu posso, me esforço até onde dá sem me frustrar e garanto que tenho algum colega que pode me ajudar na hora de deixar uma interface de fato tinindo.

Por outro lado eu sei que sou muito bom em arquitetura. Com pouca informação consigo propor vários cenários com Pros e Contras e ajudar alguém a chegar numa decisão sobre como arquitetar sua solução. Pensando nisso eu sei onde posso melhor ajudar as pessoas e sei que vou compensar, de uma maneira ou de outra, aquele ponto fraco.

Parece clichê falar. Mas a chave aqui é se conhecer, entender seus limites e se respeitar - você nunca terá todas as respostas para todas as perguntas e está tudo bem, você não precisa disso pois dificilmente estará completamente isolado, em uma ilha deserta e sem internet, resolvendo problemas de TI.

Saiba pesquisar por informação

Sabendo (e aceitando) que não temos todas as respostas vem uma skill crítica em minha opinião: Saber buscar nas fontes de conhecimento coletivo os dados para a pergunta que você não sabe responder.

Existem várias fontes de informação que você tem à sua disposição! A pergunta que você quer responder provavelmente já foi (pelo menos parcialmente) respondida por alguém na Internet!.

No mínimo você tem acesso a essas fontes - saber como utilizar elas a seu favor vai ser um baita diferencial para dar aquele "unblocker" sem precisa se frustar tanto!

• DuckDuckGo e Google: Saber pesquisar direto em qualquer search engine significa ter o poder da Internet inteira em sua mão
• StackOverflow: Provavelmente vai precisar peneirar um pouco (e torcer para ter uma resposta atualizada), mas costuma ser útil para pelo menos ter ideias alternativas!
• GitHub: Se você está utilizando uma biblioteca open source famosa, muito provavelmente, outras pessoas também estão! Então por qual motivo não poderíamos dar uma olhada em como os outros estão usando essas bibliotecas?
• Repositórios da sua Empresa: Se é uma biblioteca interna ela está em algum repositório interno. Seja um GitHub, BitBucket, GitLab ou GitTea da vida: você também pode (e deve!) pesquisar no códigos dos outros nesses repositórios! Novamente, nem que seja para ter uma pequena nova ideia ou tentar algo levemente diferente!
• YouTube: Existem muitos criadores de conteúdo para vários frameworks e linguagens de programação! É por aqui que normalmente descubro novas bibliotecas ou padrões para utilizar em meus projetos individuais.

Confie na sua equipe

No dia-a-dia normalmente esquecemos que outra fonte de informação e apoio muito importante são nossos próprios colegas. Se mantivermos e cultivarmos um mindset de crescimento será muito mais prático consultar seus colegas para ter ajuda. Inclusive ao fazer isso estamos ajudando a consolidar o conhecimento das pessoas pois ensinar e explicar faz parte do próprio processo de aprendizado!

São aqui que podemos utilizar várias metodologias:

• Pair Programming: Fazer uma sessão em que das pessoas colaboram para escrever código em um único lugar (um digitando e outro falando)
• Programming Dojo: Similar ao pair programming porém com mais pessoas - uma vai bater o código e as outras falam, simplesmente revezando quem está batendo o código
• Code Reviews: A maneira assíncrona e normalmente mais prática para algumas organizações. Simplesmente chame seus colegas para fazer review do seu pull request antes que fazer o merge. Mesmo que seu código esteja compilando e passando todos os testes existem nuances que apenas pessoas vão pegar!

Celebre pequenas vitórias

Para balancear com a enchurrada debugs lembre-se de celebrar e valorizar pequenas vitórias! Coisas "bobas" como passar por um code review só com aprovações, aumentar a performance de uma rotina por milisegundos, aumentar a cobertura de teste de uma área do sistema mesmo que por 5 linhas ou tirar um code smell antes que ele gere um bug são coisas a se celebrar!

Além disso lembre-se também de celebrar os pequenos avanços enquanto estiver estudando! Normalmente levamos várias semanas e meses para entender completamente uma nova tecnologia, portanto não custa celebrar aquela primeira prova de conceito que fez o Kafka funcionar ou um cache no Redis ser consultado pela sua api!

Tenha válvulas de escape

Talvez o mais crítico de tudo aqui seja este ponto: Você apenas trabalha uma parte do seu dia - o resto do seu dia é seu e você deve aproveitar e respeitar isso.

Sempre que possível faça seus hobbies nesse tempo livre. Se não tiver um hobby busque um! Seja ele qual for (auxiliar em open source, escrever num blog, pedalar, correr, malhar, artes marciais, jogar video-game) esse hobby será sua válvula de escape para as horas de stress que acontecem no trabalho.

Não tem segredo - ninguém é de ferro! Algo que eu costumo muito fazer é sair para uma corrida ou um pedal mais pesado quando estou frustrado ou precisando arejar os pensamentos depois de um dia ou uma semana puxada.

E a melhor parte? Normalmente durante esses momentos que acabamos tendo as melhores ideias! Quando livramos a mente de toda a pressão e passamos a fazer algo mais "relaxante" (mesmo que canse mais o corpo kkk) conseguimos ativar nossos processos criativos e muitas vezes vemos possíveis saídas para os problemas que estavam nos assombrando durante o horário de trabalho.

É por isso que vemos essa quantidade de pessoas de TI acabando, por exemplo, indo para Maratonas, Triathlon, pedais de longa distância ou gravando vídeos aleatórios!

As Vantagens de estar bem

Só para sintetizar e encerrar o post: estar bem é o segredo para o sucesso no longo prazo. Ao estar "bem" você vai ter um processo criativo melhor (e não se engane - programar requer criatividade mesmo que não seja uma arte!), você irá se frustar menos quando errar aqui ou ali, ter uma jornada de aprendizado mais estável e sustentável e conseguirá recarregar as baterias constantemente para conseguir participar daquela reunião mais chata da semana.