Estou olhando um pedaço de código. Este pode ser o pior código que já vi. Para atualizar apenas um registro no banco de dados, ele recupera todos os registros da coleção e então envia uma solicitação de atualização para todos os registros do banco de dados, mesmo aqueles que não precisam ser atualizados. Existe uma função map que simplesmente retorna o valor passado para ela. Existem testes condicionais para variáveis com aparentemente o mesmo valor, apenas nomeadas em estilos diferentes (firstName и first_name). Para cada UPDATE, o código envia uma mensagem para uma fila diferente, que é tratada por uma função sem servidor diferente, mas que faz todo o trabalho para uma coleção diferente no mesmo banco de dados. Eu mencionei que essa função sem servidor vem de uma “arquitetura orientada a serviços” baseada em nuvem contendo mais de 100 funções no ambiente?
Como foi possível fazer isso? Cubro meu rosto e soluço visivelmente em meio à risada. Meus colegas perguntam o que aconteceu e eu reconto em cores Piores acessos de BulkDataImporter.js 2018. Todos acenam para mim com simpatia e concordam: como eles puderam fazer isso conosco?
Negatividade: uma ferramenta emocional em uma cultura de programadores
A negatividade desempenha um papel importante na programação. Está incorporado em nossa cultura e é usado para compartilhar o que aprendemos (“você não você vai acreditar, como era aquele código!”), para expressar simpatia através da frustração (“Deus, POR QUE fazer isso?”), para se exibir (“Eu nunca assim não fizemos isso”), colocar a culpa em outra pessoa (“falhamos por causa do código dele, que é impossível de manter”), ou, como é habitual nas organizações mais “tóxicas”, controlar os outros através de um sentimento de vergonha (“No que você estava pensando?”? Correto).
A negatividade é muito importante para os programadores porque é uma forma muito eficaz de transmitir valor. Certa vez, participei de um acampamento de programação, e a prática padrão para incutir uma cultura industrial nos alunos era fornecer generosamente memes, histórias e vídeos, os mais populares dos quais exploravam . É bom poder usar ferramentas emocionais para identificar o Bom, o Mau, o Feio, Não Faça Isso, Nunca. É necessário preparar os recém-chegados para o fato de que provavelmente serão mal compreendidos por colegas distantes da TI. Que seus amigos começarão a vender-lhes ideias de aplicativos milionárias. Que eles terão que vagar por intermináveis labirintos de código desatualizado com um bando de minotauros ao virar da esquina.
Quando aprendemos a programar, nossa compreensão da profundidade da “experiência de programação” se baseia na observação das reações emocionais de outras pessoas. Isso pode ser visto claramente nas postagens em , onde muitos programadores novatos se encontram. Muitos humorísticos são, de uma forma ou de outra, coloridos com diferentes matizes de negatividade: decepção, pessimismo, indignação, condescendência e outros. E se isso não lhe parece suficiente, leia os comentários.
Percebi que à medida que os programadores ganham experiência, eles se tornam cada vez mais negativos. Os iniciantes, sem saber das dificuldades que os aguardam, começam com entusiasmo e vontade de acreditar que a causa dessas dificuldades é simplesmente a falta de experiência e conhecimento; e eventualmente eles serão confrontados com a realidade das coisas.
O tempo passa, eles ganham experiência e se tornam capazes de distinguir códigos bons de códigos ruins. E quando esse momento chega, os jovens programadores sentem a frustração de trabalhar com códigos obviamente ruins. E se trabalham em equipe (remotamente ou pessoalmente), muitas vezes adotam os hábitos emocionais de colegas mais experientes. Isto muitas vezes leva a um aumento da negatividade, porque os jovens podem agora falar cuidadosamente sobre o código e dividi-lo em bom e mau, mostrando assim que estão “por dentro”. Isto reforça ainda mais o negativo: por desilusão, é fácil conviver com colegas e tornar-se parte de um grupo; criticar o Bad Code aumenta o seu estatuto e profissionalismo aos olhos dos outros: .
Aumentar a negatividade não é necessariamente uma coisa ruim. As discussões sobre programação, entre outras coisas, são extremamente focadas na qualidade do código escrito. O que o código define completamente a função que ele pretende realizar (além de hardware, rede, etc.), por isso é importante poder expressar sua opinião sobre esse código. Quase todas as discussões se resumem a saber se o código é bom o suficiente e a condenar os próprios manifestos do código ruim em termos cuja conotação emocional caracteriza a qualidade do código:
- "Há muitas inconsistências lógicas neste módulo, é um bom candidato para otimização significativa de desempenho."
- “Este módulo é muito ruim, precisamos refatorá-lo.”
- “Este módulo não faz sentido, precisa ser reescrito.”
- “Este módulo é uma merda, precisa ser corrigido.”
- “Este é um pedaço de memória RAM, não um módulo, não precisava ser escrito, o que diabos seu autor estava pensando.”
Aliás, é essa “liberação emocional” que faz os desenvolvedores chamarem o código de “sexy”, o que raramente é justo – a menos que você trabalhe no PornHub.
O problema é que as pessoas são criaturas estranhas, inquietas e emocionais, e a percepção e expressão de qualquer emoção nos muda: a princípio sutilmente, mas com o tempo, dramaticamente.
Uma ladeira escorregadia e problemática de negatividade
Há alguns anos, eu era líder de equipe informal e entrevistei um desenvolvedor. Gostávamos muito dele: ele era inteligente, fazia boas perguntas, entendia de tecnologia e se adaptava bem à nossa cultura. Fiquei particularmente impressionado com sua positividade e como ele parecia empreendedor. E eu o contratei.
Naquela época, eu já trabalhava na empresa há alguns anos e sentia que nossa cultura não era muito eficaz. Tentamos lançar o produto duas, três e mais algumas vezes antes de eu chegar, o que gerou grandes gastos com retrabalho, durante os quais não tínhamos nada para mostrar a não ser longas noites, prazos apertados e produtos que funcionavam. E embora ainda estivesse trabalhando duro, estava cético quanto ao último prazo que nos foi atribuído pela administração. E ele praguejou casualmente ao discutir alguns aspectos do código com meus colegas.
Portanto, não foi surpreendente – embora eu tenha ficado surpreso – que, algumas semanas depois, o mesmo novo desenvolvedor tenha dito as mesmas coisas negativas que eu (incluindo palavrões). Percebi que ele se comportaria de maneira diferente em uma empresa diferente, com uma cultura diferente. Ele apenas se adaptou à cultura que eu criei. Fui dominado por um sentimento de culpa. Devido à minha experiência subjetiva, incuti pessimismo num recém-chegado que considerei completamente diferente. Mesmo que ele realmente não fosse assim e estivesse apenas fingindo que poderia se encaixar, eu forcei minha atitude de merda nele. E tudo o que é dito, mesmo em tom de brincadeira ou de passagem, tem o mau modo de se transformar naquilo que se acredita.
Maneiras negativas
Voltemos aos nossos ex-programadores novatos, que ganharam um pouco de sabedoria e experiência: eles se familiarizaram mais com a indústria da programação e entenderam que códigos ruins estão em toda parte, não podem ser evitados. Isso ocorre até nas empresas mais avançadas e focadas em qualidade (e deixe-me observar: aparentemente, a modernidade não protege contra códigos ruins).
Bom roteiro. Com o tempo, os desenvolvedores começam a aceitar que códigos ruins são uma realidade do software e que seu trabalho é melhorá-los. E se o código incorreto não puder ser evitado, não há sentido em fazer barulho por causa disso. Eles seguem o caminho do Zen, concentrando-se na resolução de problemas ou tarefas que os enfrentam. Eles aprendem como medir e comunicar com precisão a qualidade do software aos proprietários de empresas, escrever estimativas bem fundamentadas com base em seus anos de experiência e, por fim, receber recompensas generosas por seu valor incrível e contínuo para os negócios. Eles fazem seu trabalho tão bem que recebem US$ 10 milhões em bônus e se aposentam para fazer o que quiserem pelo resto da vida (por favor, não tome isso como garantido).
Outro cenário é o caminho das trevas. Em vez de aceitar o código ruim como uma inevitabilidade, os desenvolvedores assumem a responsabilidade de denunciar tudo de ruim no mundo da programação para que possam superá-lo. Eles se recusam a melhorar códigos ruins existentes por vários bons motivos: “as pessoas deveriam saber mais e não serem tão estúpidas”; “é desagradável”; “isto é mau para os negócios”; “isso prova o quanto sou inteligente”; “Se eu não lhe disser que código horrível é esse, toda a empresa cairá no oceano” e assim por diante.
Certamente incapazes de implementar as mudanças que desejam porque o negócio infelizmente precisa continuar a se desenvolver e não podem perder tempo se preocupando com a qualidade do código, essas pessoas ganham a reputação de reclamantes. Eles são mantidos por sua alta competência, mas são empurrados para as margens da empresa, onde não incomodarão muitas pessoas, mas ainda assim apoiarão a operação de sistemas críticos. Sem acesso a novas oportunidades de desenvolvimento, perdem competências e deixam de satisfazer as exigências da indústria. Sua negatividade se transforma em amargura e, como resultado, eles alimentam seus egos discutindo com estudantes de XNUMX anos sobre a jornada que sua velha tecnologia favorita percorreu e por que ainda é tão quente. Eles acabam se aposentando e vivendo a velhice xingando os pássaros.
A realidade provavelmente está em algum lugar entre esses dois extremos.
Algumas empresas têm sido extremamente bem sucedidas na criação de culturas extremamente negativas, insulares e obstinadas (como a Microsoft antes da sua ) - muitas vezes são empresas com produtos que se enquadram perfeitamente no mercado e com necessidade de crescer o mais rápido possível; ou empresas com uma hierarquia de comando e controle (Apple nos melhores anos de Jobs), onde todos fazem o que lhes mandam. No entanto, a investigação empresarial moderna (e o bom senso) sugere que o máximo de engenho, que conduz à inovação nas empresas, e à elevada produtividade dos indivíduos, requer baixos níveis de stress para apoiar o pensamento criativo e metódico contínuo. E é extremamente difícil fazer um trabalho criativo e baseado em discussões se você estiver constantemente preocupado com o que seus colegas terão a dizer sobre cada linha do seu código.
Negatividade é engenharia da cultura pop
Hoje, mais atenção é dada à atitude dos engenheiros do que nunca. Nas organizações de engenharia, a regra “". Cada vez mais anedotas e histórias aparecem no Twitter sobre pessoas que abandonaram esta profissão porque não podiam (não queriam) continuar a tolerar a hostilidade e a má vontade para com os estrangeiros. Até Linus Torvalds anos de hostilidade e críticas a outros desenvolvedores Linux - isso levou ao debate sobre a eficácia desta abordagem.
Alguns ainda defendem o direito de Linus de ser muito crítico – aqueles que deveriam saber muito sobre as vantagens e desvantagens da “negatividade tóxica”. Sim, a civilidade é extremamente importante (até fundamental), mas se somarmos as razões pelas quais muitos de nós permitimos que a expressão de opiniões negativas se transforme em "toxicidade", essas razões parecem paternalistas ou adolescentes: "eles merecem porque são idiotas ", "ele deve ter certeza de que eles não farão isso de novo", "se eles não tivessem feito isso, ele não teria que gritar com eles" e assim por diante. Um exemplo do impacto que as reações emocionais de um líder têm em uma comunidade de programação é o acrônimo da comunidade Ruby, MINASWAN - "Matz é legal, então nós somos legais".
Percebi que muitos defensores fervorosos da abordagem "matar um tolo" geralmente se preocupam muito com a qualidade e a exatidão do código, identificando-se com seu trabalho. Infelizmente, muitas vezes confundem dureza com rigidez. A desvantagem desta posição decorre do desejo humano simples, mas improdutivo, de se sentir superior aos outros. As pessoas que ficam imersas nesse desejo ficam presas no caminho das trevas.
O mundo da programação está crescendo rapidamente e ultrapassando os limites de seu contêiner - o mundo da não-programação (ou o mundo da programação é um contêiner para o mundo da não-programação? Boa pergunta).
À medida que a nossa indústria se expande a um ritmo cada vez maior e a programação se torna mais acessível, a distância entre os “técnicos” e os “normais” está a diminuir rapidamente. O mundo da programação está cada vez mais exposto às interações interpessoais de pessoas que cresceram na cultura nerd isolada do início do boom tecnológico, e serão elas que moldarão o novo mundo da programação. E independentemente de quaisquer argumentos sociais ou geracionais, a eficiência em nome do capitalismo aparecerá na cultura empresarial e nas práticas de contratação: as melhores empresas simplesmente não contratarão ninguém que não consiga interagir de forma neutra com os outros, muito menos ter boas relações.
O que aprendi sobre negatividade
Se você permitir que muita negatividade controle sua mente e suas interações com as pessoas, transformando-se em toxicidade, isso será perigoso para as equipes de produto e caro para os negócios. Já vi (e ouvi falar) inúmeros projetos que desmoronaram e foram completamente reconstruídos com grandes custos porque um desenvolvedor confiável tinha rancor da tecnologia, outro desenvolvedor ou até mesmo um único arquivo escolhido para representar a qualidade de toda a base de código.
A negatividade também desmoraliza e destrói relacionamentos. Jamais esquecerei como um colega me repreendeu por colocar CSS no arquivo errado, isso me incomodou e não me permitiu organizar meus pensamentos por vários dias. E no futuro, dificilmente permitirei que tal pessoa esteja perto de uma de minhas equipes (mas quem sabe, as pessoas mudam).
Finalmente, o negativo .
Acho que é assim que deveria ser uma master class sobre sorrisos.
Claro, este não é um argumento a favor de sorrir de felicidade, inserir dez bilhões de emoticons em cada pull request ou ir a uma master class sobre sorrisos (não, bem, se é isso que você quer, então não há problema). A negatividade é uma parte extremamente importante da programação (e da vida humana), sinalizando qualidade, permitindo expressar sentimentos e ter pena dos outros humanos. A negatividade indica discernimento e prudência, a profundidade do problema. Muitas vezes percebo que um desenvolvedor atingiu um novo nível quando começa a expressar descrença naquilo que antes era tímido e inseguro. As pessoas demonstram razoabilidade e confiança em suas opiniões. Você não pode descartar a expressão de negatividade, isso seria orwelliano.
Porém, a negatividade precisa ser dosada e equilibrada com outras qualidades humanas importantes: empatia, paciência, compreensão e humor. Você sempre pode dizer a uma pessoa que ela estragou tudo sem gritar ou xingar. Não subestime esta abordagem: se alguém lhe disser, sem qualquer emoção, que você estragou seriamente, é realmente assustador.
Naquela época, há vários anos, o CEO falou comigo. Discutimos o status atual do projeto e ele perguntou como eu estava me sentindo. Respondi que estava tudo bem, o projeto estava andando, estávamos trabalhando devagar, talvez tivesse perdido alguma coisa e precisasse ser reconsiderado. Ele disse que me ouviu compartilhar pensamentos mais pessimistas com colegas de escritório e que outros também notaram isso. Ele explicou que, se eu tivesse dúvidas, poderia expressá-las plenamente à administração, mas não “eliminá-las”. Como engenheiro-chefe, preciso estar ciente de como minhas palavras afetam os outros, porque tenho muita influência, mesmo que não perceba. E ele me contou tudo isso com muita gentileza e, finalmente, disse que se eu realmente me sentisse assim, provavelmente precisaria pensar no que quero para mim e para minha carreira. Foi uma conversa incrivelmente gentil, do tipo "pegue ou saia da cadeira". Agradeci a ele pela informação sobre como minha mudança de atitude ao longo de seis meses estava afetando outras pessoas despercebidas por mim.
Foi um exemplo de gestão notável e eficaz e do poder de uma abordagem suave. Percebi que parecia ter total fé na empresa e na sua capacidade de atingir os seus objetivos, mas na realidade falava e comunicava com os outros de uma forma completamente diferente. Também percebi que, mesmo que me sentisse cético em relação ao projeto em que estava trabalhando, não deveria demonstrar meus sentimentos aos meus colegas e espalhar o pessimismo como um contágio, reduzindo nossas chances de sucesso. Em vez disso, eu poderia transmitir agressivamente a situação real à minha gestão. E se eu sentisse que eles não estavam me ouvindo, poderia expressar minha discordância saindo da empresa.
Recebi uma nova oportunidade quando assumi o cargo de chefe de avaliação de pessoal. Como ex-engenheiro-chefe, tenho muito cuidado ao expressar minhas opiniões sobre nosso código legado (em constante melhoria). Para aprovar uma mudança, você precisa imaginar a situação atual, mas você não chegará a lugar nenhum se se afundar em gemidos, ataques ou coisas do gênero. Em última análise, estou aqui para concluir uma tarefa e não devo reclamar do código para entendê-lo, avaliá-lo ou corrigi-lo.
Na verdade, quanto mais controlo minha reação emocional ao código, mais entendo o que ele pode se tornar e menos confusão sinto. Quando me expressei com moderação (“deve haver espaço para melhorias adicionais aqui”), eu estava fazendo a mim mesmo e aos outros felizes e não levando a situação muito a sério. Percebi que poderia estimular e reduzir a negatividade nos outros sendo perfeitamente (irritantemente?) razoável (“você está certo, esse código é muito ruim, mas vamos melhorá-lo”). Fico feliz em ver até onde posso ir no caminho Zen.
Essencialmente, estou constantemente aprendendo e reaprendendo uma lição importante: a vida é muito curta para ficarmos constantemente com raiva e com dor.
Fonte: habr.com