Do que a tecnologia ri e porque isso importa
Olá!
Por incrível que pareça, esse post foi inspirado por um meme.
O perfil do profissional de tecnologia deixou de ser o estereótipo de nerd que popula o imaginário popular já faz algum tempo. Eu já vi pessoa desenvolvedora ciclista, esotérica, acadêmica, atleta amador de jiu-jitsu, ex-jogador de futebol vendedor de gelo… enfim, a lista é imensa.
Mas tem uma coisa que eu percebo que é uma constante em todas comunidades relacionadas a área que participo (seja de alguma tecnologia ou em um grupo de pessoas com já trabalhei ): um tipo de humor depreciativo da profissão com alguns temas recorrentes: o desprezo pelo “outro” (ou seja, qualquer pessoa de fora da área) por algumas atitudes e uma espécie de pedido de ajuda para os abusos que o profissional de tecnologia tem que se submeter algumas vezes.
Aqui a premissa é: se do que uma sociedade ri diz muito sobre ela (teoria da superioridade, mais especificamente), a próxima pergunta é: do que os profissionais de tecnologia riem?
Bom, esse post visa fazer a ponte entre a tecnologia e de quem se ri, ou seja, estou falando com você, aquele que é de fora do mundo da escovação de bits. Eu espero que com texto você entenda melhor a cabeça de um profissional de tecnologia, e, caso tenha algumas dessas atitudes, consiga transmutar o ódio que a sua equipe de tecnologia sente por você em amor. Não se engane, se você faz o que as piadas dizem, a equipe está pistola com você sim.
Se você é um profissional de tecnologia, já peço desculpas por antecipação, porque eu vou cometer o pecado mortal de explicar piadas… internas, o que é ainda pior.
Para o trabalho de um time de pessoas desenvolvedoras fluir bem, no imaginário popular dos integrantes as seguintes coisas tem que ocorrer: o demandante tem que saber exatamente o que se quer, não pode dar pitaco na solução técnica e obviamente, não deve colocar um prazo. Se for uma pessoa desenvolvedora preocupada com a qualidade do próprio trabalho, nesse cenário ideal deve haver espaços para escrita de testes de unidade. Além disso, é desejável que o trabalho seja extremamente previsível e sem a necessidade de horas extras. Ou retrabalho. Além disso, o demandante não deve ousar pedir para explicar o contexto do sistema para algum… leigo ou até mesmo uma pessoa desenvolve menos experiente. Afinal, que nojo ter que explicar coisa para junior. #contémironia
Essa descrição soou como o mundo ideal para você? Bom, reveja suas atitudes, talvez você não saiba trabalhar em equipe.
Soou absurdo e a pessoa que deseja isso lhe pareceu egoísta? Vem comigo que é com você que eu quero falar.
Vamos começar então, com a dita piada, como eu recebi pelo WhatsApp, peço desculpas por não citar o autor, dado que… muita coisa na internet não tem dono de qualquer forma.
A piada começa com a seguinte pergunta: e se outras profissões fossem tratadas como a tecnologia é tratada?
O intuito é tentar explicar através do conhecimento acumulado da profissão, porque todas essas ideias abaixo soam absurdas.
(Eu falei que eu ia explicar a piada).
Começando com:
Desenvolvimento de sistemas é uma atividade do ramo mental. É um profissão que requer conhecimento especializado e prática. É tão especializado que até o funcionamento cerebral para a leitura de código é diferente de ler texto comum, matemática e lógica.
Para alguns é uma disciplina com regras, padrões e métodos definidos como uma espécie de Engenharia ou Ciência. Para outros é Arte, como uma espécie de “ofício” no qual cada software é feito de forma artesanal e o resultado é único. Se você me perguntar, eu acho que é um pouco dos dois.
Com isso, como todo o conhecimento (e prática) acumulada por um profissional em uma determinada ferramenta/linguagem ao longos de anos torna o trabalho de replicar um trabalho extremamente complexo, eu diria até que inútil, dado que o contexto de uma empresa não é nada parecido com o de outra… mesmo que sejam do mesmo ramo, imagina se forem de ramos diferentes?
Afinal, um sistema é feito para um contexto específico, com suas particularidades e restrições orçamentárias, conhecimento tecnológico e experiência da equipe envolvida.
Ou seja, a lição aqui é: 90% do “fazer” um sistema, não é replicável para outra empresa simplesmente porque se quer. Não dá. Se fosse assim, bastaria um certo banco laranja copiar o modelo de trabalho de uma certa startup de streaming de música sueca do logo verde que daria tudo certo no final. Eles se tornariam inovadores da noite pro dia, certo? Exemplo puramente fictício, ok? #sqn
Ou seja: pare de copiar os outros, não vai funcionar no seu contexto. O caminho para a grandeza tem um limite… E ele se torna do tamanho que o lugar onde você está copiando chegou. Porque não pensar mais alto e expandir esse limite sem plágio?
Experimente chegar no seu crush com os seguintes dizeres: Veja bem, você tem que me amar, eu sei que você é capaz disso.
Vai dar certo?
O ponto aqui é: Amor, assim como inovação, não se cobra, se cultiva (ou se conquista).
Deem uma olhada aqui no que existe de “ciência” sobre o assunto gestão da inovação. Isso é só a superfície, inclusive.
O engraçado é que boa parte das soluções inovadoras surgiram em ambientes com restrições diversas, mas, com abertura para a experimentação… O que parece ser até um pouco contra-intuitivo, não?
Minha crítica aqui cabe aos gestores preguiçosos: Não é porque você quer inovar que sua equipe de TI irá inovar sem o sistema de incentivos correto. Eu acredito na máxima econômica: Incentivos funcionam.
Não adianta pedir a equipe surgir com ideias, se todas as ideais novas são cooptadas por um gestor para aparecer para o diretor, se não existe segurança psicológica, se o aprendizado não é valorizado… Enfim, tem muita coisa que precisa ser incentivada do jeito correto para que a inovação floresça. Senão gera um efeito colateral indesejado, como o efeito cobra.
Está disposto a desembolsar altos salários para atrair talentos? Está disposto a ter o status quo questionado por essas pessoas? Está disposto a ver outras pessoas com autonomia, experimentando hipóteses, sem o seu controle?
Sem isso, impossível. Gestão comando e controle é incompatível com inovação. Ou seja: inovação não se cobra, se cultiva. O que a gestão tem que fazer é parar de atrapalhar.
O Fusca só chega a 400 km/h se for aqui. No mundo real, chegou somente a 330 Km/h.
Primeiramente, se as pessoas envolvidas (me recuso a chamar pessoas de recurso) estão sendo subaproveitadas, a responsabilidade de consertar isso é de quem? Da gestão. Logo, não é justo pressionar a equipe por entregas sendo que existem falhas da gestão. Sabe o que o excesso de pressão gera? Profissionais doentes.
Toxicidade a parte, acho que vale mencionar que, novamente, tecnologia é uma área com particularidades e a maioria das ferramentas possuem usos específicos. Em um exemplo técnico: se você precisa de performance, não use PHP ou NodeJs, use Golang. Existe ciência, feita com método e rigor que mostra isso. Agora se você quer uma sintaxe amigável, use Python. Se performance não é um problema e você precisa de uma tecnologia bastante difundida, vá de NodeJs. Tecnologia é ferramenta, vamos usá-la como tal.
Um outro exemplo: Se tudo que você possui é um martelo, todos os problemas são vistos como pregos. Se sua equipe não conhece agilidade, NextJs ou Quarkus, peça ajuda de fora ou treine essas pessoas, é injusto esperar que eles sem esse conhecimento consigam fazer o Fusca bater a velocidade de um carro de F1. Uma equipe especializada de engenharia talvez consiga… e isso com esforço direcionado e conhecimento especializado.
Ou seja: os atores envolvidos em um desenvolvimento possuem pontos fortes e fracos, entenda isso e aja de acordo. Se nem você — pessoa de “fora”, to falando de você — tem competência para fazer tudo, porque a equipe de tecnologia teria?
Essa aqui é tão fácil que é possível encontrar a mesma ideias em múltiplas áreas do conhecimento diferentes. Novamente, a importância da multidisciplinaridade ❤️.
Vamos a alguns exemplos:
A microeconomia possui a lei dos rendimentos decrescentes, que, simplificando, diz que há um certo limite para o aumento da produção de algum bem, mesmo que você adicione mais trabalhadores, não vai adiantar nada.
A gestão de projetos tem o seguinte ditado: nove grávidas não geram 1 bebê em um mês.
A ciência da computação com a Lei de Amdahl coloca um limite na capacidade de processamento paralelo e ganho de performance, mesmo com aumentando da quantidade de processadores envolvidos.
No clássico livro de engenharia de software Mythical Man-month de Fred Brooks popularizou a lei que leva seu sobrenome: Adicionar mais pessoas desenvolvedoras a um projeto de software atrasado o atrasa ainda mais (Lei de Brooks).
Ou seja, você pode ter dinheiro infinito, que mesmo assim não será possível entregar, mesmo com pressão infinita em cima dos envolvidos. E agora, Faria Lima?
Aqui é simplesmente uma questão de ética na hora de honrar o acordo comercial de desenvolvimento de um sistema. É melhor não ter o cliente do que ter um cliente desonesto.
Mas, assumindo que foi um erro na hora de estimar o escopo de um determinado software, eu digo que existem ferramentas para descobrir a melhor forma de se lidar com um determinado problema baseado em seu tipo, como o modelo Cynefin. Esse dispositivo nos ajuda a identificar que um software que se “revela” aos poucos conforme o desenvolvimento prossegue é um problema complexo. Para tal tipo de problema, metodologias como Scrum e Design Thinking são excelentes, afinal, foram feitas para esse cenário.
Em projetos de escopo variável, use métodos ágeis! É para isso que eles servem. E demita clientes desonestos, eles causam problemas demais.
As vezes é difícil explicar para quem não programa 8 horas seguidas em um dia que a mente também cansa. O excesso de horas trabalhadas está relacionado a pior qualidade do trabalho, doenças físicas e mentais e baixa produtividade (lei dos retornos decrescentes, novamente). Em alguns casos, simplesmente não adianta trabalhar mais, porque o resultado sairá ruim a ponto de não valer a pena o esforço adicional.
Isso é um problema tão comum na indústria de tecnologia que parece ser algo visto como trivial por alguns profissionais, inclusive, por alguns amigos meus. Eu gostaria de fazer um apelo aqui: Normalizem folgas para os profissionais de tecnologia após entrega de trabalhos relevantes e difíceis ou após viradas de noite (ambientes que isso é comum geralmente é um sinal de um lugar ruim de se trabalhar).
Aqui vale mencionar um problema que eu vejo que pode se tornar um problema para a indústria: Caso o profissional esteja esgotado de um dia intenso de codificação, você acha mesmo que ele terá energia para estudar nos horários livres? É muito importante que o profissional continue estudando e se mantenha atualizado, porém, com altas cargas de trabalho, isso não irá acontecer. Novamente, pensemos soluções para que o processo de se manter atualizado não seja tão extenuante, com o ônus somente em cima do profissional, mesmo que ele seja competente e faça seu melhor durante o horário comercial.
Ou seja, fuja de lugares que o excesso de trabalho é regra, senão você entra em uma espiral de cansaço e sofrência que vão prejudicar sua empregabilidade. Trabalhar demais é a receita para ficar desempregado no futuro.
Até!
Você gostou do conteúdo e gostaria de fazer mentoria comigo? Clique aqui e descubra como.
