Jak przeprosić, gdy złamałeś nocną wersję [zamkniętą]

181

Moje pierwsze zatwierdzenie w moim projekcie spowodowało zepsucie nocnej kompilacji i ludzie są wokół mnie, gdy zbliżamy się do wydania. Chcę wysłać wiadomość e-mail z przeprosinami, która powinna brzmieć szczerze, a jednocześnie sugeruje, że to był mój pierwszy zatwierdzenie i że nie będzie już więcej powtarzane.

Ponieważ nie jestem rodzimym językiem angielskim, mam trudności z wymyśleniem poprawnych słów. Czy ktoś może pomóc?

rajachan
źródło
99
Jeśli kompilacja nigdy się nie złamie, zacznę podejrzewać proces zepsutej kompilacji;)
Łazarz
6
Skąd miałeś wiedzieć, że kompilacja została zepsuta?
65
Co powiesz na: „Bardzo mi przykro z powodu przerwania nocnej kompilacji. Jeśli chcesz zrezygnować z mojej pensji jako formy kary, nie wezmę firmy do trybunału pracy”. Nie, żartuję - nie przepraszaj, takie rzeczy zdarzają się cały czas. Ludzie, którzy są „po tobie”, są psychologami, którzy nie wiedzą, jak prawidłowo przywrócić system do poprzedniego stanu.
Jas
14
Zerwałem wersję na pierwszych 10 zmianach! Nie martw się tym
Nikt
135
Po prostu żałuję, że nie miałem nocnej wersji do złamania.
Max

Odpowiedzi:

306

Nie przepraszaj!

  • Przełamanie kompilacji raz na niebieskim księżycu nie jest wielką sprawą i nigdy nie powinno być przeszkodą.
  • To wina menedżera, że ​​nie konfigurował ciągłych, automatycznych kompilacji.

Założę się również, że twoja drużyna nie zdała testu Joela i nie może wykonać kompilacji w jednym kroku.

Jeśli tak, to kolejna rzecz, za którą nie powinieneś przepraszać. Rzeczywiście, jest to anty-wzór zespołu.

Jim G.
źródło
31
+1 Zgoda! Nie przepraszaj DOWIEDZ SIĘ, co zrobiłeś źle. Nie rób tego więcej, przynajmniej nie wkrótce. Bądź grzeczny, gdy ludzie są „po tobie”. Ucz się na podstawie tego, co mówią (nawet jeśli to tylko kutas, a kto OK).
Peter K.,
12
Nadal możesz przeprosić ... Ale jestem nieco zaskoczony, że ludzie są wokół ciebie. Jeśli jesteś nowy w zespole, nie powinno być zaskoczeniem, że popełniłeś błąd. Przynajmniej pokazuje, że coś zrobiłeś :)
Philippe
40
+1. Głównym celem nocnej kompilacji jest wychwycenie problemów tak wcześnie, jak to możliwe, zanim wypłyną z wydaniem. 95% programistów popełniło błędy w widoczności podczas swojej kariery. Pozostałe 5% kłamie.
Blrfl,
26
Chociaż zgadzam się, że nie wymaga to przeprosin na poziomie „upadku na miecz”, myślę, że wymaga przeprosin na poziomie „ups, my bad”. Nie każde „przepraszam” musi być obelżywe.
Matthew Scouten
5
W ogóle nie zgadzam się z tym założeniem, nie ma nic złego w zwykłych przeprosinach „przepraszam”, zdaję sobie sprawę, że spieprzę i dołożę wszelkich starań, aby wyciągnąć wnioski z mojego błędu . Zgadzam się, że najlepszym sposobem na * poprawienie * siebie samego nie jest zrobienie tego ponownie, ale jeśli cię to obchodzi, możesz nie chcieć otwarcie pokazywać tego innym, nie za każdym razem, gdy coś spieprzysz, ale najwyraźniej źle się czuł i nie ma nic złego w przepraszaniu.
Trufa
182

Bajgle Pączki Itd. W jednej firmie, w której pracowałem w przeszłości, sprawdzanie zepsutego kodu lub powodowanie zakłóceń w pracy kolegi zazwyczaj jest rozwiązywane przez przyniesienie przeprosin następnego dnia.

Pewnego dnia facet zdmuchnął bazę danych produkcji, powodując ogromną panikę i późną noc dla całego zespołu. Następnego dnia zjadł hamburgery na lunch.

