Cómo disculparte cuando has roto la compilación nocturna [cerrada]

Mi primer compromiso en mi proyecto resultó en la ruptura de la construcción nocturna y la gente está sobre mí cuando nos acercamos al lanzamiento. Quiero enviar un correo electrónico de disculpa que debería sonar sincero y al mismo tiempo insinuar que este fue mi primer compromiso y que esto ya no se repetiría.

Al ser un hablante de inglés no nativo, tengo dificultades para encontrar las palabras correctas. ¿Puede ayudarme alguien, por favor?

¡No te disculpes!

• Romper la construcción una vez en una luna azul no es un gran problema, y ​​nunca debería ser un obstáculo para el espectáculo.
• Es culpa de su gerente no configurar configuraciones continuas y automatizadas.

Además, apuesto a que su equipo no pasa la 'Prueba de Joel' y no puede construir en un solo paso.

Si es así, esta sería otra cosa por la que no debería disculparse. De hecho, es un equipo anti-patrón.

Bagels. Donuts Etc. En una empresa para la que trabajé en el pasado, el registro de código roto o la interrupción de un colega generalmente se resuelve al traer alimentos de disculpa al día siguiente.

Un día, un tipo eliminó 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 para el almuerzo.

Me encantan las disculpas de mis compañeros de trabajo. Sabrosas, sabrosas disculpas.

Dos citas para ti:

El hombre que no comete errores no suele hacer nada .-- William Connor Magee

Quien no comete errores no se está esforzando lo suficiente .-- Wess Roberts

Estoy de acuerdo con Jim G. , no te disculpes, pero aprende de él y no vuelvas a cometer el mismo error ... mantenlo SECO;)

No te disculpes, solo FIJALO lo antes posible. Sin embargo, está bien, todos rompen la construcción al menos una vez, en mi última compañía fue algo así como un ritual de iniciación. Cuando un miembro del equipo rompió la construcción, pondríamos un patito de goma en su escritorio en la mañana antes de que entrara, esto le hizo saber que rompió la construcción y lo arreglaría.

Lo llamamos el Duckie de Integración Continua y cuando lo tenías por el día la gente se burlaba de ti, pero todo era divertido, se suponía que nada de eso era malhumorado.

Tomamos algo así como una construcción rota y la convertimos en un ejercicio de trabajo en equipo.

"¡Disculpa, me equivoqué!" así es como normalmente me disculpo 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 la construcción tan fácilmente 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:

• Expresar arrepentimiento.
• Plantear el problema.
• Asumir la responsabilidad
• Compensar.
• Guardar cara.

Es decir, "lo siento [EXPRESS RECRET] por haberte incomodado [TOMA LA RESPONSABILIDAD] accidentalmente [SAVE FACE] rompiendo la compilación [DECLARAR EL PROBLEMA]. Donuts están conmigo mañana. [HACER LAS ENMIENDAS]"

Cada parte es necesaria en una disculpa adecuada; Si no indica el problema, entonces no está claro. Si no expresas arrepentimiento, asumes la responsabilidad y haces las paces, entonces la gente siente que no eres sincero. La parte que salva la cara es la parte más olvidada de una disculpa; La parte que salva la cara es lo que le recuerda a la parte lesionada que eres un compañero de trabajo valioso que a veces comete errores, y no un idiota (¡o un saboteador!)

Finalmente, algunas ideas sobre la ruptura de compilación:

Trabajo en el equipo compilador de C # / Visual Basic. Por supuesto, hoy Visual Studio es ahora un proyecto tan enorme 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 un pasante, yo, 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 sanciones por romper la construcción. En algunos equipos, la penalización 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 rompiera la construcción. En algunos equipos, si usaba ese sombrero, era responsable de verificar que la construcción nocturna fuera correcta.

Eso último suena cruel, pero en realidad sirvió para un propósito valioso. Como casi todos rompieron la compilación en un momento u otro, eventualmente todo el equipo aprendería los procesos para verificar la compilación nocturna.

No te disculpes. Son sus compañeros de trabajo quienes tienen la culpa de no revisar su primer compromiso y no tener un sistema de retroalimentación rápida para compilaciones como un servidor de integración continua.

