Mi primer compromiso en mi proyecto dio como resultado que se rompiera la construcción nocturna y que la gente esté sobre mí cuando nos acercamos al lanzamiento. Quiero enviar un correo electrónico de disculpa que debería parecer sincero. y al mismo tiempo insinuando que este fue mi primer compromiso y que ya no se repetiría.
Siendo un hablante de inglés no nativo, tengo dificultades para encontrar las palabras correctas. ¿Alguien por favor puede ayudar?
¡No discúlpate!
También, apuesto a que su equipo falla el 'Prueba de Joel' y no puede hacer una compilación en uno paso.
Si es así, esto sería otra cosa por la que no deberías disculparte. De hecho, es un equipo anti-patrón.
Bagels. Rosquillas Etc. En una empresa en la que trabajé en el pasado, verificar el código dañado o causar la interrupción de un colega generalmente se resuelve con la entrega de alimentos de disculpa al día siguiente.
Un día, un tipo hizo explotar una base de datos de producción, lo que provocó un pánico masivo y una noche tarde para todo el equipo. Al día siguiente, asó hamburguesas a la parrilla para el almuerzo.
Me encantan las disculpas de compañeros de trabajo. Disculpas sabrosas y sabrosas.
Dos citas para ti:
El hombre que no comete errores no suele hacer nada .-- William Connor Magee
Cualquiera que no cometa errores no se está esforzando lo suficiente .-- Wess Roberts
Estoy de acuerdo con Jim G. , no te disculpes pero aprendas de ello y no creas el mismo error otra vez ... manténgalo SECO;)
No te disculpes, solo FIJELO lo antes posible. Sin embargo, está bien, todos rompen la construcción al menos una vez, en mi última compañía fue como un ritual de iniciación. Cuando un miembro del equipo rompió la construcción, pondríamos un patito de goma en su escritorio por la mañana antes de que entrara, esto le hizo saber que rompió la estructura y que la arreglaría.
Lo llamamos Duckie de Integración Continua y cuando lo tuviste para el día en que la gente se burlaría de ti, pero todo fue divertido, se suponía que nada de eso era mezquino.
Tomamos algo como una versión rota y la convertimos en un ejercicio de creación de equipos.
"Lo siento, mi mal!" Es como me disculpo generalmente cuando he roto la compilación. Sucede. Pero, como han dicho otros, esta es una oportunidad para mejorar sus sistemas para que una persona no pueda romper fácilmente la construcción para todos los demás.
No haría una disculpa formal en estas circunstancias, pero si realmente siente que una disculpa más formal es apropiada, entonces su disculpa debería hacer lo siguiente:
Es decir, "lamento [EXPRESS LREGUE] que te haya molestado [TOMAS RESPONSABILIDAD] al accidentalmente [SAVE FACE] rompiendo la construcción [DECLARAR EL PROBLEMA]. Donuts me acompañan mañana. [MAKE ENMENDA]"
Cada parte es necesaria en una disculpa adecuada; Si no se menciona el problema, entonces no está claro. Si no expresa arrepentimiento, asume la responsabilidad y hace reparaciones, entonces la gente se siente como si no fuera sincera. La parte para salvar la cara es la parte más pasada por alto de una disculpa; La parte de la cara a la cara es lo que le recuerda a la parte lesionada que usted es un valioso compañero de trabajo que a veces comete errores, y no un idiota (¡o un saboteador!)
Finalmente, algunas reflexiones sobre la ruptura de la construcción:
Trabajo en el equipo del compilador de C # / Visual Basic. Por supuesto, hoy en día Visual Studio es ahora un proyecto tan masivo que tiene un equipo propio solo para administrar la infraestructura de construcción, y una gran sala con su propio sistema de aire acondicionado dedicado. A mediados de la década de 1990, cuando comencé como pasante, el equipo de compilación de Visual Basic era uno interno y un armario lleno de máquinas. ¡Los tiempos han cambiado!
En aquellos días antes de la integración continua y los procesos de registro sólidos, los equipos tendrían una variedad de penalizaciones por romper la construcción. En algunos equipos, el castigo era que si rompías la construcción, tenías que usar un sombrero divertido todos los días en el trabajo hasta que alguien más lo hiciera. En algunos equipos, si llevabas ese sombrero, eras responsable de verificar que la construcción nocturna era correcta.
El último bit puede parecer cruel, pero en realidad sirvió para un propósito valioso. Ya que casi todos rompieron la construcción en un momento u otro, eventualmente todo el equipo aprendería los procesos para verificar la construcción nocturna.
No te disculpes. Son tus compañeros de trabajo quienes tienen la culpa de no revisar tu primer compromiso y no tener un sistema de retroalimentación rápido para compilaciones como un servidor de integración continua.
En mi trabajo actual, tenemos una regla informal de que una persona que cometa furtivamente justo antes de salir del trabajo y que se rompa la preparación tiene que traer dulces / pasteles / bebidas para todo el equipo al día siguiente. Pero sí tenemos una integración continua que nos advierte de una construcción rota durante el día. Y la regla probablemente no se aplicaría al primer compromiso de alguien.
De todos modos, un correo formal de disculpas es probablemente demasiado.
Una regla fundamental: cuando te equivocas, ADMÍTALO: - | No tienes que arrepentirte de disculpas. Todos cometemos errores. Los pros lo admiten. Eso es trabajo en equipo. Los otros miembros del equipo deben estar reuniéndose para ayudarlo a superarlo. Si no lo hacen, pedir ayuda. Lo más que hay que decir después es: ¿qué podemos aprender de ello?
Dicen que un matrimonio exitoso se basa en tres pequeñas palabras: "Me equivoqué".
Si alguien no comete un error ocasional, no está trabajando, pero un error del que uno no aprende es dos errores.
La mejor disculpa es arreglar la ruptura rápidamente
Si su compañía ya tiene una forma de probar los cambios de compilación, entonces (A) sus cambios fallaron (pero los registró de todos modos) o (B) tuvieron éxito (y necesita crear un nuevo caso de prueba).
Si sus colegas prueban sus cambios con cautela y esperan encontrar descansos en la construcción nocturna, entonces (C) tiene un proceso frágil (y necesita introducir pruebas como las que se encuentran en la Programación Extrema).
Es posible que (D) Sus cambios hayan causado cambios imprevistos en el código de Bill que estaban vigentes antes o que se modificaron en la misma versión que la suya.
Dependiendo de cómo pruebes tú y tu compañía, me disculparía caso por caso:
Estoy seguro de que hay una (E) que no he pensado.
Observe que estoy diciendo "para reducir la posibilidad de reaparición" en lugar de "para que no vuelva a ocurrir". Ocurrirá de nuevo. Pero puedes mejorar tu proceso para reducir esa posibilidad. Eso, creo, es una de las marcas de un programador ganador.
No te disculpes. Eres humano y cometerás errores. Todos romperán la compilación de vez en cuando, la clave es simplemente arreglarlo rápidamente.
En cuanto a las personas que saltan sobre ti ... bueno, tengo curiosidad por saber si alguna vez escribieron un error.
La forma de abordar esto depende de la atmósfera de su grupo. Si se trata de una cultura de la culpa, sería muy cuidadoso con las disculpas y cómo lo haces. Si se trata de una atmósfera positiva y de colaboración, entonces sí, algo así como "Me equivoqué, lo siento. ¿Cómo podemos evitar esto en el futuro?" Probablemente sea una buena idea.
En cualquier caso, un error como este debe ir acompañado de algún tipo de autopsia para a) averiguar cómo sucedió yb) cómo minimizar las posibilidades de que vuelva a suceder.
No estoy familiarizado con su estructura (trabajo en un entorno muy diferente) pero, en última instancia, la realidad es que, ocasionalmente, la gente comete errores y las cosas se rompen. Aprendes de la experiencia y sigues adelante.
En mi entorno, si rompes la construcción, obtendrás un nervio de buen carácter y algún ingenioso cometario. No estoy seguro de en qué país de habla inglesa está involucrado, pero podría ser que, como un hablante no nativo de inglés, no está obteniendo la naturaleza subyacente de los comentarios.
Siendo del otro lado como desarrollador Senior, una vez comenté en una revisión de código que alguna forma de hacer x "apestaba" no porque el código fuera malo sino que afectara la estructura del proyecto. Fue más un comentario para mí mismo que necesito solucionar el problema estructural. Sólo más tarde descubrí que el Jr Dev, aunque estaba muy enojado con él debido a mi inexacto discurso frívolo.
Um. Obtienes el token de compilación roto . Pasa la rabia al siguiente afortunado receptor. Pasa todo el tiempo. La calidad es importante, pero los errores son inevitables. Arreglalos. Siga adelante. Lástima el próximo pobre tío.
Como regla general, diría:
Si su registro de entrada provoca un error de compilación, se habría sorprendido si hubiera hecho un "último envío" antes de registrarse, un "simple, mi error" está en orden. (especialmente si paseas a las 10 de la mañana del día siguiente, mientras todos deciden a qué grupo de cambios se revertirá)
Si su registro provoca un comportamiento inesperado general, incluso errores de tiempo de ejecución, no creo que deba ser contra usted. Viene con el territorio. Siempre y cuando todo el mundo "obtenga lo último" supera a sus compiladores, la gente realmente no debería estar lanzando un ajuste (con un par de excepciones, como eliminar una base de datos, eliminar la copia del proyecto del servidor y todos los conjuntos de cambios) , o cualquier otra cosa que sea tan tonta que la gente tenga que asumir intenciones maliciosas).
El EQUIPO falló.
Su compañía necesita más revisión de código en un desarrollador que realiza una compilación por primera vez.
Simplemente no veo cómo un equipo permite que esto continúe sin que hagan una revisión y ofrezcan algunas garantías en el camino de que estás haciendo las cosas correctamente.
Estar cerca del tiempo de lanzamiento no es una excusa, sino una mejor razón para volver a verificar el nuevo código.
Si su lanzamiento no se puede deshacer fácilmente, hay problemas aún mayores con este grupo.
No entiendo por qué la gente está sobre ti. Si el sistema está bien configurado, debería poder realizar cambios / solucionarlos muy rápidamente.
Pero una vez más, si eres uno de esos tipos que rompieron la construcción de ventanas, entonces ... no puedo ayudarte. (Es increíblemente difícil hacerlo por cierto, antes de que alguien cuestione la filosofía de MS, pero de vez en cuando alguien lo hace, y todo el control de calidad de la empresa se detiene por un día).
Y sí, no te disculpes. Simplemente converse con su gerente y hágale entender que aprendió de lo que ha hecho.
Las construcciones rompen todo el tiempo. Los errores y errores son un hecho de la vida, y es por eso que debe tener un proceso que minimice los efectos de errores y errores.
Si una ruptura de una compilación es tan importante, significa que tu proceso está roto.
Debes estar haciendo compilaciones continuas, no compilaciones nocturnas.
Mejor respuesta tardía que nunca ...
Como muchos otros han dicho, no te disculpes por romper la construcción. Simplemente admite que fuiste tú y continúa con el trabajo. Esto sucedería si estuvieras allí o no, y nadie merece ser tratado mal por eso. Las personas reaccionan mal bajo presión, por lo que si puede mantener la calma y simplemente continuar con el trabajo, se destacará cuando sea importante. Mi consejo para cuando la gente te da un mal rato es simplemente evitar estar a la defensiva, desactivar la situación haciéndole saber a la gente que tienes un problema o si buscas un consejo rápidamente si descubres que te has estancado.
Personalmente, veo una construcción rota como una oportunidad.
Entonces, lo que digo es que romper la construcción en ocasiones significa que las personas están haciendo su trabajo. Seguro que puede haber cometido un error, pero si lo usa como una oportunidad para aprender, está haciendo su trabajo simplemente aprendiendo a hacerlo mejor la próxima vez.
Dígales que necesitan compilaciones de CI por registro. De esa manera no tendrías que esperar hasta la noche para saber que está roto. ¡¡¡SÍ!!! Dígales que es el proceso lo que está mal, nada más. Acaba de identificar una brecha en su sistema.
Pero sí, asegúrate de arreglarlo. No es un gran trato. No está en producción. Sólo una noche sin valor.
Una práctica habitual en mi empresa es:
Mi compañía también tiene una buena manera de manejar un "incidente" de este tipo:
No me disculparía.
Culparía al líder de CI por permitirme cometer compilación rota.
Debe haber un proceso de CI implementado para evitar que los desarrolladores cometan códigos rotos.
Si la compilación local falla, no se debe permitir que ingrese al servidor de compilación.
Aunque creo que puede haber algún tipo de disculpa, no digas: "Me aseguraré de que esto no vuelva a ocurrir" Porque lo hará. Y si lo hace, te morderá.
Si está trabajando en un proyecto de código abierto,
solo di "Lo siento, rompí la construcción. ¡Tal vez tenía demasiado sueño!"
y agrégalo como un comentario de github.
Se debe a que muchos desarrolladores de código abierto escriben código durante la medianoche.
Lea otras preguntas en las etiquetas builds continuous-integration release