Quem nunca ouviu falar dos 7 pecados capitais? Muitos talvez tenham até decorado. Mas e para o programador, será que esses 7 pecados importam? Nesse artigo farei um paralelo entre os pecados e comportamentos para evitar na carreira de TI.
Avareza
Trata-se de quando a maior preocupação de alguém é a questão material. Nada mais importa, apenas dinheiro e bens.
Como isso se manifesta no caso do programador?
Começa pelo mercado. Não raro, um programador pode se ver tendo que escolher entre duas boas oportunidades de emprego, sendo uma delas melhor financeiramente que a outra. Qual escolher? O programador avarento não tem dúvidas, escolhe a melhor financeiramente.
Mas eu digo por experiência própria: isso não define qual é a melhor oportunidade.
Em momentos da vida, eu escolhi a oportunidade pior financeiramente e não me arrependo. Aprendi e evoluí demais, o que dificilmente ocorreria no outro caso.
Acho que o programador que sempre prioriza a parte material deixa de analisar N fatores que podem acrescentar muito a ele.
Vou sugerir algumas perguntas que podem te ajudar a abrir sua mente na hora de fazer uma escolha desse tipo:
Com quais tecnologias você trabalhará? É um sistema legado? Você terá autonomia para escolher novas tecnologias ou evoluir o produto? Você irá aprender coisas novas?
Com que tipo de mercado você trabalhará? Qual a complexidade do negócio e o quanto isso pode agregar pra você? Essa experiência vai pesar no seu currículo? Abrirá portas? Com quem você trabalhará? Qual o modelo de trabalho da empresa? E por aí vai…
Dinheiro sempre é bom. Mas não é tudo.
>>Leitura Recomendada:
Salário de programador: quais cargos mais bem pagos em 2019?
Gula
Excessos. É disso que gula trata.
O excesso tem a capacidade de transformar algo bom em algo ruim. Todos nós precisamos comer, é uma exigência nutricional para que nos mantenhamos vivos.
Mas se você é guloso e não impõe limites, isso pode acarretar problemas na sua saúde, causando desde indisposição até obesidade.
E quais os excessos na vida do programador? Podem ser muitos.
Pegue algo bom: design patterns. Quando usado em excesso, pode se tornar ruim, pois pode adicionar complexidade desnecessariamente a algo que atenderia muito bem à demanda de forma mais simples.
Por exemplo, pense numa situação onde, dependendo do valor de uma variável, você terá um comportamento ou outro no seu código.
O que poderia ser simplesmente um if, para o programador “guloso” vira um padrão Strategy, onde para cada comportamento, há uma classe concreta que implementa uma mesma interface.
“Ah, mas isso é uma boa prática, Raphael”.
Sim, é um padrão de projeto consolidado, valioso e extremamente útil. Mas lembre-se: a questão aqui é o excesso.
Utilize com critério. Pense: para criar um Strategy nesse caso, você terá que criar pelo menos 2 classes e 1 interface, configurá-la em algum injetor de dependência ou fornecê-la por uma Factory.
Como os benefícios desse padrão se manifestam? Ele é realmente necessário? Os comportamentos atuais são muito distintos? Qual a complexidade deles? Qual a probabilidade de surgirem novos comportamentos?
O uso de um padrão aqui não pioraria um pouco a performance? Se sim, qual a margem pra se diminuir performance aqui?
Uma maior complexidade nesse ponto do código poderia impactar a manutenção? No caso de um Strategy, a complexidade é menor.
Mas pense em um programador guloso que compulsivamente implementa padrões de projeto mais complexos que este, como um Decorator ou um Observer.
Pense nessas perguntas assim como alguém guloso pensaria antes de abocanhar um hambúrguer suculento: “Peraí, será que eu preciso mesmo disso? Será que estou com fome? ”. O hambúrguer é bom, mas será que você precisa?
>>Leitura Recomendada:
O que é Desenvolvedor full cycle?
Inveja
Ah, a inveja. Ela é um dos pecados capitais que mais frequentemente vemos por aí.
O programador invejoso torna o trabalho em equipe uma constante competição. Então, ao invés de existir um time que produz um software, há times de 1 programador competindo entre si pra produzir o melhor código em um software. O resultado tende a ser dos piores.
Isso acontece muito. Principalmente quando o nível de senioridade é alto. São os chamados “cobrões”, caras que sabem muito.
O ego tende a falar mais alto neles do que nos que estão iniciando. Mas como ninguém sabe de tudo, sempre há algo que o outro sabe mais que você. Nessa hora que a inveja toma conta e você tenta de alguma forma desmistificar o sujeito que OUSOU fazer isso.
Eu já vi programador editando código alheio apenas para sabotar o outro. Sim, acreditem, ele criou bugs propositalmente. Não era numa equipe de seniores, eram juniores.
Mas não duvido que em algum local do mundo já teve sênior fazendo algo do tipo.
Ambos são humanos. E a inveja é intrinsecamente humana. Nos resta agradecer aos sistemas de versionamento de código, que estão aí pra dificultar que atitudes como essa passem batidas.
A inveja faz parte de uma mentalidade de escassez. Sim, pois programadores invejosos preferem ter colegas de equipe que saibam menos do que ter alguém que agregue mais conhecimento à equipe como um todo.
Evite isso. Traga quem sabe mais que você pra junto e aprenda. Faça o mesmo com ele, compartilhe o que você sabe, agregue. Isso melhora a sinergia da equipe e produz melhores resultados.
>>Leitura Recomendada:
Lições que aprendi ao começar a programar em equipe
Ira
Ser programador não é fácil. A brecha para conflitos é bem grande pois o seu trabalho, por ser muito técnico, é de pouco conhecimento geral, apesar do impacto dele ser enorme.
E aí, quando você menos espera, se vê estourando com clientes e colegas de trabalho de outras áreas, que consideraram você e sua equipe os grandes vilões. E o pior: eles podem estar errados. Como lidar com isso?
Um ponto problemático é: programadores são técnicos, e caras técnicos nem sempre tem bem aprimorados aspectos interpessoais no seu perfil profissional. Aspectos interpessoais esses que, em dados momentos, são essenciais.
Exige-se jogo de cintura para lidar com pressão. E a pressão pode vir de todos os lados.
Um determinado problema em um software — desenvolvido por você — pode impactar uma equipe de suporte, de banco de dados, de projetos, etc etc etc.
Como lidar com isso? Dando vazão à ira? Não. Isso é o pior.
O conflito é o pior caminho, pois não resolverá as questões e levará a uma situação de rancor, pode apostar.
A probabilidade de outros não aguentarem mais olhar pra sua cara será enorme, mesmo que de cabeça fria. E vice versa. Mas talvez seja inevitável ter que lidar um com outro.
A verdade é que, numa situação de pressão, todos têm a sua dor. O quanto você tenta enxergar a dor do outro? Ouviu a versão dele? Entendeu o prejuízo que isso está causando a ele?
O impacto que um problema tem para alguém nem sempre é percebido por todos. Às vezes nos revoltamos com o cliente, mas o impacto de um erro no software para ele é gigantesco.
Você pode estar revoltado que alguém gritou com você, mas essa mesma pessoa pode ter ouvido um grito 10 vezes maior. Então, em muitos momentos, certas reações são compreensíveis.
Procurar entender isso é o primeiro passo para a ira não se tornar o carro chefe na discussão. E aí, em um estado emocional e equilibrado, você pode expor o seu lado, negociar, flexibilizar onde for necessário e focar na solução. Não queira vencer discussões, foque na solução.
>>Leitura Recomendada:
A importância da comunicação em Projetos de TI
Preguiça
Se o programador guloso é ansioso pra aplicar um padrão em tudo, o programador preguiçoso tem preguiça de escrever mais código mesmo quando é recomendado ou até necessário.
Isso acaba impedindo ou dificultando a evolução técnica de um software.
Já me peguei analisando um código com o seguinte comentário: “eu poderia fazer isso de forma muito melhor, mas me falta coragem”.
Preguiçosos também têm falta de coragem. Se você tem um código que poderia ser melhor do que é e há tempo para melhorá-lo, porquê não fazer isso?
Não deixe que a preguiça te impeça de fazer o melhor trabalho possível. E não confunda o melhor trabalho com o trabalho mais complexo. Alguns ajustes simples já podem melhorar consideravelmente o seu código.
Preguiça impacta também decisões de arquitetura.
Uma boa arquitetura deve ser muito bem pensada e levar em conta diversos aspectos, como requisitos funcionais e não funcionais, reuso, acoplamento, coesão, entre outros.
Ela se reflete também na escolha de padrões e tecnologias que devem ser escolhidos e aplicados com base em critérios sólidos, mapeando problemas e analisando vantagens e desvantagens de cada solução para o seu cenário específico.
O arquiteto preguiçoso não quer se preocupar com tudo isso. Dá trabalho. Então ele pensa no que é mais usado no mercado, o padrão mais bem falado, a modinha de mercado, a tecnologia da vez, a “bala de prata” e aplica na solução, sem esquentar muito a cabeça com todos esses fatores.
O resultado é um software que poderia ser muito melhor do que é e que poderia não ter alguns problemas que tem.
>>Leitura Recomendada:
Dicas para aprender programação e evoluir na carreira
Luxúria
Luxúria é um pecado relacionado ao sexo, à sensualidade e ao prazer. Como isso poderia se aplicar a um programador?
Existem programadores que erotizam seu código. Segura a risada, é sério. Para estes, programar vai além da resolução de problemas. Ele desenvolve o software para cultuar, namorar.
Para ele, o desenvolvimento de software é uma obra de arte e ele é o artista. Cada classe e método funcionam como músicos, mas é ele que toca a orquestra. Entendeu a erotização do código?
Mas qual o problema disso? É uma sensação tão boa se sentir orgulhoso de seu código. Sim, mas isso pode te desviar daquele que eu considero o objetivo principal de um programador: ser pragmático.
Pragmatismo é uma mentalidade, uma corrente de pensamento que prega que a validade de algo se dá pelo bom êxito. O programador pragmático se importa com o que funciona, com o que é eficaz e eficiente. Essa é a prioridade para ele.
Por que isso não combina com um programador mais narcisista, que preza pelo belo? Vamos pensar, o que normalmente é considerado belo? Algo complexo.
Dificilmente as pessoas se admiram e se encantam com algo simples. É cultural. Assim, o programador narcisista tenderá a construir um software mais complexo — muitas vezes desnecessariamente complexo — para resolver algo simples.
E o pior: não podemos dizer que quanto mais complexo um software, mais qualidade ele têm.
No mundo real, a tendência é que seja o contrário. Aí o narcisista entrega um sistema complexo e lindo, mas cheio de problemas. Não seria melhor ter sido pragmático?
>>Leitura Recomendada:
6 blogs de programação que todo desenvolvedor deve conhecer
Soberba
O soberbo é aquele arrogante que acha que sempre sabe mais que você. Em muitos casos, ele pode ser também o narcisista, pois adora ser reconhecido.
E aí ele faz um código rebuscado e uma solução complexa, mostra para os outros e espera a reação deles. Aparecem caras de interrogação, mas caras admiradas, olhinhos brilhantes.
Pois é o que dissemos: é complexo, então é belo. O fato de as pessoas não compreenderem tão facilmente o código dá um ar de superioridade ao autor.
Esse código é para poucos. Tão para poucos que dar manutenção ali vai ser difícil…
Se a inveja é a sua disposição negativa para com o outro, a soberba é a sua disposição positiva (até demais) de você sobre os outros.
Muitas vezes irrealista, pois você pode não ser tão bom quanto pensa. E ser soberbo pode ser pior ainda pra você, pois pode te levar à inércia já que você se considera em um nível muito elevado para buscar melhorar em algo.
E aí, quando você ver, aquele rapaz humilde, que saiu de baixo, está te superando e você nem percebeu.
Outro ponto é que soberbos nem sempre são admirados. Muitas vezes ocorre o oposto, pois muitas pessoas não toleram arrogância e combatem isso, sejam elas do mesmo nível técnico que você ou não.
A diferença é que se for alguém de um nível técnico equiparável ao seu, essa sua pretensa competência será questionada.
O ponto é: pessoas soberbas não costumam se dar bem com outras e assim, o trabalho em equipe fica comprometido.
Já o humilde sim, é admirado. Como pessoa ou como profissional. Se você for bom tecnicamente e humilde o suficiente pra reconhecer que sempre há onde melhorar, será admirado das duas formas.
>>Leitura Recomendada:
As principais fontes de informação de um programador
Conclusão
Nesse artigo procurei expor alguns pontos — com pitadas de humor — que acho importante que um programador se atente.
Note que a maioria deles sai um pouco do aspecto técnico e tem relação com aspectos interpessoais, de postura, personalidade e tato com outros.
Uma carreira profissional não se limita apenas a capacidade técnica. Não somos ilhas, trabalhamos quase sempre em equipe e lidamos muitas vezes com clientes.
Saber lidar e trazer essas pessoas pra junto de você ajuda a ser não só um programador melhor, mas acima de tudo um profissional melhor.
>>Leitura Recomendada:
Um guia para o programador iniciante
