4 coisas que todo programador deve entender sobre trabalhar com programação

Introdução

Não é de hoje que a profissão de programador vem crescendo constantemente e são muitas as perspectivas de futuro, seja em salários mais altos ou quantidades de vagas. Consequentemente, a área vem sendo uma das mais visadas para troca de carreira, ao mesmo tempo que apresenta uma baixa taxa de desistência, e muitas pessoas acabam buscando um espaço no mercado de trabalho de programação com muitas expectativas profissionais.

Independentemente se o candidato em questão é um veterano de outra área que está vindo atuar como programador, ou um iniciante que está buscando sua primeira vaga de emprego, ou até um desenvolvedor nível pleno ou sênior que já esteja nesse mercado há um bom tempo, a profissão de desenvolvedor de software, embora extremamente gratificante (e bem delicinha haha), não é um tipo de mundo mágico diferente de outros setores e, apesar de todas as características positivas que a profissão tem, ainda existem alguns pontos ou situações negativas que cada profissional pode acabar tendo que presenciar e vivenciar.

Por isso, gostaria de trazer uma série de relatos, ensinamentos e experiências que gostaria que você tivesse em mente antes de entrar na área, ou, caso já esteja dentro dela, se frustrar menos sabendo que você não é a única pessoa que passa por isso.

Muitas vezes não é o mais certo, mas o que a equipe/chefe prefere

Sabemos que existem muitas maneiras de chegar a um mesmo resultado em algumas questões na nossa área. Seja uma linguagem ou framework A ou B, uma ferramenta de organização ou um trecho de código específico, não são raras as situações onde você pode ou tem de fazer escolhas entre 2 ou mais soluções possíveis para resolver um problema. Nessas situações, na maioria das vezes, você poderá encontrar vantagens e desvantagens caso adote determinada abordagem em detrimento de outra, ou também poderão existir algumas situações onde uma opção acabe se mostrando bem mais eficiente, como usar TypeScript ao invés de Vanilla Javascript em um projeto grande.

Em cenários como esses, que na verdade tendem a ser bem comuns no dia a dia de trabalho, geralmente nós, desenvolvedores, amantes de bons códigos e boas soluções, tendemos a escolher a opção que trará mais vantagem para aquela situação. Mas, ei, isso deveria ser óbvio, certo? Bom, nem tanto assim.

Desconsiderando os casos em que você trabalhe em um projeto sozinho, vão existir situações onde algumas decisões acordadas entre o time ou passadas pelo chefe claramente não são a maneira mais eficiente de lidar com aquela questão. Os motivos? Eles variam, mas inclua receio de substituir métodos antigos que funcionam por métodos novos, economia por parte da empresa, conforto de um membro com mais influência na equipe etc. Quaisquer que sejam as razões, saiba que casos assim costumam acontecer e que você nem sempre está no controle da aplicabilidade das melhores práticas. Pode ser frustante, eu sei, mas é a realidade.

Chefes ruins existem, mas eles não são uma constante

De uma maneira geral, existe um certo estigma em relação à imagem de um chefe em uma empresa. Muitas vezes, eles são representados como espécies de ditadores que exigem uma sequência de passos que deve ser executada pelos funcionários, reclamam da maneira como um trabalho foi feito e são carrancudos.

Bom, tenho uma boa e uma má notícia sobre isso. A má é que existem, sim, chefes ruins por aí, enquanto a boa é quase que o contrário disso. Eles existem, mas nem todos são assim. Na verdade, mais do que isso, a cultura de empresas de software hoje em dia tendem a tentar criar um ambiente mais confortável para os funcionários, pois os resultados em cenários como esse tendem a ser melhores, e a realidade é que uma gerência como essa é cada vez mais difícil.

Em minha experiência profissional, constantemente vi mais cenário como os últimos descritos, onde as companhias implementavam práticas como montar um cômodo com jogos para os horários livres, deixavam à escolha de cada membro do time optar pelo modelo de trabalho (se híbrido, remoto ou presencial) e coisas do tipo. Particulamente, nunca vivenciei diretamente um desses casos de chefes que agem de acordo como o estigma criado tende a fazer a gente pensar, mas já ouvi alguns relatos de alguns colegas de trabalho ou faculdade citando algumas situações do tipo.

"O nosso chefe constantemente reclamava da maneira como o código era implementado naquele intervalo de tempo. Parecia nunca estar bom o suficiente ou ter sido entregue rápido o suficiente. Foi uma experiência extremamente estressante trabalhar lá, e outros colegas de time diziam o mesmo. Não desejo algo assim para ninguém."

Um antigo colega de trabalho

