Raiva do código: programadores e negatividade

Eu estou olhando para um pedaço de código. Talvez este seja o pior código que eu já conheci. Para atualizar apenas um registro no banco de dados, ele extrai todos os registros da coleção e envia uma solicitação para atualizar cada registro no banco de dados, mesmo aqueles que não precisam ser atualizados. Existe uma função de mapa que simplesmente retorna o valor passado para ela. Existem verificações condicionais de variáveis ​​com obviamente o mesmo valor, apenas nomeadas em estilos diferentes ( firstName e first_name ). Para cada UPDATE, o código envia uma mensagem para outra fila, que é processada por outra função sem servidor, mas que faz todo o trabalho para outra coleção no mesmo banco de dados. Eu não mencionei que essa função sem servidor é de uma “arquitetura orientada a serviços” baseada em nuvem que contém mais de 100 funções no ambiente?

Como isso pode ser feito? Eu cubro meu rosto e soluço através da risada. Meus colegas perguntam o que aconteceu e eu reconto em cores os piores resultados do BulkDataImporter.js 2018 . Todo mundo acena com simpatia para mim e concorda: como eles poderiam fazer isso conosco?

Negativo: uma ferramenta emocional na cultura de programadores

A negatividade desempenha um papel importante na programação. Ele é incorporado à nossa cultura e é usado para compartilhar o que é reconhecido ("você não acredita na aparência desse código!"), Para expressar simpatia por meio de um transtorno ("Senhor, por que fazer isso?") à luz ("Eu nunca faria isso"), culpar os outros ("somos ostentados por causa de seu código que é impossível de acompanhar"), ou, como é habitual nas organizações mais "tóxicas", gerenciar os outros por vergonha ("O que você estava pensando? Correto").



A negatividade é tão importante para os programadores, porque é uma maneira muito eficaz de transmitir valor. Eu costumava estudar em um campo de programadores, e a prática padrão de vacinar os alunos com a cultura da guilda era fornecer generosamente memes, histórias e vídeos, dos quais os mais populares exploravam a tristeza dos programadores quando eram confundidos pelas pessoas . É bom quando você pode usar ferramentas emocionais para indicar o que é bom, ruim, horrível, nunca faça isso, nunca faça nada. É necessário preparar os iniciantes para o fato de que seus colegas, longe da TI, provavelmente os entenderão erroneamente. Que seus amigos vão começar a empurrar para eles idéias de aplicativos "em um milhão". O que eles têm para passear nos labirintos intermináveis ​​de códigos desatualizados com um monte de minotauros na esquina.

Quando começamos a aprender programação pela primeira vez, nossa compreensão da profundidade da “experiência de programação” se baseia em observações das reações emocionais de outras pessoas. Isso é claramente visto nas postagens no subwoofer ProgrammerHumor , no qual muitos programadores estão presentes. Muitos posts engraçados, em um grau ou outro, são coloridos com diferentes tonalidades negativas: decepção, pessimismo, ressentimento, indulgência e outros. E se isso não lhe parecer suficiente, leia os comentários.



Percebi que, com o acúmulo de experiência, os programadores estão se tornando cada vez mais negativos. Os iniciantes, desconhecendo as dificuldades que os aguardam, começam com entusiasmo e vontade de acreditar que a razão para essas dificuldades é simplesmente a falta de experiência e conhecimento; e no final enfrentarão o estado real das coisas.

O tempo passa, eles ganham experiência e conseguem distinguir código bom de ruim. E quando esse momento chegar, jovens programadores ficam chateados ao trabalhar com códigos aparentemente ruins. E se eles trabalham em equipe (remotamente ou pessoalmente), geralmente adotam os hábitos emocionais de colegas mais experientes. Freqüentemente, isso leva a um aumento do negativo, porque os jovens agora podem falar atenciosamente sobre o código e dividi-lo em ruim e bom, mostrando assim que estão "no assunto". Isso reforça ainda mais o negativo: por causa da decepção, é fácil encontrar-se com colegas e fazer parte de um grupo, a crítica ao Código Ruim eleva seu status e profissionalismo aos olhos dos outros: as pessoas que expressam uma opinião negativa são frequentemente percebidas como mais inteligentes e competentes .