Uwielbiam przeprosiny współpracowników. Smaczne, smaczne przeprosiny.

Dan Ray
źródło
83
+1 za „Uwielbiam przeprosiny współpracowników. Smaczne, smaczne przeprosiny”.
Jas
32
Przerwanie nocnej kompilacji deweloperów to jedno, ale zdmuchnięcie produkcyjnej bazy danych jest na zupełnie innym poziomie. Gdybym to zrobił, żałuję, że grillowanie hamburgerów nie było najgorszą z moich kar.
wałek klonowy
20
Możesz prawie poczuć winę.
Mike Speed
40
„Wysadzenie produkcyjnej bazy danych” umieszcza w mojej głowie wszelkiego rodzaju zabawne zdjęcia dotyczące tego, co dokładnie stało się z bazą danych. Większość z nich polega na tym, że wszyscy słyszą głośną eksplozję z serwerowni. „O Boże, baza danych osiąga krytyczną objętość!” „Szybko! Opuść pręty sterujące!” „Jest za późno, dane, jest skazana!” BOOM
Carson Myers
7
drop database... Och, moc tych dwóch małych słów. To było lata temu, ale dobrze to pamiętam;)
Leigh
80

Dwa cytaty dla Ciebie:

Człowiek, który nie popełnia błędów, zwykle nic nie robi. - William Connor Magee

Każdy, kto nie popełnia błędów, nie stara się wystarczająco mocno. - Wess Roberts

Zgadzam się z Jimem G. , nie przepraszaj, ale ucz się na tym i nie popełniaj tego samego błędu ponownie ... zachowaj SUCHOŚĆ;)

Lazarus
źródło
9
Albo jest bardziej ogólny cytat: „niech ten, kto jest bez grzechu, rzuci pierwszy kamień”. Jeśli ktokolwiek narzeka na zepsutą kompilację, wcześniej ją złamał, nie powinien narzekać
Richard
jak drugi !!
Sufendy
1
Cytowanie się do każdego Grad / Junior I kiedykolwiek mentorem, "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
Fajne zastosowanie zasady „OSUSZANIE” ... :)
J. Allan
53

Nie przepraszaj, po prostu USUŃ to tak szybko, jak to możliwe. Jest w porządku, wszyscy przynajmniej raz przerywają kompilację, w mojej ostatniej firmie było to coś w rodzaju rytuału inicjacyjnego. Kiedy członek zespołu złamał kompilację, kładliśmy gumowe kaczuszki na jego biurku rano, zanim on wszedł, to dało mu do zrozumienia, że ​​złamał kompilację i naprawi ją.

Nazywaliśmy to Duckie Continuous Integration, a kiedy miałeś go na dzień, kiedy ludzie cię droczyli, ale było wesoło, żadne z nich nie miało być złośliwe.

Wzięliśmy coś w rodzaju zepsutej kompilacji i przekształciliśmy w ćwiczenie budowania zespołu.

wałek klonowy
źródło
2
+1: nie tylko to, na czym im zależy - wszystko, na czym powinni dbać. Nie zrobiłeś nic złego jako takiego - po prostu zmieniłem granice tego, co jest możliwe, trochę za daleko;). Prawdopodobnie jesteś również osobą, która najlepiej umie to naprawić. Wszyscy robią to od czasu do czasu. Każdy przesyła coś do życia, co nie powinno zniknąć. Każdy raz w życiu opuszcza klauzulę WHERE z instrukcji UPDATE. Ważne jest to, jak reagujesz. Tam, gdzie jesteśmy, wszyscy deweloperzy mają tendencję do zamykania się, nie chcąc mówić o tym, kto indywidualnie był winny, jeśli ktoś zapyta, to po prostu naprawia się.
Tom Morgan
To wydaje się być naprawdę świetnym sposobem radzenia sobie z błędami.
Trufa
3
Continuous Integration Duckie , Hahahaha
AttackingHobo
43

"Przepraszam moja wina!" tak zwykle przepraszam, gdy zepsułem kompilację. Zdarza się. Ale jak powiedzieli inni, jest to okazja do ulepszenia systemów, aby jedna osoba nie mogła tak łatwo przerwać kompilacji dla wszystkich innych.