En mi trabajo actual, tenemos una regla informal de que alguien que se comete furtivamente justo antes de salir del trabajo y resulta que rompe la construcción tiene que traer dulces / pasteles / bebidas para todo el equipo al día siguiente. Pero 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 disculpa es probablemente demasiado.

Una regla fundamental: cuando esté equivocado, ADMÍTELO: - | No tienes que disculparte. Todos cometemos errores. Los profesionales lo admiten. Eso es trabajo en equipo. Los otros miembros del equipo deberían unirse para ayudarlo a superarlo. Si no lo hacen, PIDA ayuda. Lo más que hay que decir después es: ¿qué podemos aprender de él?

Dicen que un matrimonio exitoso se basa en tres pequeñas palabras: "Me equivoqué".

Si alguien no comete un error ocasional, no está funcionando, pero un error del que uno no aprende es dos errores.

La mejor disculpa es arreglar el descanso rápidamente

Si su empresa ya tiene una forma de probar sus cambios de compilación, (A) sus cambios fallaron (pero los revisó de todos modos) o (B) tuvieron éxito (y necesita construir un nuevo caso de prueba).

Si sus colegas prueban con cautela sus cambios y esperan encontrar pausas 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 causaron cambios imprevistos en el código de Bill que estaban en su lugar antes o cambiaron en la misma compilación que la suya.

Dependiendo de cómo usted y su empresa evalúen, me disculparía caso por caso:

• (A) Fallé la prueba de compilación pero verifiqué mis cambios. Lo siento, estoy cambiando mi proceso, así que no lo volveré a hacer.
• (B) Pasé la prueba de compilación y agregué la prueba JUnit XYZtest.java para reducir la posibilidad de que vuelva a ocurrir.
• (C) Como no tenemos un proceso de prueba de compilación, estoy creando uno para mis cambios. Me gustaría compartir con ustedes cómo podemos mejorar nuestro proceso de compilación.
• (D) Trabajaré con Bill para escribir una prueba JUnit XYZtest.java para reducir la posibilidad de que vuelva a ocurrir.

Estoy seguro de que hay una (E) en la que no he pensado.

Tenga en cuenta que estoy diciendo "para reducir la posibilidad de que vuelva a ocurrir" en lugar de "para que no vuelva a suceder". Sucederá de nuevo. Pero puede mejorar su proceso para reducir esa posibilidad. Esa, 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 solucionarla rápidamente.

En cuanto a las personas que saltan sobre ti ... bueno, tengo curiosidad por saber si alguna vez han escrito en un error.

Cómo abordar esto depende de la atmósfera en su grupo. Si se trata de una cultura de la culpa, tendré mucho cuidado al pedir disculpas y cómo lo haces. Si se trata de una atmósfera colaborativa y positiva, entonces sí, algo parecido a "Me equivoqué, lo siento. ¿Cómo podemos evitar esto en el futuro?" Es probablemente una buena idea.

En cualquier caso, una tontería como esta debería ir acompañada 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, las personas cometen errores y las cosas se rompen. Aprendes de la experiencia y sigues adelante.

En mi entorno, si rompías la construcción, obtendrías un buen nervio y algún cometario ingenioso. No estoy seguro de en qué país de habla inglés estás, pero podría ser que, como hablante no nativo de inglés, no entiendas la naturaleza subyacente de los comentarios.

Siendo del otro lado como desarrollador sénior, 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 para la estructura del proyecto. Fue más comentario para mí que necesito arreglar el problema estructural. Solo más tarde descubrí que el Jr Dev, aunque estaba muy enojado con él debido a mi discurso impreciso e inexacto.

Um. Obtienes el token de construcción roto . Pase la rabia al próximo destinatario afortunado. Pasa todo el tiempo. La calidad es importante, pero los errores son inevitables. Arreglalos. Siga adelante. Avergonzar al próximo pobre tipo.

Como regla general, diría:

Si su registro causa un error de compilación, se habría sorprendido si hubiera hecho un "obtener la última" antes de registrarse, un simple "¡vaya! (especialmente si camina a las 10 de la mañana del día siguiente, mientras todos deciden a qué conjunto de cambios volver)

