Cómo disculparse cuando rompió la compilación nocturna [cerrado]

180

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?

    
pregunta rajachan 25.11.2016 - 14:42
fuente

23 respuestas

305
  

¡No discúlpate!

  • Romper la construcción una vez en una luna azul no es un gran problema, y nunca debe ser un show stopper.
  • Es culpa de su administrador no configurar configuraciones automáticas continuas.

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.

    
respondido por el Jim G. 26.05.2011 - 10:00
fuente
182

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.

    
respondido por el Dan Ray 25.05.2011 - 14:36
fuente
79

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;)

    
respondido por el Lazarus 12.04.2017 - 09:31
fuente
53

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.

    
respondido por el maple_shaft 25.05.2011 - 13:51
fuente
43

"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:

  • Expresar arrepentimiento.
  • Indica el problema.
  • Asume la responsabilidad.
  • Hacer enmiendas.
  • Guardar cara.

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.

    
respondido por el Eric Lippert 25.05.2011 - 18:33
fuente
15

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.

    
respondido por el guillaume31 25.05.2011 - 14:42
fuente
10

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.

    
respondido por el Mike Dunlavey 25.05.2011 - 15:00
fuente
6

La mejor disculpa es arreglar la ruptura rápidamente

    
respondido por el JaredPar 25.05.2011 - 17:37
fuente
5

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:

  • (A) Fallé la prueba de compilación pero verifiqué mis cambios. Lo siento, estoy cambiando mi proceso para no volver a hacerlo.
  • (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 construcción.
  • (D) Trabajaré con Bill para escribir una prueba de JUnit XYZtest.java para reducir la posibilidad de que vuelva a ocurrir.

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.

    
respondido por el rajah9 25.05.2011 - 20:34
fuente
2

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.

    
respondido por el Corv1nus 25.05.2011 - 14:25
fuente
2

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.

    
respondido por el temptar 25.05.2011 - 15:47
fuente
2

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.

    
respondido por el rerun 25.05.2011 - 16:05
fuente
2

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.

    
respondido por el M. Tibbits 26.05.2011 - 07:17
fuente
1

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).

    
respondido por el Morgan Herlocker 25.05.2011 - 21:01
fuente
1

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.

    
respondido por el JeffO 07.05.2012 - 16:50
fuente
0

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.

    
respondido por el Subu Sankara Subramanian 25.05.2011 - 14:10
fuente
0

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.

    
respondido por el Christoffer Hammarström 25.05.2011 - 16:23
fuente
0

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.

  • Si la compilación se rompe y usted puede demostrar 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 algún problema.
  • Si ha roto la compilación de una manera bastante común, y sucede que se rompe de esta manera a menudo, tal vez falte algo en el proceso de CI. Esta es una oportunidad para mejorar sus procesos para que los escenarios de fallas comunes puedan administrarse mejor.
  • Si ha superado el deber y realmente ha arruinado la compilación con un problema oscuro, entonces tiene la oportunidad de aprender algo nuevo que podría ser lo suficientemente importante como para provocar una advertencia al resto del equipo.

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.

    
respondido por el S.Robins 07.05.2012 - 01:50
fuente
-1

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.

    
respondido por el Issa Fram 27.05.2011 - 04:48
fuente
-2

Una práctica habitual en mi empresa es:

  • Gritando "¡No fui yo!" (normalmente pruebas CVS / SVN de lo contrario)
  • ¡Usando una camiseta que dice "my-userlogin ist Schuld!" (sí, el 50% de la propia camisa de nuestro desarrollador)
  • Afirmando que funciona en el buzón de envío local y que todas las pruebas pasaron muy bien

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

  • El trabajador tiene que usar el siguiente traje durante medio día ( enlace )
respondido por el Robert Heine 26.05.2011 - 12:50
fuente
-2
  • 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.

respondido por el CodeART 07.05.2012 - 01:02
fuente
-2

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á.

    
respondido por el Pieter B 07.05.2012 - 12:47
fuente
-2

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.

    
respondido por el linquize 14.05.2013 - 05:36
fuente

Lea otras preguntas en las etiquetas