W tych okolicznościach nie składałbym formalnych przeprosin, ale jeśli faktycznie uważasz, że bardziej formalne przeprosiny są odpowiednie, przeprosiny powinny wykonać następujące czynności:

  • Wyraź żal.
  • Podaj problem.
  • Brać odpowiedzialność.
  • Zrekompensować.
  • Chroń twarz.

To znaczy: „Przykro mi [EXPRESS REGRET], że sprawiłem ci niedogodność [PODEJMUJ ODPOWIEDZIALNOŚĆ] przez przypadkowe [SAVE FACE] złamanie kompilacji [STATE THE PROBLEM]. Pączki są jutro na mnie. [POWIEDZIEĆ]”

Każda część jest niezbędna w odpowiednich przeprosinach; jeśli nie podasz problemu, to nie jest jasne. Jeśli nie wyrażasz żalu, nie bierzesz odpowiedzialności i nie zarabiasz, ludzie czują się, jakbyś był nieszczery. Część ratująca twarz jest najczęściej pomijaną częścią przeprosin; część oszczędzająca twarz przypomina poszkodowanemu, że jesteś cennym współpracownikiem, który czasem popełnia błędy, a nie idiotą (lub sabotażystą!)

Na koniec kilka przemyśleń na temat łamania kompilacji:

Pracuję w zespole kompilatorów C # / Visual Basic. Oczywiście dziś Visual Studio jest teraz tak ogromnym projektem, że ma własny zespół do zarządzania infrastrukturą i ogromną salę z własnym systemem klimatyzacji. W połowie lat 90., kiedy zaczynałem jako stażysta, zespół budujący Visual Basic był jednym stażystą - mną - i szafą pełną maszyn. Czasy się zmieniły!

W tamtych czasach przed ciągłą integracją i silnymi procesami meldowania zespoły miały różne kary za złamanie kompilacji. W niektórych zespołach karą było to, że jeśli złamałeś kompilację, musiałeś codziennie nosić zabawny kapelusz, dopóki ktoś inny nie złamał kompilacji. W niektórych zespołach, jeśli nosiłeś ten kapelusz, odpowiadałeś za sprawdzenie, czy wersja nocna była poprawna.

Ten ostatni kawałek może być okrutny, ale w rzeczywistości służył cennemu celowi. Ponieważ prawie wszyscy złamali kompilację w tym czy innym czasie, w końcu cały zespół poznałby procedury weryfikacji kompilacji nocnej.

Eric Lippert
źródło
15

Nie przepraszaj To twoi współpracownicy są winni za to, że nie sprawdzili twojego pierwszego zatwierdzenia i nie mieli systemu szybkiego sprzężenia zwrotnego dla kompilacji takich jak serwer ciągłej integracji.

W mojej obecnej pracy obowiązuje nieformalna zasada, że ​​ktoś, kto podstępnie popełnia tuż przed wyjściem z pracy i okazuje się, że chce przerwać kompilację, musi przynieść cukierki / ciastka / napoje całemu zespołowi następnego dnia. Ale mamy ciągłą integrację, która ostrzega nas o zepsutej kompilacji w ciągu dnia. I reguła prawdopodobnie nie miałaby zastosowania do pierwszego zatwierdzenia.

W każdym razie formalna poczta z przeprosinami to prawdopodobnie trochę za dużo.

guillaume31
źródło
Znakomity punkt - przegląd powinien był to zauważyć. Ponieważ dokonujesz zmian w recenzjach zanim zostaną one zastosowane do master / HEAD / default, prawda?
Frank Shearar
11

Podstawowa zasada - kiedy się mylisz, ZGADŹ SIĘ: - | Nie musisz żałować przeprosin. Wszyscy popełniają błędy. Profesjonaliści to przyznają. To praca zespołowa. Pozostali członkowie zespołu powinni się zjednoczyć, aby ci pomóc. Jeśli nie, ZAPYTAJ o pomoc. Najważniejsze, co należy potem powiedzieć, to - czego możemy się z tego nauczyć?

Mówią, że udane małżeństwo opiera się na trzech małych słowach - „Myliłem się”.

Jeśli ktoś nie popełnia sporadycznego błędu, nie działa, ale błąd, z którego się nie uczy, to dwa błędy.

Mike Dunlavey
źródło
Myślę, że to świetna odpowiedź i znacznie lepsza niż „Nie przepraszaj”, która ma najwięcej głosów. Możesz przeprosić wszystkich za złamanie kompilacji, ale muszą też okazać ci odrobinę wdzięku. Powinni też mówić: „nie martw się, wszyscy już to złamaliśmy, przecież po to jest to”. Tak długo, jak spróbujesz go nie złamać, powinni być z tym spoko. Jeśli zignorujesz wszystkich i popełnisz ten sam błąd, to inna historia.
Rocklan,
6