Si su registro provoca un comportamiento inesperado general, incluso errores de tiempo de ejecución, no creo que deba ser tomado en su contra. Viene con el territorio. Siempre y cuando todo el mundo "obtenga la última versión" generalmente pase sus compiladores, la gente realmente no debería lanzar un ajuste (con un par de excepciones, como eliminar una base de datos, eliminar la copia del servidor del proyecto y todos los conjuntos de cambios, o cualquier otra cosa que sea así) tonto que la gente tenga que asumir intenciones maliciosas).

El equipo falló.

Su empresa 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, pero es una mejor razón para 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ían poder descifrar sus cambios / corregirlos muy rápidamente.

Pero de nuevo, si eres uno de esos tipos que rompieron la construcción de Windows, entonces ... no puedo evitarlo. (Es increíblemente difícil de hacer por cierto, antes de que alguien cuestione las filosofías de construcción de la EM, pero de vez en cuando alguien lo hace, y el control de calidad de toda la compañía se detiene por un día).

Y sí, no te disculpes. Simplemente hable con su gerente y hágale entender que aprendió de lo que ha hecho.

Las construcciones se rompen todo el tiempo. Los errores y errores son una realidad, y es por eso que debe tener un proceso que minimice los efectos de errores y errores.

Si una ruptura de compilación es tan importante, significa que su proceso está roto.

Debería estar haciendo compilaciones continuas, no compilaciones nocturnas.

Mejor una respuesta tardía que nunca ...

Como muchos otros han dicho, no te disculpes por romper la construcción. Simplemente admite que eras tú y sigue con el trabajo. Esto sucedería si estuvieras allí o no, y nadie merece ser maltratado 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 haga pasar un mal rato es simplemente evitar estar a la defensiva, calmar la situación haciéndole saber a la gente que estás en el problema o que buscas consejo rápidamente si te encuentras atascado.

Personalmente, veo una construcción rota como una oportunidad.

• Si la compilación se rompe y puede probar que es su culpa, entonces es probable que muestre que la integración continua y los procesos de compilación están haciendo su trabajo. Esto es algo bueno, ya que valida sus procesos. Si la compilación nunca se rompe, me preocuparía que hubiera algo mal.
• Si ha roto la compilación de una manera bastante común, y sucede que se rompe de esta manera a menudo, entonces quizás falta algo en el proceso de CI. Esta es una oportunidad para mejorar sus procesos para que los escenarios de falla comunes se puedan administrar mejor.
• Si ha ido más allá del deber y realmente ha estropeado la construcción con un oscuro problema, entonces tiene la oportunidad de aprender sobre algo nuevo que podría ser lo suficientemente importante como para provocar una advertencia para el resto del equipo.

Entonces, lo que digo es que romper la construcción ocasionalmente 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Í!!! Diles que es el proceso lo que está mal, nada más. Acabas de identificar una brecha en su sistema.

Pero sí, asegúrate de arreglarlo. No es un gran trato. No está en producción. Solo una noche sin valor.

Una práctica habitual en mi empresa es:

• Gritando "¡no fui yo!" (generalmente pruebas CVS / SVN de lo contrario)
• Usando una camiseta que dice "my-userlogin ist Schuld!" (sí, el 50% de la propia camiseta de nuestro desarrollador)
• Afirmando que funciona en el sendbox local y que todas las pruebas pasaron bien

Mi compañía también tiene una buena manera de manejar un "incidente" como este:

• El trabajador debe usar el siguiente disfraz durante medio día ( http://www.tradoria.de/kostueme/kruemelmonster-sesamstrasse-kostuem-kruemelkostuem-337103661.html )

• No me disculparía

• Culparía al líder de CI por permitirme cometer una compilación rota.

• Debe haber un proceso de CI para evitar que los desarrolladores cometan código roto.

• Si la compilación local falla, no se debe permitir que ingrese al servidor de compilación.

Si bien creo que puede haber algún tipo de disculpa, por favor no diga: "Me aseguraré de que esto no vuelva a suceder". Porque lo hará. Y si lo hace, te morderá.

Si está trabajando en un proyecto de código abierto,

solo diga "Lo siento, rompí la compilación. ¡Quizás tenga demasiado sueño!"

y agregarlo como un comentario de github.

Esto se debe a que muchos desarrolladores de código abierto escriben código durante la medianoche.