Estou mirando un anaco de código. Este pode ser o peor código que vin. Para actualizar só un rexistro na base de datos, recupera todos os rexistros da colección e, a continuación, envía unha solicitude de actualización a todos os rexistros da base de datos, incluso aqueles que non precisan ser actualizados. Hai unha función de mapa que simplemente devolve o valor que se lle pasou. Existen probas condicionais para variables con aparentemente o mesmo valor, só nomeadas en estilos diferentes (firstName и first_name). Para cada ACTUALIZACIÓN, o código envía unha mensaxe a unha cola diferente, que é xestionada por unha función sen servidor diferente, pero que fai todo o traballo para unha colección diferente na mesma base de datos. Mencionei que esta función sen servidor é dunha "arquitectura orientada a servizos" baseada na nube que contén máis de 100 funcións no contorno?
Como foi posible facer isto? Túpome a cara e salouco visiblemente pola miña risa. Os meus compañeiros preguntan o que pasou, e volvo a contar con cores Peores éxitos de BulkDataImporter.js 2018. Todos asenten con simpatía para min e están de acordo: como poderían facernos isto?
Negatividade: unha ferramenta emocional na cultura do programador
A negatividade xoga un papel importante na programación. Está incrustado na nosa cultura e úsase para compartir o que aprendimos (“ti non vas crer, como era ese código!”), para expresar simpatía a través da frustración (“Deus, POR QUE facelo?”), para presumir de si mesmo (“eu nunca así non o fixo”), botarlle a culpa a outra persoa (“fallamos polo seu código, que é imposible de manter”), ou, como é costume nas organizacións máis “tóxicas”, controlar aos demais mediante un sensación de vergoña ("¿En que estabas pensando?"? Correcto").
A negatividade é tan importante para os programadores porque é unha forma moi eficaz de transmitir valor. Unha vez asistín a un campamento de programación, e a práctica estándar de inculcar unha cultura da industria nos estudantes era proporcionar xenerosamente memes, historias e vídeos, o máis popular dos cales se explotaba. . É bo poder utilizar ferramentas emocionais para identificar o bo, o malo, o feo, non o fagas, nunca. É necesario preparar aos recén chegados para o feito de que probablemente sexan incomprendidos por compañeiros que están lonxe das TIC. Que os seus amigos comezarán a venderlles ideas de aplicacións de millóns de dólares. Que terán que pasear por interminables labirintos de código desfasado cunha chea de minotauros á volta da esquina.
Cando aprendemos por primeira vez a programar, a nosa comprensión da profundidade da "experiencia de programación" baséase na observación das reaccións emocionais doutras persoas. Isto pódese ver claramente nas publicacións en , onde saen moitos programadores novatos. Moitos humorísticos están, nun ou outro grao, coloreados con diferentes matices de negatividade: decepción, pesimismo, indignación, condescendencia e outros. E se isto non che parece suficiente, le os comentarios.
Notei que a medida que os programadores gañan experiencia, vólvense cada vez máis negativos. Os principiantes, inconscientes das dificultades que lles esperan, comezan con entusiasmo e vontade de crer que a causa destas dificultades é simplemente a falta de experiencia e coñecemento; e, finalmente, enfrontaranse á realidade das cousas.
Pasa o tempo, gañan experiencia e son capaces de distinguir o código bo do malo. E cando chega ese momento, os programadores novos senten a frustración de traballar cun código obviamente malo. E se traballan en equipo (a distancia ou persoalmente), adoitan adoptar os hábitos emocionais dos compañeiros máis experimentados. Isto adoita levar a un aumento da negatividade, porque os mozos agora poden falar reflexivamente sobre o código e dividilo en malo e bo, mostrando así que están "en coñecemento". Isto reforza aínda máis o negativo: por decepción, é fácil levarse ben cos compañeiros e formar parte dun grupo; criticar Bad Code aumenta o seu estatus e profesionalidade ante os demais: .
Aumentar a negatividade non é necesariamente algo malo. As discusións sobre programación, entre outras cousas, están moi centradas na calidade do código escrito. O que é o código define completamente a función que se pretende facer (hardware, redes, etc. aparte), polo que é importante poder expresar a túa opinión sobre ese código. Case todas as discusións redúcense a saber se o código é o suficientemente bo e a condenar os mesmos manifestos do código malo en termos cuxa connotación emocional caracteriza a calidade do código:
- "Hai moitas inconsistencias lóxicas neste módulo, é un bo candidato para unha optimización significativa do rendemento".
- "Este módulo é bastante malo, necesitamos refactorizalo".
- "Este módulo non ten sentido, hai que reescribirlo".
- "Este módulo é unha merda, hai que parchear".
- "Este é un anaco de ram, non un módulo, non necesitaba estar escrito en absoluto, que diaños estaba pensando o seu autor".
Por certo, é este "lanzamento emocional" o que fai que os desenvolvedores chamen ao código "sexy", que raramente é xusto, a non ser que traballes en PornHub.
O problema é que as persoas son criaturas estrañas, inquietas, emocionais, e a percepción e expresión de calquera emoción cámbianos: ao principio de forma sutil, pero co paso do tempo, de forma espectacular.
Unha pendente esvaradía con problemas de negatividade
Hai uns anos, fun xefe de equipo informal e entrevistei a un programador. Gustounos moito: era intelixente, facía boas preguntas, era un experto en tecnoloxía e encaixaba ben coa nosa cultura. Impresionoume especialmente a súa positividade e o emprendedor que parecía. E contrateino.
Daquela levaba un par de anos traballando na empresa e sentía que a nosa cultura non era moi efectiva. Tentamos lanzar o produto dúas, tres veces e un par de veces máis antes de que eu chegara, o que provocou grandes gastos de reelaboración, durante os cales non tiñamos nada que mostrar, excepto noites longas, prazos axustados e produtos que funcionaron. E aínda que seguía traballando duro, eu era escéptico sobre o último prazo que nos asignou a dirección. E xurou casualmente ao discutir algúns aspectos do código cos meus compañeiros.
Entón, non foi sorprendente, aínda que me sorprendeu, que unhas semanas despois, ese mesmo novo desenvolvedor dixese as mesmas cousas negativas que eu fixen (incluídos insultos). Decateime de que se comportaría de forma diferente nunha empresa diferente cunha cultura diferente. El só se adaptou á cultura que eu creei. Eu estaba superado cun sentimento de culpa. Debido á miña experiencia subxectiva, inculquei o pesimismo nun recén chegado ao que percibía como completamente diferente. Aínda que realmente non era así e só estaba facendo unha aparencia para demostrar que podía encaixar, forcínlle a miña actitude de merda. E todo o dito, aínda de broma ou de paso, ten a mala maneira de converterse no que se cre.
Vías negativas
Volvamos aos nosos antigos programadores novatos, que gañaron un pouco de sabedoría e experiencia: familiarizáronse máis coa industria da programación e entenden que o código malo está en todas partes, non se pode evitar. Dáse mesmo nas empresas máis avanzadas centradas na calidade (e permítanme notar: ao parecer, a modernidade non protexe contra o código malo).
Bo guión. Co paso do tempo, os desenvolvedores comezan a aceptar que o código malo é unha realidade do software e que o seu traballo é melloralo. E que se non se pode evitar un código malo, entón non ten sentido facer ruído. Eles toman o camiño do Zen, centrándose en resolver problemas ou tarefas que lles enfrontan. Aprenden a medir e comunicar con precisión a calidade do software aos propietarios de empresas, a escribir estimacións ben fundamentadas baseadas nos seus anos de experiencia e, finalmente, reciben xenerosas recompensas polo seu incrible e continuo valor para a empresa. Fan tan ben o seu traballo que cobran 10 millóns de dólares en bonos e retíranse para facer o que queiran durante o resto das súas vidas (por favor, non o dean por feito).
Outro escenario é o camiño da escuridade. En lugar de aceptar o código malo como algo inevitable, os desenvolvedores encárganse de chamar todo o malo no mundo da programación para poder superalo. Néganse a mellorar o código mal existente por moitas boas razóns: "a xente debería saber máis e non ser tan estúpido"; "é desagradable"; "isto é malo para os negocios"; “isto demostra o intelixente que son”; "Se non che digo o pésimo código que é este, toda a empresa caerá ao océano", etc.
Seguramente incapaces de implementar os cambios que queren porque, lamentablemente, o negocio debe seguir desenvolvéndose e non pode dedicar tempo a preocuparse pola calidade do código, estas persoas gañan reputación de denunciantes. Mantéñense pola súa alta competencia, pero son empuxados ás marxes da empresa, onde non molestarán a moita xente, pero aínda así apoiarán o funcionamento de sistemas críticos. Sen acceso a novas oportunidades de desenvolvemento, perden habilidades e deixan de satisfacer as demandas da industria. A súa negatividade convértese en amargura e, como resultado, alimentan o seu ego discutindo con estudantes de vinte anos sobre a viaxe que fixo a súa antiga tecnoloxía favorita e por que aínda está tan quente. Acaban xubilándose e vivindo a súa vellez insultando aos paxaros.
A realidade probablemente estea nalgún lugar entre estes dous extremos.
Algunhas empresas tiveron un gran éxito na creación de culturas extremadamente negativas, insulares e de vontade forte (como Microsoft antes da súa ) - moitas veces son empresas con produtos que se adaptan perfectamente ao mercado e a necesidade de crecer o máis rápido posible; ou empresas cunha xerarquía de mando e control (Apple nos mellores anos de Jobs), onde cada quen fai o que lle manda. Non obstante, a investigación empresarial moderna (e o sentido común) suxire que o máximo enxeño, que leva á innovación nas empresas e á alta produtividade nos individuos, require baixos niveis de estrés para apoiar o pensamento creativo e metódico continuo. E é moi difícil facer un traballo creativo baseado en discusións se estás constantemente preocupado polo que os teus colegas terán que dicir sobre cada liña do teu código.
A negatividade é a enxeñería da cultura pop
Hoxe en día préstase máis atención á actitude dos enxeñeiros que nunca. Nas organizacións de enxeñaría, a regra "". Cada vez aparecen máis anécdotas e historias en Twitter sobre persoas que deixaron esta profesión porque non podían (non seguirían) aguantando a hostilidade e a mala vontade cara aos de fóra. Incluso Linus Torvalds anos de hostilidade e críticas cara a outros desenvolvedores de Linux - isto levou a debater sobre a eficacia deste enfoque.
Algúns aínda defenden o dereito de Linus a ser moi crítico: aqueles que deberían saber moito sobre as vantaxes e desvantaxes da "negatividade tóxica". Si, o civismo é sumamente importante (incluso fundamental), pero se resumimos as razóns polas que moitos permitimos que a expresión de opinións negativas se converta en "toxicidade", estas razóns parecen paternalistas ou adolescentes: "mérecenno porque son idiotas". ", "debe estar seguro de que non o farán de novo", "se non o fixeran, non tería que berrarlles", etc. Un exemplo do impacto que teñen as reaccións emocionais dun líder nunha comunidade de programación é o acrónimo MINASWAN da comunidade Ruby: "Matz é agradable, así que somos agradables".
Notei que moitos defensores ardentes do enfoque de "matar a un parvo" adoitan preocuparse moito pola calidade e corrección do código, identificándose co seu traballo. Desafortunadamente, moitas veces confunden dureza con rixidez. A desvantaxe desta posición deriva do simple desexo humano, pero improdutivo, de sentirse superior aos demais. As persoas que se sumergen neste desexo quedan atrapadas no camiño da escuridade.
O mundo da programación está a crecer rapidamente e vai contra os límites do seu contedor: o mundo da non programación (ou é o mundo da programación un contedor para o mundo da non programación? Boa pregunta).
A medida que a nosa industria se expande a un ritmo cada vez maior e a programación faise máis accesible, a distancia entre os "tecnolóxicos" e os "normais" está pechando rapidamente. O mundo da programación está cada vez máis exposto ás interaccións interpersoais de persoas que creceron na cultura nerd illada do primeiro boom tecnolóxico, e son eles os que darán forma ao novo mundo da programación. E independentemente de calquera argumento social ou xeracional, a eficiencia en nome do capitalismo aparecerá na cultura da empresa e nas prácticas de contratación: as mellores empresas simplemente non contratarán a ninguén que non poida interactuar neutralmente cos demais, e moito menos ter boas relacións.
O que aprendín sobre a negatividade
Se permites que demasiada negatividade controle a túa mente e as interaccións coas persoas, converténdose en toxicidade, entón é perigoso para os equipos de produtos e caro para as empresas. Vin (e escoitei falar de) incontables proxectos que se desmoronaron e foron completamente reconstruídos cun gran gasto porque un desenvolvedor de confianza tiña rencor contra a tecnoloxía, outro desenvolvedor ou mesmo un único ficheiro elixido para representar a calidade de toda a base de código.
A negatividade tamén desmoraliza e destrúe as relacións. Nunca esquecerei como un compañeiro me reprochou por poñer CSS no ficheiro equivocado, molestoume e non me permitiu recoller os meus pensamentos durante varios días. E no futuro, é pouco probable que permita que esa persoa estea preto dun dos meus equipos (pero quen sabe, a xente cambia).
Finalmente, o negativo .
Creo que así debería ser unha clase maxistral sobre sorrisos.
Por suposto, este non é un argumento a favor de transmitir felicidade, inserir dez mil millóns de emoticonas en cada solicitude de atracción ou ir a unha clase maxistral sobre sorrisos (non, ben, se iso é o que queres, non hai problema). A negatividade é unha parte extremadamente importante da programación (e da vida humana), sinalando a calidade, permitindo expresar sentimentos e compadecerse cos seus compañeiros. A negatividade indica perspicacia e prudencia, a profundidade do problema. Moitas veces noto que un programador alcanzou un novo nivel cando comeza a expresar a incredulidade no que antes era tímido e inseguro. As persoas demostran razoabilidade e confianza coas súas opinións. Non podes descartar a expresión de negatividade, esa sería orwelliana.
Porén, a negatividade debe ser dosificada e equilibrada con outras importantes calidades humanas: empatía, paciencia, comprensión e humor. Sempre se lle pode dicir a unha persoa que se estropeou sen berrar nin xurar. Non subestimes este enfoque: se alguén che di sen ningunha emoción que te despistaches seriamente, dá moito medo.
Esa vez, hai varios anos, o director xeral falou comigo. Discutimos o estado actual do proxecto, entón preguntou como me sentía. Eu contesteille que todo estaba ben, o proxecto ía avanzando, traballabamos aos poucos, quizais algo me faltaba e había que repensalo. Dixo que me escoitara compartir pensamentos máis pesimistas cos compañeiros da oficina, e que outros tamén se decataran diso. Explicou que se tivese dúbidas, podería expresalas plenamente á dirección, pero non "quitalas". Como enxeñeiro principal, teño que ter en conta como as miñas palabras afectan aos demais porque teño moita influencia aínda que non me dea conta. E díxome todo isto moi amablemente, e finalmente dixo que, se realmente me sentía así, probablemente teño que pensar no que quero para min e para a miña carreira. Foi unha conversación incriblemente amable, para conseguir ou saír do seu asento. Agradecínlle a información sobre como o meu cambio de actitude ao longo de seis meses estaba afectando aos demais sen que eu me decatara.
Foi un exemplo de xestión notable e eficaz e do poder dun enfoque suave. Decateime de que só parecía ter total fe na empresa e na súa capacidade para acadar os seus obxectivos, pero en realidade falei e comuniqueime cos demais dun xeito completamente diferente. Tamén me decatei de que aínda que me sentía escéptico sobre o proxecto no que estaba a traballar, non debería mostrar os meus sentimentos aos meus compañeiros e estender o pesimismo como un contaxio, reducindo as nosas posibilidades de éxito. Pola contra, podería transmitir agresivamente a situación real á miña dirección. E se eu sentía que non me estaban escoitando, podería expresar o meu desacordo deixando a empresa.
Recibín unha nova oportunidade cando asumín o posto de xefe de avaliación de persoal. Como antigo enxeñeiro xefe, teño moito coidado ao expresar as miñas opinións sobre o noso código legado (en constante mellora). Para aprobar un cambio, cómpre imaxinar a situación actual, pero non chegará a ningún lado se se revolca en xemidos, ataques ou similares. En definitiva, estou aquí para completar unha tarefa e non debería queixarme do código para entendelo, avalialo ou solucionalo.
De feito, canto máis controlo a miña reacción emocional ante o código, máis entendo en que podería chegar a ser e menos confusión sinto. Cando me expresei con moderación («aquí debe haber marxe para mellorar máis»), facíame feliz a min e aos demais e non tomaba a situación demasiado en serio. Decateime de que podía estimular e reducir a negatividade dos demais sendo perfectamente (molesto?) razoable (“tes razón, este código é bastante malo, pero mellorarémolo”). Alégrome de ver ata onde podo chegar no camiño Zen.
Esencialmente, estou aprendendo e reaprendiendo constantemente unha lección importante: a vida é demasiado curta para estar constantemente enfadada e con dor.
Fonte: www.habr.com