Ira por el código: programadores y negatividad

Estoy mirando una pieza de código. Quizás este es el peor código que he conocido. Para actualizar solo un registro en la base de datos, extrae todos los registros de la colección y luego envía una solicitud para actualizar cada registro en la base de datos, incluso aquellos que no necesitan actualizarse. Hay una función de mapa que simplemente devuelve el valor que se le pasó. Hay comprobaciones condicionales de variables con obviamente el mismo valor, simplemente nombradas en diferentes estilos ( firstName y first_name ). Para cada ACTUALIZACIÓN, el código envía un mensaje a otra cola, que es procesada por otra función sin servidor, pero que hace todo el trabajo para otra colección en la misma base de datos. ¿No 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 podría hacerse tal cosa? Me tapo la cara y lloro entre risas. Mis colegas preguntan qué sucedió, y vuelvo a contar en color los peores éxitos de BulkDataImporter.js 2018 . Todos me saludan con simpatía y están de acuerdo: ¿cómo podrían hacernos esto?

Negativo: una herramienta emocional en la cultura del programador

La negatividad juega un papel importante en la programación. Está integrado en nuestra cultura y se usa para compartir lo que se reconoce ("¡no creerás cómo se veía este código!"), Para expresar simpatía a través de un malestar ("Señor, ¿por qué hacer esto?") a la luz ("nunca haría eso"), culpar a otros ("nos alardeamos por su código que es imposible de acompañar") o, como es habitual en las organizaciones más "tóxicas", gestionar a otros por vergüenza ("¿En qué estabas pensando? Correcto").



La negatividad es muy importante para los programadores porque es una forma muy efectiva de transmitir valor. Solía ​​estudiar en un campamento de programadores, y la práctica habitual de vacunar a los estudiantes con la cultura del gremio era proporcionar generosamente memes, historias y videos, el más popular de los cuales explotó la decepción de los programadores cuando la gente los confundía . Es bueno cuando puedes usar herramientas emocionales para denotar lo bueno, lo malo, lo horrible, nunca hagas esto, nunca en absoluto. Es necesario preparar a los principiantes para el hecho de que sus colegas, lejos de TI, probablemente los entenderán erróneamente. Que sus amigos comenzarán a impulsarles ideas de aplicaciones "en un millón". Lo que tienen que deambular en los interminables laberintos de código obsoleto con un montón de minotauros a la vuelta de la esquina.

Cuando comenzamos a aprender programación por primera vez, nuestra comprensión de la profundidad de la "experiencia de programación" se basa en observaciones de las reacciones emocionales de otras personas. Esto se ve claramente en las publicaciones en el subwoofer ProgrammerHumor , en el que se juntan muchos programadores nuevos. Muchas publicaciones humorísticas, en un grado u otro, están coloreadas con diferentes tonos de negativo: decepción, pesimismo, resentimiento, indulgencia y otros. Y si esto no te parece suficiente, lee los comentarios.



Noté que, con la acumulación de experiencia, los programadores se están volviendo cada vez más negativos. Los principiantes, sin darse cuenta de las dificultades que les esperan, comienzan con entusiasmo y disposición a creer que la razón de estas dificultades es simplemente la falta de experiencia y conocimiento; y al final se enfrentarán al estado real de las cosas.

El tiempo pasa, ganan experiencia y la capacidad de distinguir el código Bueno del Malo. Y cuando llega este momento, los jóvenes programadores están molestos al trabajar con un código aparentemente malo. Y si trabajan en equipo (de forma remota o en persona), a menudo adoptan los hábitos emocionales de los colegas más experimentados. A menudo, esto lleva a un aumento de la negativa, porque los jóvenes ahora pueden hablar cuidadosamente sobre el código y dividirlo en malo y bueno, lo que demuestra que están "en el tema". Esto refuerza aún más lo negativo: debido a la decepción, es fácil reunirse con colegas y formar parte de un grupo, las críticas al Código Malo elevan su estatus y profesionalismo a los ojos de los demás: las personas que expresan una opinión negativa a menudo son percibidas como más inteligentes y competentes .

