A Armadilha da Positividade Tóxica
Publicado em
Há algumas semanas um assunto viralizou no LinkedIn: Uma empresa qualquer teve a ideia de demitir um funcionário “de forma humanizada”, com uma cesta decorada e palavras de agradecimento.
Muitas pessoas criticaram e se colocaram contra essa atitude: No que isso ajuda em uma situação delicada de desligamento?
São críticas muito pertinentes.
É muito boa a ideia de uma gestão que trata bem os funcionários, superando a ideia hierarquizada e rígida (há muito ultrapassada), mas existe um limite de bom senso.
Depois de muitos anos trabalhando em seu sistema, construindo, consertando, melhorando, quebrando e remontando, você decide que o que realmente precisa é de uma reescrita completa. Afinal, o que poderia dar errado?
Se você já esteve envolvido em um projeto de reescrita completa, você sabe a resposta. Absolutamente tudo pode dar errado.
Porque você acha que quer Existem muitos motivos para se defender uma reescrita completa de sistema, mas o mais comum é a complexidade do software e o custo de manutenção.
Existem centenas de técnicas de entrevista, milhares de ferramentas, cada uma com um conhecimento necessário correspondente para trabalhar, incontáveis algoritmos “clássicos” e uma miríade de diferentes tipos de projetos para tentar avaliar um Desenvolvedor de Software. No entanto, não é fácil, nem formal ou matematicamente, separar um bom desenvolvedor de um mau. Porque?
Como sempre, não há uma resposta fácil para essa pergunta. A principal razão para isso é, talvez, que não sabemos o que um Desenvolvedor de Software faça de fato.
Com certeza há muito assunto e trabalho sobre estimativas em desenvolvimento de software. Esteja você em uma grande empresa, uma pequena agência ou o famoso projeto com o “exército de um homem só”, a ideia de que você possa prever quanto tempo levará para construir um sistema é amplamente difundida e adotada por todos.
Qualquer princípio de gestão ou cronograma de projeto tem isso como um mínimo para operar. Isso é útil para que você possa planejar com antecedência e lidar com os projetos em uma ordem sã, evitando armadilhas óbvias e erros de negócios.
Quando comecei minha carreira eu não entendia bem o conceito de me fixar a uma única linguagem/tecnologia. Sempre me pareceu errado fazer isso porque você precisa “usar a ferramenta certa para o trabalho” e " se não se parece com um prego, não use um martelo “, mas hoje acho que, como sempre, a realidade é um pouco mais complexa.
Eu ainda acredito que, como desenvolvedor, sou mais capaz e produtivo aprendendo cada vez mais linguagens/plataformas/ferramentas/frameworks/etc.