Esta es una gran pregunta.
Es absolutamente cierto que, como ingenieros agresivos , nos encontramos con situaciones de WTF con bastante frecuencia. Por ejemplo, mi equipo actualmente está haciendo un poco de cableado de arranque de primavera, scala, cassandra, kafka, y una serie de otras piezas entre sí. Debido a la gran complejidad de lo que estamos haciendo, nos encontramos con todo tipo de problemas.
Por ejemplo, ¿cuál es la forma correcta de mantener las compensaciones de kafka en un sistema distribuido de este tipo? Respuesta: Tuvimos que implementar nuestra propia solución, que inspecciona los cálculos en tiempo real, saca las compensaciones y las guarda en kafka. Es sorprendente que no parezca que haya una solución estándar para esto y esto es algo que deberíamos abrir claramente.
Otro ejemplo es nuestro uso de Apache Storm, que es otro sistema de cómputo distribuido, y que, de vez en cuando, simplemente parece morir. Así que tenemos que poner en marcha sistemas de alerta / reinicio para lidiar con eso, y planificar una migración de Storm a Spark.
- ¿Cómo se evita el juego de la culpa cuando las cosas van mal en un equipo?
- He planeado tantas cosas, pero no puedo organizarlo de acuerdo con la prioridad. ¿Qué tengo que hacer?
- ¿Por qué me aburro fácilmente?
- ¿Qué crees que atrae a la gente a los cultos?
- ¿Podré alguna vez lograr algo en mi vida?
En otro caso, estábamos haciendo uso de los dominios Node.js, pero resulta que los dominios en Node están rotos y que Node internamente estaba haciendo cosas realmente malvadas que rompieron su interacción con otra biblioteca que estábamos usando, así que terminamos hasta conseguir un parche empujado en el propio nodo.
En conclusión, si estás haciendo algo remotamente interesante, si estás usando un software en las últimas versiones y presionando el código, siempre vas a tener un comportamiento bizarro que deberás resolver por ti mismo y luego parche de alguna manera Si no lo eres, entonces es probable que no estés haciendo nada interesante.
Por supuesto, mis partes favoritas en realidad no son las anteriores, que en realidad tienden a ser complicadas porque solo estás perdiendo el tiempo resolviendo las malas elecciones de diseño de otra persona. Las partes divertidas son en realidad escribir código, e incluso allí siempre hay nuevos patrones para aprender y mejores enfoques … pero esas son cosas que tienen un efecto de palanca y te hacen más productivo / mejor en tu trabajo y son divertidos. Por ejemplo, cosas como aprender un nuevo idioma desafiante o una nueva metodología o una nueva forma de lidiar con el código asíncrono o nuevos enfoques teóricos de las cosas que resultan en un código práctico más sólido; Por ejemplo, aprender a escribir código de rendimiento contra datos inmutables.
HTH.