Reforçar o negativo não é necessariamente uma coisa ruim. A discussão de programação, entre outras coisas, é extremamente focada na qualidade do código escrito. O que é o código determina completamente a função a que se destina (descartamos o equipamento, a rede etc.), portanto, é importante poder expressar sua opinião sobre esse código. Quase todas as discussões se resumem a se esse código é bom o suficiente e a condenar o próprio manifesto do código incorreto em expressões cuja coloração emocional caracteriza a qualidade do código:

• "Existem muitas inconsistências lógicas neste módulo, o que é um bom candidato para otimização significativa do desempenho".
• "Este módulo é muito ruim, precisamos refatorá-lo."
• "Este módulo não faz sentido, precisa ser reescrito."
• "Este módulo é péssimo, ele precisa ser corrigido."
• "Este é um pedaço de memória ram, não um módulo, não precisava ser escrito, o que diabos o autor estava pensando".

A propósito, é essa "liberação emocional" que força os desenvolvedores a chamar o código de "sexy", o que raramente é justo - a menos que você trabalhe no PornHub.

O problema é que as pessoas são estranhas, perturbadas, cheias de emoções da criação, e a percepção e expressão de quaisquer emoções nos mudam: a princípio é quase imperceptível, mas com o tempo - dramaticamente.

Trilha escorregadia inquieta da negatividade

Alguns anos atrás, eu era um líder informal da equipe e entrevistei um desenvolvedor. Nós realmente gostamos dele: ele era inteligente, fazia boas perguntas, era tecnicamente experiente e se encaixava perfeitamente em nossa cultura. Fiquei particularmente impressionado com a positividade dele e com o quão aventureiro ele parecia. E eu o contratei.

Naquela época, trabalhei na empresa por alguns anos e senti que a cultura adotada por nós não é muito eficaz. Tentamos lançar o produto duas vezes, três vezes e algumas vezes antes de eu chegar, o que levou a grandes despesas com retrabalho, durante as quais não tínhamos nada para mostrar, exceto por longas noites, prazos curtos e produtos de trabalho tipo. E, embora ainda trabalhasse duro, fiquei cético quanto ao último prazo que a administração nos atribuiu. E ele xingou casualmente ao discutir com meus colegas alguns aspectos do código.

Portanto, não havia nada de surpreendente no fato - embora eu estivesse surpreso - de que, algumas semanas depois, o mesmo novo desenvolvedor falasse da mesma maneira negativa que eu (incluindo palavrões). Percebi que ele teria agido de maneira diferente em uma empresa diferente, com uma cultura diferente. Ele só se ajustou à cultura que eu criei. A culpa me dominou. Por causa da minha experiência subjetiva, instilei o pessimismo no novato, que eu considerava completamente diferente. Mesmo que ele realmente não fosse assim e apenas tentasse mostrar que ele poderia se juntar ao time, eu impus minha atitude de merda a ele. E tudo o que foi dito, mesmo de brincadeira ou de passagem, tem uma maneira ruim de transformar aquilo em que se acredita.

Caminhos de negatividade

Vamos voltar aos nossos ex-programadores iniciantes que ganharam um pouco de sabedoria e experiência: eles conheceram o setor de programação mais de perto e entenderam que o código ruim está em todo lugar, não pode ser evitado. É encontrado mesmo nas empresas mais avançadas focadas na qualidade (e deixe-me observar: parece que a modernidade não nos salva de nenhum código incorreto).

Bom roteiro. Com o tempo, os desenvolvedores começam a tolerar o fato de que o código incorreto é a realidade do software e que seu trabalho é aprimorá-lo. E se o código incorreto não puder ser evitado, não faz sentido fazer barulho por causa disso. Eles embarcam no caminho do Zen, se concentram na solução de problemas ou tarefas que os confrontam. Eles aprendem como medir e fornecer com precisão a qualidade do software para os empresários, com base em seus muitos anos de experiência, escrevem estimativas perfeitamente justificadas e, por fim, recebem recompensas generosas por seu valor incrível e imutável para os negócios. Eles fazem seu trabalho tão bem que recebem bônus de US $ 10 milhões e se aposentam para fazer o que querem pelo resto de suas vidas (por favor, não aceite isso com fé).



Outro cenário é o caminho das trevas. Em vez de aceitar códigos ruins como inevitáveis, os desenvolvedores assumem a responsabilidade de anunciar todos os erros no mundo da programação para que possam derrotá-los. Eles se recusam a melhorar o código incorreto existente por muitas boas razões: “as pessoas devem saber mais e não ser tão estúpidas”; "É desagradável"; "Isso é ruim para os negócios"; "Prova o quão inteligente eu sou"; "Se eu não lhe disser que código é ruim, toda a empresa mergulhará no oceano" e assim por diante.

