Como ingeniero, ¿cuál es un ejemplo de un buen día y uno malo?

Específico para mi trabajo:

Buen día: descubro un problema, se me ocurre una prueba que lo documenta a fondo que funciona la primera vez en lugar de tener que depurarlo, lo presento a I + D y lo aceptan y se ponen a trabajar para solucionarlo.

Mal día: a) el problema vino de mi uso incorrecto del producto, por lo que perder el tiempo discutiendo con él
b) mi rutina de prueba no funciona correctamente (luchando con esa hoy)
c) I + D ve el problema documentado, pero pone muchas excusas y lo convierte en una cuestión de política de oficina en lugar de centrarse en el cliente

Haga que sea un buen día nuevamente: a) Los clientes tuvieron el mismo problema, y ​​ahora puedo documentarlo y escribirlo para ellos, aumentando su confianza en nuestras habilidades técnicas y haciéndolos confiar más en nosotros.
b) Aprendo mucho sobre cómo hacer que mi código funcione mejor
c) Involucro al VP, y el VP les grita. No, eso no resuelve mi problema, pero tengo una sensación retorcida de satisfacción al saber que están en problemas y yo no.

Buen día: el cliente pregunta si una aplicación es viable. Construyo un sistema de prueba, funciona bien, digo que sí, que el cliente ordena una pequeña carga del subsistema que hice.

Mal día: resuelvo un problema para un cliente, y es una solución realmente simple, elegante, barata y fácil que instantáneamente hace que nuestro producto sea mucho más viable para su aplicación sin que tengan que revisar nada , algo que solo es un problema porque el cliente hizo un gran error técnico en su diseño, pero al cliente no le gusta porque “no tienen que hacer eso por . (Lo veo como una excusa para dejarnos e ir a un solo proveedor: tenemos documentación de un cliente haciendo eso porque alguien fue sobornado para hacerlo).

Haga que sea un buen día otra vez: un año después, descubra que el ingeniero que descalificó nuestro producto ya no está en ese departamento. Reenvío nuestro producto con la solución fácil, y está calificado como equivalente al producto de la competencia.

Pero vuelva a ser un mal día: no les gusta nuestro precio y no enviarán una contraoferta. 🙁

Buen día: conseguir trabajo en algo significativo hecho. Ya sea que esté funcionando al final del día o no, es sobre todo irrelevante, siempre y cuando haya escrito algo nuevo e interesante que se dirija hacia el camino correcto. Eso incluye especificaciones de diseño, no solo código.

Mal día: trabajando en cosas inmateriales (modificando el código de manera que no mejore el proceso del desarrollador ni la experiencia del usuario), sin hacer nada (por ejemplo, pasar el día depurando el oscuro error que no puedo depurar normalmente que termina siendo un tercero grado síntoma de haber usado un guión bajo en alguna parte), o que me hayan dicho que deje de trabajar en el proyecto que me interesaba.

Durante mi licenciatura:

Mal día: examen
Buen día: ¡Cada dos días!

Ahora:

Buen día: cada pieza de código funciona, de alguna manera.
Mal día: cada pieza de código no funciona de alguna manera

Buen día: me paso todo el día haciendo cálculos y trabajando en dibujos.

Mal día: me paso todo el día lidiando con BS administrativas y enviando correos electrónicos a contactos y estoy atrasada por la información que falta.

Un buen día es cuando su diseño funciona como lo pretendía. Lo contrario de eso es un mal día. Tener que explicar los resbalones de la línea de tiempo a la alta gerencia también puede ser un mal día.

Buen día: cuando despejas 4-5 rondas del proceso de entrevista aplicando tus conocimientos para obtener el primer trabajo de tu vida

Mal día: cuando llegaste a saber que lo que haces en tu trabajo no necesita las habilidades que aprendiste durante tu ingeniería

Buen día: envío de una función
Mal día: darse cuenta de la función no resolvió el problema del usuario.

Mal día: Discutir con los probadores sobre los problemas no.
Buen día: Discutir con los evaluadores sobre los problemas reales a resolver.

Buen día: aplico mis conocimientos.

Mal día: estudio para los exámenes.