Najlepsze przeprosiny to szybkie naprawienie przerwy

JaredPar
źródło
5

Jeśli Twoja firma ma już sposób przetestować zmiany kompilacji, to (A) zmiany albo nie powiodły się (ale i tak je sprawdziłeś), albo (B) powiodły się (i musisz zbudować nowy przypadek testowy).

Jeśli twoi koledzy ostrożnie przetestują swoje zmiany i spodziewają się znaleźć przerwy w kompilacji nocnej, to (C) masz kruchy proces (i musisz wprowadzić testy podobne do tych, które można znaleźć w Extreme Programming).

Możliwe, że (D) Twoje zmiany spowodowały nieprzewidziane zmiany w kodzie Billa, które były albo wcześniej wprowadzone, albo zmienione na tej samej kompilacji co Twoja.

W zależności od tego, jak Ty i Twoja firma przeprowadzacie testy, przepraszam za każdym razem:

  • (A) Nie zdałem testu kompilacji, ale sprawdziłem zmiany. Przepraszam, zmieniam proces, więc nie będę tego więcej robić.
  • (B) Zdałem test kompilacji i dodałem test JUnit XYZtest.java, aby zmniejszyć ryzyko ponownego wystąpienia.
  • (C) Ponieważ nie mamy procesu testowania kompilacji, tworzę go dla moich zmian. Chciałbym się z Tobą podzielić, w jaki sposób możemy ulepszyć nasz proces kompilacji.
  • (D) Będę współpracować z Billem, aby napisać test JUnit XYZtest.java, aby zmniejszyć ryzyko ponownego wystąpienia.

Jestem pewien, że istnieje (E), o którym nie myślałem.

Zauważ, że mówię „w celu zmniejszenia szansy ponownego wystąpienia”, a nie „aby to się więcej nie powtórzyło”. To się powtórzy. Ale możesz ulepszyć swój proces, aby zmniejszyć tę możliwość. Myślę, że to jeden ze znaków zwycięskiego programisty.

rajah9
źródło
2

Nie przepraszaj Jesteś człowiekiem i popełniasz błędy. Wszyscy od czasu do czasu przerywają kompilację, kluczem jest szybkie naprawienie.

Jeśli chodzi o ludzi skaczących po tobie ... jestem ciekawy, czy kiedykolwiek napisali błąd.

Corv1nus
źródło
2

Sposób podejścia zależy od atmosfery w twojej grupie. Jeśli jest to wina obwiniana, byłbym bardzo ostrożny w przepraszaniu i jak to robisz. Jeśli jest to pozytywna atmosfera współpracy, to tak, coś w stylu „Zepsułem, przepraszam. Jak możemy tego uniknąć w przyszłości?” jest prawdopodobnie dobrym pomysłem.

W każdym razie takiemu głupkowi powinien towarzyszyć jakaś sekcja zwłok, aby a) dowiedzieć się, jak to się stało i b) jak zminimalizować szanse, że to się powtórzy.

Nie znam twojej struktury (pracuję w zupełnie innym środowisku), ale ostatecznie rzeczywistość jest taka, że ​​czasami ludzie popełniają błędy i rzeczy się psują. Uczysz się na podstawie tego doświadczenia i kontynuujesz.

kuszenie
źródło
2

W moim środowisku, jeśli złamiesz kompilację, dostaniesz dobre, naturalne żebrowanie i dowcipny kometar. Nie jestem pewien, w którym kraju anglojęzycznym jesteś, ale może się zdarzyć, że jako nie mówiący po angielsku nie dostaniesz podkreślającego charakteru komentarzy.

Będąc z drugiej strony jako starszy programista, kiedyś skomentowałem recenzję kodu, że jakiś sposób robienia x „jest do bani” nie dlatego, że kod był zły, ale do struktury projektu. To był bardziej komentarz do mnie, że muszę rozwiązać problem strukturalny. Dopiero później odkryłem, że Jr Dev był bardzo zły na niego z powodu mojej niedokładnej, nonszalanckiej mowy.

ponownie odtwarzać
źródło
2

