Home Ciencia y Tecnología El síndrome de Icarus en ingeniería de software program (y cómo vencerlo)

El síndrome de Icarus en ingeniería de software program (y cómo vencerlo)

28
0

Todos conocemos la historia de Icarus:

Encargado por el rey en una isla al sur del Mar Egeo, su padre Daedalus ideó un plan de escape. Planeaba reunir plumas de los pájaros que volaban cerca de su torre, asegurarlas con hilo y fijarlas con cera. Elaboró dos pares de alas, una para él y otra para su hijo.

El impostor:
Sin embargo, Daedalus cuestionó su propio diseño. Se revolvió en sí mismo durante meses. ¿Se mantendrían las alas? ¿Se lideraba a sí mismo y a Icarus en un desastre? Sus planes de escape se retrasaron debido al peso de la incertidumbre.

Antes de tomar el vuelo, Daedalus dio instrucciones estrictas de Icarus: no vuela ni demasiado bajo, donde la humedad del mar podría obstruir las alas, ni demasiado alto, donde el calor del sol podía derretir la cera.

La arrogancia:
Icarus tenía otras concepts. Cuando dio sus primeros pasos al aire, sintió una sensación de libertad. Con cada solapa de las alas, se disparó más rápido. En su emoción, ignoró la única advertencia de Daedalus y voló más alto. La cera que ató las plumas comenzó a derretirse. Una pluma se deshizo, seguida de otra. Pronto, estaba en caída libre, y Daedalus observó con horror cómo su propio hijo se desplomaba del cielo. Todo lo que se necesitó fue un momento de arrogancia para provocar la tragedia.

.
.
.

Corte a 3.000 años después. Un ingeniero de software program que trabaja en el corazón de Silicon Valley experimenta cambios emocionales similares cada semana.

Un día, no puede entender por qué su aplicación Spring Boot no se inicia. Ha revisado el código cuatro veces, y un compañero de equipo se une a usted para revisarlo. Aún así, no hay suerte. Cuatro horas después, después de casi enviar un correo electrónico a su campo de botas exigiendo un reembolso completo y una disculpa incondicional, lo encuentra: un tablero EM se coló en el nombre de su archivo de configuración donde debería estar un tablero regular.

software–dev.properties

parece idéntico a

software—dev.properties

Al menos en la pantalla lo hace, pero Spring no reconoce el nombre del archivo con el personaje de EM Sprint. Su cerebro académico de cafeína tampoco alcanzó la diferencia Unicode entre (U+2014) y U+002d.

Te odias a ti mismo. Te sientes como el peor ingeniero de software program, ya que el desarrollador que codificó su contraseña en el código fuente.

Al día siguiente por la mañana, inicia sesión. El paseo de la vergüenza al día diario, donde le cube a todos los que pasó todo el día arreglando su propio archivo de configuración, supera su confianza.

Momentos después: los temidos anillos de campaña de los equipos de Microsoft en el piso …

Los usuarios no pueden iniciar sesión en todo el país. El gerente y el propietario del producto han provocado una llamada. Los compañeros de equipo se unen, y tú también. Nadie puede averiguar qué está pasando mientras mira el tablero.

Se lanzan diferentes teorías. Algunos sugieren reiniciar los contenedores. No ayuda.

El desarrollador senior está pasando por compromisos recientes. El desarrollador junior repite lo que dicen los gerentes, solo para ser escuchados en la llamada.

Notas algo.

El número de llamadas que ingresan a su servicio y la cantidad de errores registrados no se alinean. De repente, lo ves. Una llamada al servicio de servicio de un proveedor, y el código no tiene en cuenta. La aplicación intenta continuar como si nada sucediera cuando debería haber errado y notificado al equipo.

¡Tienes una solución! El proveedor ha sido informado del tiempo de espera. Se reinician sus contenedores. Los usuarios pueden iniciar sesión nuevamente.

Cue Borat’s Nice Success Gif!

Ayer, no pudiste mirarte a los ojos, y hoy eres el favorito del gerente (al menos para hoy; veremos cómo va el mañana). Esta es la sierra ver de las emociones del mundo de la ingeniería.

¿Cómo lidiamos con esto?

La clave es adoptar esta dicotomía: no como una elección binaria sino como un rango dinámico de experiencias. Cada línea de código, cada error y cada solución contribuyen a un viaje más amplio de aprendizaje y crecimiento. En lugar de verse a sí mismo como un desarrollador impostor o superior, trate de verse a sí mismo como un alumno perpetuo. Daedalus reconoció sus limitaciones mientras se esforzaba continuamente por innovar. Los cielos pueden ser impredecibles, pero con resiliencia y conciencia, sabía que podía volar con un propósito.

En el mundo de Icarus, sea un daedalus.

fuente

LEAVE A REPLY

Please enter your comment!
Please enter your name here