Estoy mirando un fragmento de código. Este puede ser el peor código que he visto en mi vida. Para actualizar solo un registro en la base de datos, recupera todos los registros de la colección y luego envía una solicitud de actualización a cada registro de la base de datos, incluso aquellos que no necesitan actualizarse. Hay una función de mapa que simplemente devuelve el valor que se le pasa. Hay pruebas condicionales para variables que aparentemente tienen el mismo valor, solo que se nombran en diferentes estilos (firstName и first_name). Para cada ACTUALIZACIÓN, el código envía un mensaje a una cola diferente, que es manejada por una función sin servidor diferente, pero que hace todo el trabajo para una colección diferente en la misma base de datos. ¿Mencioné que esta función sin servidor proviene de una “arquitectura orientada a servicios” basada en la nube que contiene más de 100 funciones en el entorno?
¿Cómo fue posible hacer esto? Me cubro la cara y sollozo visiblemente entre risas. Mis compañeros preguntan qué pasó y yo lo vuelvo a contar en colores. Peores éxitos de BulkDataImporter.js 2018. Todos me saludan con simpatía y están de acuerdo: ¿cómo pudieron hacernos esto?
Negatividad: una herramienta emocional en una cultura programadora
La negatividad juega un papel importante en la programación. Está arraigado en nuestra cultura y se utiliza para compartir lo que hemos aprendido (“no lo creerás, ¡cómo era ese código!”), expresar simpatía a través de la frustración (“Dios, ¿POR QUÉ hacer eso?”), lucirse (“yo nunca tan no lo hizo”), echarle la culpa a otra persona (“fallamos debido a su código, que es imposible de mantener”), o, como es habitual en las organizaciones más “tóxicas”, gestionar a los demás a través de un sentido de vergüenza ("¿En qué estabas pensando?" ? correcto").
La negatividad es muy importante para los programadores porque es una forma muy eficaz de transmitir valor. Una vez asistí a un campamento de programación, y la práctica habitual de inculcar una cultura industrial en los estudiantes era proporcionar generosamente memes, historias y vídeos, los más populares de los cuales explotaban . Es bueno poder utilizar herramientas emocionales para identificar lo bueno, lo malo, lo feo, no hagas eso, nunca. Es necesario preparar a los recién llegados para el hecho de que probablemente serán malinterpretados por colegas que están lejos de TI. Que sus amigos empezarán a venderles ideas de aplicaciones millonarias. Que tendrán que deambular por interminables laberintos de código obsoleto con un montón de minotauros a la vuelta de la esquina.
Cuando aprendemos a programar por primera vez, nuestra comprensión de la profundidad de la "experiencia de programación" se basa en la observación de las reacciones emocionales de otras personas. Esto se puede ver claramente en las publicaciones en , donde pasan el rato muchos programadores novatos. Muchos humorísticos están, en un grado u otro, teñidos de diferentes matices de negatividad: decepción, pesimismo, indignación, condescendencia y otros. Y si esto no te parece suficiente, lee los comentarios.
Noté que a medida que los programadores ganan experiencia, se vuelven cada vez más negativos. Los principiantes, sin darse cuenta de las dificultades que les aguardan, comienzan con entusiasmo y voluntad de creer que la causa de estas dificultades es simplemente la falta de experiencia y conocimiento; y eventualmente se enfrentarán a la realidad de las cosas.
Pasa el tiempo, ganan experiencia y pueden distinguir el código bueno del malo. Y cuando llega ese momento, los jóvenes programadores sienten la frustración de trabajar con código obviamente malo. Y si trabajan en equipo (de forma remota o en persona), a menudo adoptan los hábitos emocionales de colegas más experimentados. Esto a menudo conduce a un aumento de la negatividad, porque los jóvenes ahora pueden hablar reflexivamente sobre el código y dividirlo en malo y bueno, demostrando así que están "al tanto". Esto refuerza aún más lo negativo: por decepción, es fácil llevarse bien con colegas y formar parte de un grupo; criticar Bad Code aumenta su estatus y profesionalismo ante los ojos de los demás: .
Aumentar la negatividad no es necesariamente algo malo. Las discusiones sobre programación, entre otras cosas, se centran extremadamente en la calidad del código escrito. Lo que es el código define completamente la función que pretende realizar (aparte del hardware, la red, etc.), por lo que es importante poder expresar su opinión sobre ese código. Casi todas las discusiones se reducen a si el código es lo suficientemente bueno y a condenar los propios manifiestos del código incorrecto en términos cuya connotación emocional caracteriza la calidad del código:
- "Hay muchas inconsistencias lógicas en este módulo; es un buen candidato para una optimización significativa del rendimiento".
- "Este módulo es bastante malo, necesitamos refactorizarlo".
- "Este módulo no tiene sentido, es necesario reescribirlo".
- "Este módulo apesta, necesita un parche".
- "Esto es una pieza de RAM, no un módulo, no necesitaba ser escrito en absoluto, ¿qué diablos estaba pensando su autor?"
Por cierto, es esta "liberación emocional" la que hace que los desarrolladores llamen al código "sexy", lo cual rara vez es justo, a menos que trabajes en PornHub.
El problema es que las personas somos criaturas extrañas, inquietas y emocionales, y la percepción y expresión de cualquier emoción nos cambia: al principio sutilmente, pero con el tiempo, dramáticamente.
Una problemática y resbaladiza pendiente de negatividad
Hace unos años, fui líder de equipo informal y entrevisté a un desarrollador. Nos agradaba mucho: era inteligente, hacía buenas preguntas, conocía la tecnología y encajaba bien en nuestra cultura. Me impresionó especialmente su positivismo y lo emprendedor que parecía. Y lo contraté.
En ese momento yo llevaba un par de años trabajando en la empresa y sentía que nuestra cultura no era muy efectiva. Intentamos lanzar el producto dos, tres veces y un par de veces más antes de que yo llegara, lo que generó grandes gastos en retrabajo, durante los cuales no teníamos nada que mostrar excepto largas noches, plazos ajustados y productos que funcionaban. Y aunque todavía estaba trabajando duro, me sentía escéptico sobre el último plazo que nos había asignado la dirección. Y maldijo casualmente cuando discutió algunos aspectos del código con mis colegas.
Así que no fue sorprendente, aunque sí me sorprendió, que unas semanas más tarde, ese mismo nuevo desarrollador dijera las mismas cosas negativas que yo (incluyendo malas palabras). Me di cuenta de que se comportaría de manera diferente en una empresa diferente con una cultura diferente. Simplemente se adaptó a la cultura que yo creé. Me invadió un sentimiento de culpa. Debido a mi experiencia subjetiva, inculqué pesimismo en un recién llegado a quien percibía como completamente diferente. Incluso si él realmente no era así y solo estaba aparentando para demostrar que podía encajar, lo obligué a adoptar mi actitud de mierda. Y todo lo dicho, aunque sea en broma o de pasada, tiene la mala costumbre de convertirse en lo que se cree.
formas negativas
Volvamos a nuestros antiguos programadores novatos, que han adquirido un poco de sabiduría y experiencia: se han familiarizado más con la industria de la programación y comprenden que el código incorrecto está en todas partes y no se puede evitar. Ocurre incluso en las empresas más avanzadas centradas en la calidad (y déjenme señalar: aparentemente, la modernidad no protege contra el código incorrecto).
Buen guión. Con el tiempo, los desarrolladores comienzan a aceptar que el código incorrecto es una realidad del software y que su trabajo es mejorarlo. Y que si no se puede evitar el código incorrecto, entonces no tiene sentido armar un escándalo por ello. Toman el camino del Zen, enfocándose en resolver los problemas o tareas que enfrentan. Aprenden cómo medir y comunicar con precisión la calidad del software a los propietarios de empresas, escribir estimaciones bien fundamentadas basadas en sus años de experiencia y, en última instancia, recibir generosas recompensas por su increíble y continuo valor para la empresa. Hacen su trabajo tan bien que les pagan 10 millones de dólares en bonos y se retiran para hacer lo que quieran por el resto de sus vidas (por favor, no lo den por sentado).
Otro escenario es el camino de la oscuridad. En lugar de aceptar el código incorrecto como algo inevitable, los desarrolladores se encargan de denunciar todo lo malo en el mundo de la programación para poder superarlo. Se niegan a mejorar el código incorrecto existente por muchas buenas razones: “la gente debería saber más y no ser tan estúpida”; "es desagradable"; “esto es malo para los negocios”; “esto demuestra lo inteligente que soy”; “Si no les digo que es un código tan malo, toda la empresa se caerá al océano”, y así sucesivamente.
Seguramente incapaces de implementar los cambios que desean porque lamentablemente el negocio debe continuar desarrollándose y no pueden perder tiempo preocupándose por la calidad del código, estas personas se ganan la reputación de quejosos. Se mantienen por su alta competencia, pero se los empuja a los márgenes de la empresa, donde no molestarán a mucha gente, pero seguirán apoyando el funcionamiento de sistemas críticos. Sin acceso a nuevas oportunidades de desarrollo, pierden habilidades y dejan de satisfacer las demandas de la industria. Su negatividad se convierte en amargura y, como resultado, alimentan sus egos discutiendo con estudiantes de veinte años sobre el viaje que ha recorrido su vieja tecnología favorita y por qué sigue siendo tan popular. Terminan jubilándose y viviendo su vejez insultando a los pájaros.
La realidad probablemente se encuentre en algún punto intermedio entre estos dos extremos.
Algunas empresas han tenido mucho éxito en la creación de culturas extremadamente negativas, insulares y de voluntad fuerte (como Microsoft antes de su creación). ) - a menudo se trata de empresas con productos que se adaptan perfectamente al mercado y a la necesidad de crecer lo más rápido posible; o empresas con una jerarquía de mando y control (Apple en los mejores años de Jobs), donde cada uno hace lo que le dicen. Sin embargo, la investigación empresarial moderna (y el sentido común) sugiere que el máximo ingenio, que conduce a la innovación en las empresas y a una alta productividad en los individuos, requiere bajos niveles de estrés para respaldar el pensamiento creativo y metódico continuo. Y es extremadamente difícil realizar un trabajo creativo basado en debates si estás constantemente preocupado por lo que tus colegas tendrán que decir sobre cada línea de tu código.
La negatividad está diseñando la cultura pop.
Hoy en día se presta más atención que nunca a la actitud de los ingenieros. En las organizaciones de ingeniería, la regla "". Cada vez aparecen más anécdotas e historias en Twitter sobre personas que abandonaron esta profesión porque no podían (no querían) seguir soportando la hostilidad y la mala voluntad hacia los extraños. Incluso Linus Torvalds Años de hostilidad y críticas hacia otros desarrolladores de Linux, esto ha llevado a un debate sobre la efectividad de este enfoque.
Algunos todavía defienden el derecho de Linus a ser muy crítico: aquellos que deberían saber mucho sobre las ventajas y desventajas de la "negatividad tóxica". Sí, el civismo es sumamente importante (incluso fundamental), pero si resumimos las razones por las que muchos de nosotros permitimos que la expresión de opiniones negativas se convierta en "toxicidad", estas razones parecen paternalistas o adolescentes: "se lo merecen porque son idiotas". ", "debe estar seguro de que no lo volverán a hacer", "si no hubieran hecho eso, no tendría que gritarles", etc. Un ejemplo del impacto que tienen las reacciones emocionales de un líder en una comunidad de programación es el acrónimo de la comunidad Ruby MINASWAN: "Matz es amable, entonces nosotros somos amables".
He notado que muchos defensores fervientes del enfoque de "matar a un tonto" a menudo se preocupan mucho por la calidad y corrección del código, identificándose con su trabajo. Desafortunadamente, a menudo se confunde dureza con rigidez. La desventaja de esta posición proviene del simple deseo humano, pero improductivo, de sentirse superior a los demás. Las personas que se sumergen en este deseo quedan atrapadas en el camino de la oscuridad.
El mundo de la programación está creciendo rápidamente y va más allá de los límites de su contenedor: el mundo de la no programación (¿o es el mundo de la programación un contenedor para el mundo de la no programación? Buena pregunta).
A medida que nuestra industria se expande a un ritmo cada vez mayor y la programación se vuelve más accesible, la distancia entre los "técnicos" y los "normales" se está acortando rápidamente. El mundo de la programación está cada vez más expuesto a las interacciones interpersonales de personas que crecieron en la cultura nerd aislada del primer boom tecnológico, y son ellos quienes darán forma al nuevo mundo de la programación. E independientemente de cualquier argumento social o generacional, la eficiencia en nombre del capitalismo aparecerá en la cultura empresarial y en las prácticas de contratación: las mejores empresas simplemente no contratarán a nadie que no pueda interactuar neutralmente con los demás, y mucho menos tener buenas relaciones.
Lo que aprendí sobre la negatividad
Si permite que demasiada negatividad controle su mente y sus interacciones con las personas, convirtiéndose en toxicidad, entonces es peligroso para los equipos de productos y costoso para las empresas. He visto (y oído hablar de) innumerables proyectos que se desmoronaron y fueron completamente reconstruidos con un gran costo porque un desarrollador confiable tenía rencor contra la tecnología, otro desarrollador o incluso un solo archivo elegido para representar la calidad de todo el código base.
La negatividad también desmoraliza y destruye las relaciones. Nunca olvidaré cómo un colega me regañó por poner CSS en el archivo equivocado, esto me molestó y no me permitió ordenar mis pensamientos durante varios días. Y en el futuro, es poco probable que permita que una persona así esté cerca de uno de mis equipos (pero quién sabe, la gente cambia).
Finalmente, lo negativo .
Creo que así debería ser una clase magistral sobre sonrisas.
Por supuesto, esto no es un argumento a favor de irradiar felicidad, insertar diez mil millones de emoticones en cada solicitud de extracción o asistir a una clase magistral sobre sonrisas (no, bueno, si eso es lo que quieres, entonces no hay duda). La negatividad es una parte extremadamente importante de la programación (y de la vida humana), que indica calidad y permite expresar sentimientos y compadecerse de otros seres humanos. La negatividad indica perspicacia y prudencia, la profundidad del problema. A menudo me doy cuenta de que un desarrollador ha alcanzado un nuevo nivel cuando comienza a expresar incredulidad en aquello de lo que antes era tímido e inseguro. Las personas demuestran razonabilidad y confianza con sus opiniones. No se puede descartar la expresión de negatividad, eso sería orwelliano.
Sin embargo, la negatividad debe dosificarse y equilibrarse con otras cualidades humanas importantes: la empatía, la paciencia, la comprensión y el humor. Siempre puedes decirle a una persona que cometió un error sin gritar ni maldecir. No subestimes este enfoque: si alguien te dice sin ninguna emoción que has cometido un error grave, da mucho miedo.
Esa vez, hace varios años, el director ejecutivo habló conmigo. Hablamos del estado actual del proyecto y luego me preguntó cómo me sentía. Le respondí que todo estaba bien, el proyecto avanzaba, estábamos trabajando lentamente, tal vez me perdí algo y necesitaba ser reconsiderado. Dijo que me había oído compartir pensamientos más pesimistas con colegas de la oficina y que otros también lo habían notado. Explicó que si tuviera dudas, podría expresárselas plenamente a la gerencia, pero no “eliminarlas”. Como ingeniero líder, tengo que ser consciente de cómo mis palabras afectan a los demás porque tengo mucha influencia incluso si no me doy cuenta. Y me dijo todo esto muy amablemente, y finalmente dijo que si realmente me sentía así, entonces probablemente tendría que pensar en lo que quiero para mí y mi carrera. Fue una conversación increíblemente gentil, del tipo “tómalo o levántate del asiento”. Le agradecí la información sobre cómo mi cambio de actitud durante seis meses estaba afectando a otros sin que yo me diera cuenta.
Fue un ejemplo de gestión extraordinaria y eficaz y del poder de un enfoque suave. Me di cuenta de que sólo parecía tener plena fe en la empresa y en su capacidad para lograr sus objetivos, pero en realidad hablaba y me comunicaba con los demás de una manera completamente diferente. También me di cuenta de que incluso si me sentía escéptico sobre el proyecto en el que estaba trabajando, no debía mostrar mis sentimientos a mis colegas y difundir el pesimismo como un contagio, reduciendo nuestras posibilidades de éxito. En cambio, podría transmitir agresivamente la situación real a mi gerencia. Y si sentía que no me escuchaban, podía expresar mi disconformidad saliendo de la empresa.
Recibí una nueva oportunidad cuando asumí el cargo de jefe de evaluación de personal. Como ex ingeniero jefe, soy muy cuidadoso al expresar mis opiniones sobre nuestro código heredado (en constante mejora). Para aprobar un cambio, es necesario imaginar la situación actual, pero no llegarás a ninguna parte si te dejas llevar por gemidos, ataques o cosas por el estilo. En última instancia, estoy aquí para completar una tarea y no debería quejarme del código para poder comprenderlo, evaluarlo o corregirlo.
De hecho, cuanto más controlo mi reacción emocional al código, más entiendo en qué podría convertirse y menos confusión siento. Cuando me expresaba con moderación (“debe haber margen para seguir mejorando aquí”), estaba haciendo felices a mí y a los demás y no me tomaba la situación demasiado en serio. Me di cuenta de que podía estimular y reducir la negatividad en los demás siendo perfectamente (¿molesto?) razonable (“tienes razón, este código es bastante malo, pero lo mejoraremos”). Me alegra ver hasta dónde puedo llegar en el camino Zen.
Esencialmente, estoy constantemente aprendiendo y reaprendiendo una lección importante: la vida es demasiado corta para estar constantemente enojado y dolorido.
Fuente: habr.com