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

181

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?

rajachan
fuente
99
Si la compilación nunca se rompiera, comenzaría a sospechar un proceso de compilación dañado;)
Lázaro
66
¿Cómo ibas a saber que la construcción estaba rota?
65
Qué tal: "Siento mucho romper la construcción nocturna. Si quieres retener mi salario como forma de castigo, no llevaré a la empresa al tribunal de empleo". No, es broma, no te disculpes, este tipo de cosas pasan todo el tiempo. Las personas que están "sobre ti" son unos psicópatas que no saben cómo restaurar adecuadamente el sistema al estado anterior.
Jas
14
¡Rompí la compilación en mis primeros 10 commits! No te preocupes por eso
Nadie
135
Solo desearía tener una construcción nocturna para romper ..
Max

Respuestas:

306

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

Jim G.
fuente
31
+1 de acuerdo! No te disculpes. APRENDE lo que hiciste mal. No lo vuelvas a hacer, al menos no antes. Sé cortés cuando la gente esté "sobre ti". Aprende de lo que dicen (incluso si es solo un imbécil y quién está bien).
Peter K.
12
Bueno, aún puedes disculparte ... Pero estoy un poco sorprendido de que la gente esté sobre ti. Si eres nuevo en el equipo, no debería ser una sorpresa que hayas cometido un error. Al menos muestra que hiciste algo :)
Philippe
40
+1. El propósito de hacer una construcción nocturna es detectar los problemas lo antes posible y antes de que salgan con un lanzamiento. El 95% de los desarrolladores han cometido errores de alta visibilidad durante sus carreras. El otro 5% está mintiendo.
Blrfl
26
Si bien estoy de acuerdo en que esto no exige una disculpa de nivel de "caer sobre la espada", creo que sí requiere una disculpa de nivel de "¡Uy, mi mal!". No todos los "lo siento" deben ser abyectos.
Matthew Scouten
55
No estoy de acuerdo con esta premisa en absoluto, no hay nada de malo con una simple disculpa de "lo siento", me doy cuenta de que me equivoco y haré todo lo posible para aprender de mi error . Estoy de acuerdo en que la mejor manera de * enmendarse * es no hacerlo de nuevo, pero si te importa, es posible que no quieras mostrarlo abiertamente para que los demás lo sepan, no cada vez que te equivocas, pero claramente se sintió mal por y no hay nada de malo en disculparse.
Trufa
182

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.

Dan Ray
fuente
83
+1 para "Me encantan las disculpas de compañeros de trabajo. Sabrosas, sabrosas disculpas".
Jas
32
Romper la construcción de desarrollo nocturno es una cosa, pero eliminar la base de datos de producción está en un nivel completamente diferente. Si alguna vez hice eso, desearía que asar hamburguesas fuera el peor de mis castigos.
maple_shaft
20
Casi puedes saborear la culpa.
Mike Speed
40
"Soplar una base de datos de producción" pone todo tipo de imágenes hilarantes en mi cabeza sobre lo que sucedió exactamente con la base de datos. La mayoría de ellos involucran a todos escuchando una fuerte explosión desde la sala de servidores. "¡Oh Dios, la base de datos está alcanzando un volumen crítico!" "¡Rápido! ¡Baja las barras de control!" "Es demasiado tarde, los datos, ella está condenada!" BOOM
Carson Myers
77
drop database... Oh, el poder de esas dos pequeñas palabras. Fue hace años, pero lo recuerdo bien;)
Leigh
80

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

Lázaro
fuente
99
O hay una cita más general de: "deja que el que no tiene pecado arroje la primera piedra" Si quien alguna vez está gimiendo por la construcción rota ha roto la construcción antes, no debería estar gimiendo
Richard
como el segundo !!
Sufendy
1
Citando a mí mismo a cada graduado / secundaria que he mentor nunca, "I expect you to make lots of mistakes. Own up to them, accept them, and learn from them. If you never make mistakes, you'll never really learn anything".
S.Robins
Buen uso del principio "DRY" ... :)
J. Allan
53

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.

eje de arce
fuente
2
+1: no solo lo que les importa, sino todo lo que deberían importarles. No ha hecho nada malo, como tal, simplemente flexionó demasiado los límites de lo que es posible;). Probablemente también sea la persona mejor posicionada para solucionarlo. Todos hacen esto de vez en cuando. Todos cargan algo para vivir que no debería haberse ido. Todos dejan la cláusula WHERE de una declaración de ACTUALIZACIÓN una vez en sus vidas. Lo importante es cómo reaccionas. Donde estamos, todos los desarrolladores tienden a cerrar, negándose a hablar sobre quién tuvo la culpa individualmente si alguien pregunta, simplemente se arregla.
Tom Morgan
Eso parece como una muy buena manera de manejar errores.
Trufa
3
Integración continua Duckie , Jajajaja
AttackingHobo
43

"¡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.

Eric Lippert
fuente
15

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.

guillaume31
fuente
Excelente punto: la revisión por pares debería haber captado esto. Debido a que hagas revisar los cambios de pares antes de que sean aplicados a maestro / cabeza / por defecto, ¿verdad?
Frank Shearar
11

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.

Mike Dunlavey
fuente
Creo que esta es una gran respuesta y mucho mejor que la de "No te disculpes" que tiene los votos más altos. Puedes disculparte con todos por romper la compilación, pero también deben mostrarte un poco de gracia. También deberían decir "no te preocupes, todos lo hemos roto antes, después de todo, para eso está". Mientras trates de no romperlo de nuevo, deberían ser geniales con eso. Si ignoras a todos y haces el mismo error, esa es una historia diferente.
Rocklan
6

La mejor disculpa es arreglar el descanso rápidamente

JaredPar
fuente
5

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.

rajah9
fuente
2

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.

Corv1nus
fuente
2

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.

temptar
fuente
2

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.

repetición
fuente
2

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.

M. Tibbits
fuente
1
He visto esto mucho. La otra es que puedes "cuidar" la construcción nocturna hasta que alguien más la rompa. Esto no significa arreglarlo, sino descubrir por qué y quién debería arreglarlo.
Stephen Darlington
1

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

Morgan Herlocker
fuente
1

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.

JeffO
fuente
0

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.

Subu Sankara Subramanian
fuente
0

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.

Christoffer Hammarström
fuente
+1 para "si una ruptura de compilación es tan importante, significa que su proceso está roto". Por otro lado, todavía tiene que lidiar con el proceso interrumpido, y eso significa hacer lo que pueda para evitar romper la compilación nocturna hasta que se mejore el proceso.
Caleb
0

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.

S.Robins
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Í!!! 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.

Issa Fram
fuente
-2

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:

Robert Heine
fuente
-2
  • 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.

CodeART
fuente
1) No todos los proyectos están configurados para realizar una integración continua. Es bueno tenerlo y puede ayudar con situaciones como los OP, pero está lejos de ser un hecho. 2) Nunca está de más pedir disculpas, incluso cuando no es realmente un gran problema, incluso cuando hay herramientas que podrían haber evitado el problema. 3) Culpar a alguien más por un problema que usted causó, sea o no realmente su culpa, es una mala idea.
Caleb
Aquí hay dos problemas: 1: código roto en la máquina local. 2: código roto en un servidor de compilación. El primer problema es muy pequeño ya que todos los desarrolladores cometen errores. Los cambios se pueden deshacer y no habrá impacto en el sistema o el departamento. Es probable que el segundo problema tenga un impacto negativo mucho mayor en el sistema y el departamento.
CodeART
-2

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

Pieter B
fuente
-2

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.

linquizar
fuente