Fortalecer lo negativo no es necesariamente algo malo. La discusión de la programación, entre otras cosas, está extremadamente centrada en la calidad del código escrito. El código es el que determina completamente la función para la que está destinado (descartamos el equipo, la red, etc.), por lo que es importante poder expresar su opinión sobre este código. Casi todas las discusiones se reducen a si este código es lo suficientemente bueno y a condenar el manifiesto del código malo en expresiones cuyo color emocional caracteriza la calidad del código:

• "Hay muchas inconsistencias lógicas en este módulo, que 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, necesita ser reescrito".
• "Este módulo apesta, necesita ser parcheado".
• "Este es un trozo de carnero, no un módulo, no necesitaba ser escrito en absoluto, qué demonios estaba pensando el autor".

Por cierto, es esta "liberación emocional" la que obliga a los desarrolladores a llamar al código "sexy", lo que rara vez es justo, a menos que trabajes en PornHub.

El problema es que las personas son extrañas, problemáticas, llenas de emociones de creación, y la percepción y expresión de cualquier emoción nos cambia: al principio apenas se nota, pero con el tiempo, dramáticamente.

Inquieto y resbaladizo rastro de negatividad

Hace unos años, era un líder informal del equipo y entrevisté a un desarrollador. Realmente nos gustó: era inteligente, hacía buenas preguntas, tenía conocimientos técnicos y encajaba perfectamente en nuestra cultura. Me impresionó especialmente su positividad y lo aventurero que parecía. Y lo contraté.

En ese momento, trabajé en la empresa durante un par de años y sentí que la cultura adoptada en nuestro país no era muy efectiva. Intentamos lanzar el producto dos veces, tres y un par de veces antes de que yo llegara, lo que me llevó a grandes gastos de retrabajo, durante los cuales no teníamos nada que mostrar, excepto largas noches, plazos cortos y productos de tipografía. Y aunque todavía trabajé duro, era escéptico sobre la última fecha límite que nos asignó la gerencia. Y maldijo casualmente cuando discutía con mis colegas algunos aspectos del código.

Por lo tanto, no había nada sorprendente en el hecho, aunque me sorprendió, de que unas pocas semanas después, el mismo desarrollador nuevo hablara de la misma manera negativa que yo (incluyendo palabrotas). Me di cuenta de que él habría actuado de manera diferente en una compañía diferente con una cultura diferente. Solo se ajustó a la cultura que yo creé. La culpa me abrumaba. Debido a mi experiencia subjetiva, inculqué pesimismo en el novicio, a quien percibí como completamente diferente. Incluso si realmente no era así y solo trataba de mostrar que podía unirse al equipo, le impuse mi actitud de mierda. Y todo lo que se ha dicho, incluso como una broma o de pasada, tiene una mala manera de transformar lo que uno cree.

Formas de negatividad

Volvamos a nuestros antiguos programadores novatos que obtuvieron un poco de sabiduría y experiencia: conocieron la industria de la programación más de cerca y entendieron que el código incorrecto está en todas partes, no se puede evitar. Se encuentra incluso en las empresas más avanzadas centradas en la calidad (y permítanme señalar: parece que la modernidad no nos salva del mal código en absoluto).

Buen guion. Con el tiempo, los desarrolladores comienzan a tolerar el hecho de que el código incorrecto es la realidad del software y que su trabajo es mejorarlo. Y si el código incorrecto no se puede evitar, entonces no tiene sentido hacer ruido por eso. Se embarcan en el camino del zen, se centran en resolver problemas o tareas que enfrentan. Aprenden a medir y entregar con precisión la calidad del software a los propietarios de negocios, en base a sus muchos años de experiencia, escriben estimaciones perfectamente justificadas y, en última instancia, reciben generosas recompensas por su valor increíble e inmutable para el negocio. Hacen su trabajo tan bien que se les paga bonificaciones de bonificación de $ 10 millones, y se jubilan para hacer lo que quieran por el resto de sus vidas (por favor, no lo tomen por fe).



Otro escenario es el camino de la oscuridad. En lugar de aceptar el código incorrecto como inevitable, los desarrolladores asumen la responsabilidad de anunciar todo lo malo en el mundo de la programación para poder derrotarlo. 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"; "Demuestra lo inteligente que soy"; "Si no te digo qué código tan malo es este, toda la compañía se lanzará al océano", y así sucesivamente.