Um. Dostajesz zepsuty żeton kompilacji . Przekaż wściekliznę następnemu szczęśliwemu odbiorcy. Dzieje się cały czas. Jakość jest ważna, ale błędy są nieuniknione. Napraw je. Pójść dalej. Wstyd kolejny biedny facet.

M. Tibbits
źródło
1
Dużo to widziałem. Drugim jest „opieka” nad nocną wersją, dopóki ktoś inny jej nie złamie. Nie oznacza to naprawy, ale zastanawianie się, dlaczego i kto powinien to naprawić.
Stephen Darlington
1

Zasadniczo powiedziałbym:

Jeśli Twoje zgłoszenie powoduje błąd kompilatora, złapałbyś się, gdybyś zrobił „dostać najnowszą” przed zalogowaniem, proste „ups, mój zły” jest w porządku. (szczególnie, jeśli następnego ranka wejdziesz o 10, a wszyscy decydują, do którego zestawu zmian należy przywrócić)

Jeśli Twoje zgłoszenie powoduje ogólne nieoczekiwane zachowanie, a nawet błędy w czasie wykonywania, nie sądzę, że powinno się to obciążyć. Przychodzi razem z terytorium. Tak długo, jak wszyscy „zdobywają najnowsze” zwykle przechodzą kompilatory, ludzie naprawdę nie powinni rzucać napadu (z kilkoma wyjątkami, takimi jak usunięcie bazy danych, usunięcie kopii serwera projektu i wszystkich zestawów zmian lub cokolwiek innego, co jest tak głupi, że ludzie muszą przyjmować złośliwe zamiary).

Morgan Herlocker
źródło
1

ZESPÓŁ nie powiódł się.

Twoja firma potrzebuje więcej recenzji kodu dla programisty wykonującego kompilację po raz pierwszy.

Po prostu nie rozumiem, w jaki sposób zespół pozwala, aby to trwało bez dokonywania przeglądu i oferowania pewnych gwarancji, że postępujesz właściwie.

Zbliżanie się do czasu wydania nie jest usprawiedliwieniem, ale lepszym powodem do dwukrotnego sprawdzenia nowego kodu.

Jeśli wydania nie da się łatwo cofnąć, z tą grupą są jeszcze większe problemy.

JeffO
źródło
0

Nie rozumiem, dlaczego ludzie są wokół ciebie. Jeśli system jest dobrze skonfigurowany, powinien być w stanie dokuczać twoim zmianom / naprawić je bardzo szybko.

Ale znowu, jeśli jesteś jednym z tych facetów, którzy złamali system Windows, to ... Nie mogę pomóc. (Jest to niezwykle trudne do zrobienia btw - zanim ktokolwiek zadaje pytania, stwardnienie rozsiane buduje filozofie, ale od czasu do czasu ktoś to robi - i cała kontrola jakości firmy zatrzymuje się na jeden dzień).

I tak - nie przepraszaj. Po prostu porozmawiaj z menedżerem i daj mu do zrozumienia, że ​​nauczyłeś się z tego, co zrobiłeś.

Subu Sankara Subramanian
źródło
0

Kompilacje cały czas się psują. Błędy i pomyłki są faktem i dlatego powinieneś mieć proces minimalizujący skutki błędów i pomyłek.

Jeśli łamanie kompilacji jest tak duże, oznacza to, że proces jest zepsuty.

Powinieneś robić ciągłe kompilacje, a nie kompilacje nocne.

Christoffer Hammarström
źródło
+1 dla „jeśli łamanie kompilacji jest tak duże, oznacza to, że proces jest zepsuty”. Z drugiej strony nadal musisz radzić sobie z uszkodzonym procesem, a to oznacza robienie wszystkiego, co możesz, aby uniknąć przerwania nocnej kompilacji, dopóki proces nie zostanie ulepszony.
Caleb
0

Lepsza późna odpowiedź niż nigdy ...

Jak wielu innych powiedziało, nie przepraszaj za złamanie kompilacji. Po prostu przyznaj, że to byłeś ty i zacznij pracę. Te rzeczy miałyby miejsce bez względu na to, czy tam byłeś, czy nie, i nikt nie zasługuje na to, aby być źle traktowanym z tego powodu. Ludzie źle reagują na presję, więc jeśli jesteś w stanie zachować spokój i po prostu kontynuować pracę, wyróżnisz się, gdy ma to znaczenie. Moja rada, gdy ludzie mają trudności, to po prostu unikanie obrony, rozbrajanie sytuacji poprzez informowanie ludzi, że masz problem lub szybko szukać porady, jeśli utkniesz.