Certamente, não tendo a oportunidade de implementar as mudanças desejadas, porque, infelizmente, os negócios devem continuar a se desenvolver e não podem gastar tempo se preocupando com a qualidade do código, essas pessoas ganham a reputação de reclamantes. Eles são mantidos por alta competência, mas são levados para o quintal da empresa, onde não incomodarão muitos, mas ao mesmo tempo apoiarão a operação de sistemas críticos. Tendo perdido o acesso a novas oportunidades de desenvolvimento, eles perdem suas habilidades e deixam de atender aos requisitos da indústria. Sua negatividade se transforma em amargura feroz e, como resultado, eles divertem seu ego, discutindo com estudantes de vinte anos sobre o caminho seguido por sua amada tecnologia antiga e por que ela ainda é nítida. No final, eles se aposentam e vivem a velhice, xingando os pássaros.

Provavelmente, a realidade está em algum lugar no meio entre esses dois extremos.

Algumas empresas foram extremamente bem-sucedidas na criação de culturas extremamente negativas, isoladas e de força de vontade (como a Microsoft antes da década perdida ) - geralmente são empresas com produtos que combinam perfeitamente com o mercado e a necessidade de crescer o mais rápido possível; ou empresas com uma hierarquia de gerenciamento e controle (Apple nos melhores anos de Jobs), onde todos fazem o que mandam. No entanto, a pesquisa empresarial moderna (e o senso comum) sugere que, para obter o máximo de criatividade, levando à inovação da empresa e alta produtividade dos indivíduos, é necessário um baixo nível de estresse para manter o pensamento criativo e metódico contínuo. E é extremamente difícil fazer um trabalho criativo, que se baseia em discussões se você estiver constantemente preocupado com o que seus colegas terão a dizer sobre cada linha do seu código.

Negativo é a cultura pop de engenharia

Hoje, mais atenção é dada à atitude dos engenheiros do que nunca. Nas organizações de engenharia, a regra " No Ovuk " está se tornando cada vez mais popular. No Twitter, há cada vez mais piadas e histórias sobre pessoas que deixaram essa profissão porque não podiam (não queriam) continuar tolerando hostilidade e hostilidade em relação a pessoas de fora. Até Linus Torvalds pediu desculpas recentemente pelos anos de sua hostilidade e crítica a outros desenvolvedores de Linux - isso levou a uma discussão sobre a eficácia dessa abordagem.

Alguém ainda defende o direito de Linus de ser muito crítico - aqueles que precisam saber muito sobre as vantagens e desvantagens da "negatividade tóxica". Sim, a correção é extremamente importante (mesmo fundamental), mas se resumirmos os motivos pelos quais muitos de nós permitem que a expressão de opiniões negativas se transforme em “toxicidade”, esses motivos parecem paternalistas ou adolescentes: “eles merecem porque são idiotas”, “ele Devo ter certeza de que eles não repetirão "," se não tivessem feito isso, ele não teria que gritar com eles "e assim por diante. Um exemplo de como as reações emocionais do líder afetam a comunidade de programação é a abreviação MINASWAN na comunidade Ruby - "Matz é legal, então somos legais" (Matz [criador da linguagem] é bom, então somos bons).

Percebi que muitos defensores ardentes da abordagem "matar o tolo" costumam cuidar muito da qualidade e correção do código, identificando-se com seu trabalho. Infelizmente, muitas vezes confundem dureza com rigidez. A desvantagem dessa posição decorre de um desejo humano simples, mas improdutivo, de se sentir superior aos outros. As pessoas que estão imersas nesse desejo estão presas no caminho da escuridão.



O mundo da programação está crescendo rapidamente e limita os limites de seu contêiner - o mundo da não programação (ou esse é o mundo da programação de um contêiner para o mundo da não programação? Boa pergunta).

À medida que nossa indústria se expande a um ritmo crescente e a programação se torna mais acessível, a distância entre "técnicos" e "normal" está diminuindo rapidamente. O mundo da programação está cada vez mais exposto à comunicação interpessoal entre pessoas que cresceram em uma cultura isolada de “nerds” do início do boom tecnológico, e são elas que formarão o novo mundo da programação. E, independentemente de quaisquer argumentos em relação à esfera social ou às gerações, a eficiência em nome do capitalismo se manifestará na cultura das empresas e nas abordagens de contratação: as melhores empresas simplesmente não contratam aqueles que não conseguem interagir de maneira neutra, sem mencionar boas relações.