De uma maneira geral, o que você deve ter em mente é que há, sim, a possibilidade de você acabar trabalhando com um chefe ruim, mas não deixe essa preocupação subir à cabeça e, se acontecer, avalie a situação de uma maneira profissional. Tente passar feedbacks, conversar a respeito e, se vir que a situação está estressante demais e você não vê cenários de mudanças, busque outras oportunidades com um time que trate você melhor e o faça se desenvolver profissionalmente.

Erros, das mais diversas naturezas, sempre podem acontecer, e tudo bem

É possível que algum desenvolvedor, em algum momento, já visou como meta de estudos ficar tão bom em uma tecnologia a ponto de resolver todos os problemas de uma empresa ou projeto com ela, de forma extremamente eficiente e sem gerar falhas. Bom, se você já teve ou tem esse ponto de vista, saiba que essa é uma visão admirável, mas que não necessariamente será realidade, em qualquer momento da sua vida de programador.

Acho importante falar sobre isso porque já observei no meu time de trabalho alguns membros terem uma espécie de síndrome do impostor ou crises de ansiedade por não conseguirem resolver uma task no tempo estabelecido por conta de algum bug ou até ter subido um código que gerou erro.

Antes de você passar por algo do tipo, saiba que, independente do seu nível de conhecimento, você não é completamente isento de errar ou deixar algum detalhe passar despercebido, levando a uma falha ou mal funcionamento do sistema em que está trabalhando. Se você é iniciante, entenda que essa cobrança é (ou, pelo menos, deveria ser) nivelada com a sua posição. Assim, espera-se que os gestores saibam que talvez nem tudo que você desenvolva tenha sido feito da melhor forma. Se você tem mais anos de experiência, tenha em mente que todo mundo comete erros. Já aconteceu com outras pessoas e pode acontecer com você também.

Além disso, temos de ser francos, existem algumas decisões, estratégias ou features de uma aplicação que já são fadadas a situações como essa. Seja por estar adentrando em uma área pouco explorada da computação ou por decisões empresariais que não investem nos melhores processos, pode ser que, em algum momento, essas escolhas caiam por terra e os eventuais bugs apareçam.

Não estou dizendo que você deve começar a desenvolver software de forma negligente, sem se preocupar com erros até que eles apareçam, mas só que entenda que, caso você os provoque em algum momento, é algo perfeitamente normal e não há motivos para se sentir inferior por isso.

Você tem que pelo menos dar os feedbacks, independente do resultado deles

Trabalhar como programador muitas vezes é ter de lidar com decisões que não são totalmente certas ou erradas. Além disso, é um trabalho que envolve interação com um time, onde o que uma pessoa fizer poderá afetar diretamente o que outra fez. Justamente por isso, é importante que, se você considera que alguma coisa não deveria ser feita de determinada forma, ou tem uma solução melhor, fale.

Isso não se limita somente a aspectos técnicos, mas também com comportamentos de outros membros da equipe. Às vezes, pode ser difícil expressar críticas ou apontar algo que não saiu como esperado, mas é justamente esse tipo de conversa que ajuda a equipe a crescer e melhorar. Existem momentos em que alguma pessoa agiu de determinada forma por nem ter se ligado nos resultados daquele comportamento, tudo que elas precisam é entender que não agiram bem, ou que agiram bem, se o feedback for positivo.

Existem muitos motivos pelos quais você pode não querer expor seu ponto de vista sobre algumas coisas. Ser tímido, ficar preocupado se a outra pessoa não aceitar bem uma crítica construtiva ou achar que seu feedback não valerá de nada. Bom, em todos esses cenários, meu conselho é o mesmo: apenas faça. Ser mais sociável é bom para toda equipe, então deixe a timidez de lado; sua relação com alguém que não é tão aberto a feedbacks dificilmente será pior do que passar por situações desagradáveis mais de uma vez; por fim, mesmo que suas observações não sejam levados a sério, você não perderá nada e ganhará em outros pontos, por ter tido a coragem de dá-las, estimulado sua sociabilidade e tirado isso de dentro de você.

De forma geral, eu sei que pode ser intimidador, especialmente se você é novo no time e não teve tanta experiência com situações do tipo antes, mas, lembre-se, você tem mais a ganhar do que a perder e uma equipe em que os membros não podem compartilhar o que pensam, não é uma boa equipe.

Conclusão

Basicamente, era isso que tinha a trazer para vocês hoje. Espero que essas experiências ajudem vocês a entenderem mais sobre algumas situações que acontecem ou poder vir a acontecer no seu dia a dia trabalhando com programação, e a maneira de lidar com elas. Todo mundo é mais produtivo quando seu ambiente de trabalho é confortável e devemos sempre zelar pelo nosso bem estar.

Se tiver alguma dúvida, podem deixar aqui nos comentários. Um forte abraço e bons códigos!