Osobiście widzę zepsutą wersję jako szansę.

  • Jeśli kompilacja się zepsuje i udowodnisz, że to twoja wina, prawdopodobnie pokaże, że ciągłe procesy integracji i kompilacji wykonują swoje zadania. To dobra rzecz, ponieważ potwierdza twoje procesy. Jeśli kompilacja nigdy się nie psuje, martwię się, że coś jest z nią nie tak.
  • Jeśli złamałeś kompilację w dość powszechny sposób i zdarza się, że często tak się psuje, być może w procesie CI brakuje czegoś. Jest to okazja do usprawnienia procesów, aby lepiej zarządzać typowymi scenariuszami awarii.
  • Jeśli wykroczyłeś poza wezwanie do służby i naprawdę zepsułeś wersję z niejasnym problemem, masz okazję dowiedzieć się o czymś nowym, co może być wystarczająco ważne, aby wywołać ostrzeżenie dla reszty zespołu.

Mówię więc, że od czasu do czasu przerwanie kompilacji oznacza, że ​​ludzie wykonują swoją pracę. Pewnie popełniłeś błąd, ale jeśli wykorzystasz go jako okazję do nauki, wykonujesz swoją pracę po prostu ucząc się robić to lepiej następnym razem.

S.Robins
źródło
-1

Powiedz im, że potrzebują kompilacji CI przy odprawie. W ten sposób nie będziesz musiał czekać do wieczora, aby wiedzieć, że jest zepsuty. TAK!!! Powiedz im, że to proces jest zły, nic więcej. Właśnie zidentyfikowałeś lukę w ich systemie.

Ale tak, upewnij się, że to naprawisz. Żaden problem. Nie jest w produkcji. Po prostu bezwartościowa nocna.

Issa Fram
źródło
-2

Zwykłą praktyką w mojej firmie jest:

  • Krzycząc „to nie byłem ja!” (zwykle dowody CVS / SVN w innym przypadku)
  • W koszulce z napisem „my-userlogin ist Schuld!” (tak, 50% własnej koszuli naszego programisty)
  • Twierdzenie, że działa w lokalnej skrzynce wysyłkowej, a wszystkie testy przeszły dobrze

Moja firma ma również dobry sposób na poradzenie sobie z takim „incydentem”:

Robert Heine
źródło
-2
  • Nie przepraszam.

  • Zrzuciłbym winę CI za umożliwienie mi popełnienia zepsutej kompilacji.

  • Powinien istnieć proces CI, aby powstrzymać programistów przed popełnianiem uszkodzonego kodu.

  • Jeśli kompilacja lokalna zakończy się niepowodzeniem, nie powinno być dozwolone wchodzenie na serwer kompilacji.

CodeART
źródło
1) Nie wszystkie projekty są skonfigurowane do ciągłej integracji. Fajnie jest mieć i może pomóc w sytuacjach takich jak PO, ale nie jest to pewne. 2) Przepraszanie nigdy nie boli, nawet jeśli nie jest to naprawdę wielka sprawa, nawet jeśli istnieją narzędzia, które mogłyby zapobiec problemowi. 3) Obwinianie kogoś innego za spowodowany przez ciebie problem, bez względu na to, czy jest to naprawdę twoja wina, jest kiepskim pomysłem.
Caleb
Występują tutaj dwa problemy: 1 - uszkodzony kod na komputerze lokalnym. 2 - uszkodzony kod na serwerze kompilacji. Pierwszy problem jest bardzo niewielki, ponieważ wszyscy programiści popełniają błędy. Zmiany można cofnąć i nie będzie to miało wpływu na system ani dział. Drugi problem może mieć znacznie większy negatywny wpływ na system i dział.
CodeART
-2

Chociaż myślę, że można przeprosić, nie mów: „Dopilnuję, aby to się więcej nie powtórzyło”. Ponieważ tak będzie. A jeśli to zrobi, ugryzie cię.

Pieter B.
źródło
-2

Jeśli pracujesz nad projektem typu open source,

po prostu powiedz „Przepraszam, zepsułem wersję.

i dodaj jako komentarz github.

Jest tak, ponieważ wielu programistów open source pisze kod o północy.

linquize
źródło