O que eu aprendi sobre o negativo

Se você permitir que um excesso de negatividade controle sua mente e a comunicação com as pessoas, transformando-se em "toxicidade", isso é perigoso para as equipes de produtos e caro para os negócios. Eu vi uma infinidade de projetos (e ouvi falar disso) que se desfizeram e foram completamente refeitos a um alto custo, porque um dos desenvolvedores de confiança aguçou a tecnologia, outro desenvolvedor ou mesmo o único arquivo selecionado para representar a qualidade de toda a base de código .

A negatividade também desmoraliza e destrói relacionamentos. Nunca esquecerei como um colega me repreendeu por colocar CSS no arquivo errado, isso me chateou e me impediu de reunir meus pensamentos por vários dias. E, no futuro, é improvável que eu permita que essa pessoa esteja perto de uma das minhas equipes (no entanto, quem sabe, as pessoas estão mudando).

Finalmente, a negatividade literalmente prejudica sua saúde .


Parece-me que uma aula de mestre em sorrisos deveria ser assim.

Obviamente, este não é um argumento a favor de ser feliz, inserir dez bilhões de smileys em cada solicitação pull ou ir para uma master class com sorrisos (não, bem, se é isso que você quer, então não há dúvida). A negatividade é uma parte extremamente importante da programação (e da vida humana), sinalizando qualidade, permitindo expressar sentimentos e condolências às pessoas-irmãos. Evidência negativa de insight e razoabilidade, a profundidade do problema. Costumo notar que um desenvolvedor atingiu um novo nível quando começa a expressar desconfiança no que era tímido e inseguro. Com suas opiniões, as pessoas demonstram prudência e confiança. Não se pode rejeitar a expressão da negatividade, seria no estilo orwelliano.

No entanto, o negativo deve ser dosado e equilibrado com outras importantes qualidades humanas: empatia, paciência, compreensão e humor. Você sempre pode dizer a uma pessoa que ela estragou tudo sem gritar e xingar. Não subestime esta abordagem: se você estiver completamente sem emoção, eles dizem que você estragou seriamente, isso realmente assusta.

Naquela época, há vários anos, o CEO falou comigo. Discutimos a situação atual do projeto, então ele perguntou como me sinto. Respondi que estava tudo bem, o projeto estava em andamento, estávamos trabalhando lentamente, talvez eu tivesse perdido alguma coisa e precisasse ser revisada. Ele disse que me ouviu compartilhando considerações mais pessimistas com colegas do escritório e que outros também perceberam isso. Ele explicou que, se eu tiver dúvidas, posso expressá-las completamente à liderança, mas não para "abaixá-las". Como engenheiro líder, devo lembrar como minhas palavras afetam os outros, porque tenho grande influência, mesmo que não perceba. E tudo isso ele me disse muito gentilmente e, no final, disse que, se realmente sinto tais sentimentos, provavelmente preciso pensar no que quero para mim e para minha carreira. Foi uma conversa incrivelmente suave no estilo de "se recompor ou sair". Agradeci pela informação sobre como minha atitude, que mudou nos últimos seis meses, afeta imperceptivelmente os outros por mim.

Este foi um exemplo de gerenciamento maravilhoso e eficaz e o poder de uma abordagem suave. Percebi que só me parecia acreditar totalmente na empresa e em sua capacidade de atingir objetivos, mas, na realidade, conversei e me comuniquei com os outros de uma maneira completamente diferente. Também percebi que, mesmo sentindo ceticismo em relação ao projeto em que estava trabalhando, não deveria ter demonstrado minha atitude em relação aos meus colegas e espalhado o pessimismo como uma infecção, reduzindo nossas chances de sucesso. Em vez disso, eu poderia transmitir agressivamente a situação real para minha liderança. E se eu sentisse que eles não estavam me ouvindo, eu poderia expressar minha discordância em deixar a empresa.

Tive uma nova oportunidade quando assumi o cargo de chefe de avaliação de pessoal. Como ex-engenheiro-chefe, monitorei cuidadosamente minha opinião sobre nosso código legado (em constante aprimoramento). Para aprovar a mudança, você precisa imaginar a situação atual, mas não terá nada se ficar atolado em gemidos, ataques ou algo assim. , , , , , .

, , , , . (« »), . , , (?) (« , , »). , .

, : , .