Seguramente no tendrá la oportunidad de implementar los cambios deseados, ya que, desafortunadamente, las empresas deben continuar desarrollándose y no pueden pasar tiempo preocupándose por la calidad del código, esas personas ganan reputación como reclamantes. Están recluidos por su alta competencia, pero son conducidos al patio trasero de la compañía, donde no molestarán a muchos, pero al mismo tiempo apoyarán la operación de sistemas críticos. Habiendo perdido el acceso a nuevas oportunidades en el desarrollo, pierden sus habilidades y dejan de cumplir con los requisitos de la industria. Su negatividad se convierte en una amargura feroz y, como resultado, divierten su ego y discuten con estudiantes de veinte años sobre el camino que ha seguido su amada tecnología antigua y por qué todavía es nítida. Al final, se retiran y viven la vejez, maldiciendo a las aves.

Probablemente, la realidad está en algún punto intermedio entre estos dos extremos.

Algunas compañías han tenido mucho éxito en la creación de culturas extremadamente negativas, aisladas y de carácter fuerte (como Microsoft antes de su década perdida ); a menudo, estas son empresas con productos que coinciden perfectamente con el mercado y la necesidad de crecer lo más rápido posible; o empresas con una jerarquía de gestión y control (Apple en los mejores años de Jobs), donde todos hacen lo que les ordenan. Sin embargo, la investigación empresarial moderna (y el sentido común) sugiere que para obtener el máximo ingenio, lo que lleva a la innovación de la empresa y la alta productividad de las personas, se requiere un bajo nivel de estrés para mantener un pensamiento creativo y metódico continuo. Y es extremadamente difícil hacer un trabajo creativo, que se basa en discusiones si está constantemente preocupado por lo que sus colegas tendrán que decir sobre cada línea de su código.

Negativo es ingeniería cultura pop

Hoy, se presta más atención a la actitud de los ingenieros que nunca. En las organizaciones de ingeniería, la regla " No Ovuk " se está volviendo cada vez más popular. En Twitter, hay cada vez más bromas e historias sobre personas que dejaron esta profesión porque no podían (no querían) continuar soportando la hostilidad y hostilidad hacia los extraños. Incluso Linus Torvalds se disculpó recientemente a lo largo de los años por su hostilidad y críticas a otros desarrolladores de Linux, lo que llevó a una discusión sobre la efectividad de este enfoque.

Alguien todavía defiende el derecho de Linus a ser muy crítico: aquellos que necesitan saber mucho sobre las ventajas y desventajas de la "negatividad tóxica". Sí, la corrección es extremadamente importante (incluso fundamental), pero si resumimos las razones por las cuales muchos de nosotros permitimos que la expresión de opiniones negativas se convierta en "toxicidad", entonces estas razones parecen paternalistas o adolescentes: "se lo merecen porque son idiotas", "él Debo asegurarme de que no lo repitan, "" si no hubieran hecho eso, no tendría que gritarles ", y así sucesivamente. Un ejemplo de cómo las reacciones emocionales del líder afectan a la comunidad de programación es la abreviatura MINASWAN en la comunidad Ruby: "Matz es bueno, así que somos agradables" (Matz [creador del lenguaje] es bueno, así que somos buenos).

Me di cuenta de que muchos partidarios ardientes del enfoque de "matar al tonto" a menudo se preocupan mucho por la calidad y la corrección del código, identificándose con su trabajo. Desafortunadamente, a menudo confunden dureza con rigidez. La desventaja de esta posición proviene de un simple deseo humano, pero improductivo, de sentirse superior a los demás. Las personas que están inmersas en este deseo están atrapadas en el camino de la oscuridad.



El mundo de la programación está creciendo rápidamente y colinda con los límites de su contenedor: el mundo de la no programación (¿o es este el mundo de la programación de 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 "técnicos" y "normales" está disminuyendo rápidamente. El mundo de la programación está cada vez más expuesto a la comunicación interpersonal entre las personas que crecieron en una cultura aislada de "nerds" del comienzo del tecno-boom, y son ellos quienes formarán el nuevo mundo de la programación. E independientemente de cualquier argumento con respecto a la esfera social o las generaciones, la eficiencia en nombre del capitalismo se manifestará en la cultura de las empresas y los enfoques de contratación: las mejores empresas simplemente no contratarán a aquellos que no pueden interactuar con otros de manera neutral, sin mencionar las buenas relaciones.

Lo que aprendí sobre lo negativo

Si permite que un exceso de negatividad controle su mente y la comunicación con las personas, convirtiéndose en "toxicidad", entonces esto es peligroso para los equipos de productos y costoso para los negocios. Vi una gran cantidad de proyectos (y escuché sobre ellos) que se desmoronaron y se rehicieron por completo a un alto costo, porque uno de los desarrolladores de confianza afiló sus dientes en tecnología, otro desarrollador o incluso el único archivo seleccionado para representar la calidad de toda la base de código .

La negatividad también desmoraliza y destruye las relaciones. Nunca olvidaré cómo un colega me regañó por poner CSS en el archivo incorrecto, esto me molestó y me impidió reunir mis pensamientos durante varios días. Y en el futuro es poco probable que permita que esa persona esté cerca de uno de mis equipos (sin embargo, quién sabe, la gente está cambiando).

Finalmente, la negatividad literalmente daña tu salud .


Me parece que una clase magistral sobre sonrisas debería verse así.

Por supuesto, este no es un argumento a favor de ser feliz, insertar diez mil millones de emoticones en cada solicitud de extracción o ir a una clase magistral con 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 la vida humana), ya que es señal de calidad, lo que le permite expresar sentimientos y condolencias a las personas-hermanos. Evidencia negativa de perspicacia y razonabilidad, la profundidad del problema. A menudo noto que un desarrollador ha alcanzado un nuevo nivel cuando comienza a expresar desconfianza en lo que era tímido e inseguro. Con sus opiniones, las personas demuestran prudencia y confianza. No se puede rechazar la expresión de negatividad, sería en estilo orwelliano.

Sin embargo, lo negativo debe ser dosificado y equilibrado con otras cualidades humanas importantes: empatía, paciencia, comprensión y humor. Siempre puedes decirle a una persona que se equivocó sin gritar ni maldecir. No subestimes este enfoque: si estás completamente sin emoción, dicen que te equivocaste mucho, realmente asusta.

En ese momento, hace varios años, el CEO me habló. Discutimos la situación actual del proyecto, luego me preguntó cómo me sentía. Le respondí que todo estaba bien, que el proyecto se estaba moviendo, que estábamos trabajando lentamente, tal vez me había perdido algo y necesitaba ser revisado. Dijo que me escuchó compartir más consideraciones pesimistas con colegas en la oficina, y que otros también notaron esto. Explicó que si tengo dudas, puedo expresarlas completamente a los líderes, pero no "bajarlas". Como ingeniero principal, debo recordar cómo mis palabras afectan a los demás, porque tengo una gran influencia, incluso si no me doy cuenta. Y todo esto me lo dijo muy amablemente, y al final dijo que si realmente siento esos sentimientos, entonces probablemente necesito pensar en lo que quiero para mí y mi carrera. Fue una conversación increíblemente suave al estilo de "reponerse o salir". Le agradecí la información sobre cómo mi actitud, que ha cambiado en los últimos seis meses, afecta de manera imperceptible a los demás.

Este fue un ejemplo de administración maravillosa y efectiva y el poder de un enfoque suave. Me di cuenta de que solo me parecía que creía totalmente en la empresa y en su capacidad para lograr objetivos, pero en realidad hablé y me comuniqué con los demás de una manera completamente diferente. También me di cuenta de que incluso sintiendo escepticismo sobre el proyecto en el que estaba trabajando, no debería haber mostrado mi actitud a mis colegas y difundir el pesimismo como una infección, reduciendo nuestras posibilidades de éxito. En cambio, podría transmitir agresivamente la situación real a mi liderazgo. Y si sentía que no me estaban escuchando, podría expresar mi desacuerdo con dejar la empresa.

Tuve una nueva oportunidad cuando asumí el cargo de jefe de evaluación de personal. Como ex ingeniero jefe, superviso cuidadosamente mi opinión sobre nuestro código heredado (en constante mejora). Para aprobar el cambio, debes imaginar la situación actual, pero no llegarás a nada si te atascas en gemidos, ataques o algo así. , , , , , .

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

, : , .