Cara meminta maaf ketika Anda telah merusak bangunan malam [ditutup]


181

Komitmen pertama saya dalam proyek saya menghasilkan bangunan malam rusak dan orang-orang di sekitar saya saat kami mendekati rilis. Saya ingin mengirim email permintaan maaf yang seharusnya terdengar tulus dan pada saat yang sama mengisyaratkan bahwa ini adalah komit pertama saya dan ini tidak akan terulang lagi.

Menjadi penutur bahasa Inggris non-pribumi, saya mengalami kesulitan menghasilkan kata-kata yang benar. Dapatkah seseorang tolong bantu?


99
Jika build tidak pernah rusak saya akan mulai curiga proses build yang rusak;)
Lazarus

6
Bagaimana Anda tahu bahwa bangunan itu rusak?

65
Bagaimana dengan: "Saya sangat menyesal karena melanggar pembangunan malam. Jika Anda ingin memotong gaji saya sebagai bentuk hukuman, saya tidak akan membawa perusahaan ke pengadilan ketenagakerjaan". Nah, hanya bercanda - jangan minta maaf, hal semacam ini terjadi setiap saat. Orang-orang yang "seluruh Anda" adalah psikopat f.king yang tidak tahu cara mengembalikan sistem dengan benar ke keadaan sebelumnya.
Jas

14
Saya merusak bangunan berdasarkan 10 komitmen pertama saya! Jangan khawatir tentang hal itu
Tidak ada yang

135
Saya hanya berharap saya memiliki bangunan malam untuk istirahat ..
Max

Jawaban:


306

Jangan minta maaf!

  • Menghancurkan bangunan sekali di bulan biru bukanlah masalah besar, dan seharusnya tidak pernah menjadi show-stopper.
  • Ini kesalahan manajer Anda karena tidak mengonfigurasi pembuatan yang berkelanjutan dan otomatis.

Juga, saya yakin tim Anda gagal dalam 'Tes Joel' dan tidak dapat membuat build dalam satu langkah.

Jika demikian, ini akan menjadi hal lain yang tidak boleh Anda minta maaf. Memang, itu adalah tim anti-pola.


31
+1 Setuju! Jangan minta maaf. PELAJARI apa yang Anda lakukan salah. Jangan lakukan lagi, setidaknya tidak segera. Bersikap sopan ketika orang-orang "menguasai Anda". Belajarlah dari apa yang mereka katakan (meskipun hanya siapa yang menyebalkan dan siapa yang baik-baik saja).
Peter K.

12
Yah, kau masih bisa meminta maaf ... Tapi aku agak terkejut bahwa orang-orang di sekitarmu. Jika Anda baru di tim, seharusnya tidak mengejutkan bahwa Anda melakukan kesalahan. Setidaknya itu menunjukkan bahwa Anda melakukan sesuatu :)
Philippe

40
+1. Seluruh tujuan melakukan pembangunan malam adalah untuk menangkap masalah sedini mungkin dan sebelum mereka berlayar dengan rilis. 95% pengembang telah membuat kesalahan visibilitas tinggi selama karier mereka. 5% lainnya berbohong.
Blrfl

26
Sementara saya setuju bahwa ini tidak meminta permintaan maaf tingkat "jatuh pada pedang", saya pikir itu meminta permintaan maaf tingkat "oops, my bad". Tidak semua 'Maafkan aku' harus hina.
Matthew Scouten

5
Saya tidak setuju dengan premis ini sama sekali, tidak ada yang salah dengan sederhana "Maaf" maaf, aku menyadari bahwa aku mengacaukan dan akan melakukan yang terbaik untuk belajar dari kesalahan saya . Saya setuju cara terbaik untuk * mengubah * diri Anda sendiri adalah tidak melakukannya lagi, tetapi Anda jika Anda peduli, Anda mungkin tidak akan secara terbuka menunjukkannya kepada orang lain, tidak setiap kali Anda mengacau, tetapi ia jelas merasa buruk tentang dan tidak ada yang salah dengan meminta maaf.
Trufa

182

Roti bagel. Donat. Dll. Di satu perusahaan tempat saya bekerja dulu, memeriksa kode yang rusak atau menyebabkan gangguan rekan kerja biasanya diselesaikan dengan memasukkan permintaan maaf bahan makanan pada hari berikutnya.

Kami memiliki seorang pria menerbangkan database produksi suatu hari, menyebabkan kepanikan besar dan larut malam untuk seluruh tim. Hari berikutnya dia memanggang burger untuk makan siang.

Saya suka permintaan maaf rekan kerja. Enak, permintaan maaf enak.


83
+1 untuk "Saya suka permintaan maaf rekan kerja. Permintaan maaf enak, enak."
Jas

32
Melanggar pengembangan dev malam adalah satu hal tetapi meniup basis data produksi adalah pada tingkat lain. Jika saya pernah melakukan itu saya berharap burger panggang adalah yang terburuk dari hukuman saya.
maple_shaft

20
Anda hampir bisa merasakan rasa bersalah.
Mike Speed

40
"Meniup basis data produksi" menempatkan semua jenis gambar lucu di kepala saya tentang apa yang sebenarnya terjadi pada basis data. Kebanyakan dari mereka melibatkan semua orang yang mendengar ledakan keras dari ruang server. "Ya Tuhan, database mencapai volume kritis!" "Cepat! Turunkan batang kendali!" "Sudah terlambat, data, dia sudah hancur!" BOOM
Carson Myers

7
drop database... Oh kekuatan dari dua kata kecil itu. Itu bertahun-tahun yang lalu, tetapi saya ingat dengan baik;)
Leigh

80

Dua kutipan untuk Anda:

Pria yang tidak melakukan kesalahan biasanya tidak melakukan apa-apa .-- William Connor Magee

Siapa pun yang tidak melakukan kesalahan tidak berusaha cukup keras .-- Wess Roberts

Saya setuju dengan Jim G. , jangan minta maaf tetapi belajarlah darinya dan jangan melakukan kesalahan yang sama lagi ... tetap KERING;)


9
Atau ada kutipan yang lebih umum dari: "biarkan dia yang tanpa dosa melemparkan batu pertama" Jika siapa yang pernah mengeluh tentang bangunan yang rusak telah menghancurkan bangunan sebelumnya, mereka seharusnya tidak mengerang
Richard

seperti yang kedua !!
Sufendy

1
Mengutip diri untuk setiap Lulusan / SMP yang pernah saya bimbing "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

Penggunaan prinsip "KERING" yang bagus ... :)
J. Allan

53

Jangan minta maaf, hanya PERBAIKAN IT sesegera mungkin. Tidak apa-apa, semua orang merusak bangunan setidaknya sekali, di perusahaan terakhir saya itu adalah semacam ritual inisiasi. Ketika seorang anggota tim merusak bangunan, kami akan meletakkan bebek karet di mejanya di pagi hari sebelum dia masuk, ini memberi tahu dia bahwa dia merusak bangunan dan dia akan memperbaikinya.

Kami menyebutnya Duckie Integrasi Berkelanjutan dan ketika Anda memilikinya pada hari orang akan menggodamu, tetapi itu semua menyenangkan, tidak ada yang seharusnya bersemangat.

Kami mengambil sesuatu seperti bangunan yang rusak dan mengubahnya menjadi latihan membangun tim.


2
+1: bukan hanya apa yang mereka pedulikan - semua yang harus mereka pedulikan. Anda tidak melakukan kesalahan, karena itu - hanya melenturkan batas dari apa yang mungkin agak terlalu jauh;). Anda mungkin juga orang yang paling tepat untuk memperbaikinya. Setiap orang melakukan ini setiap sekarang dan lagi. Semua orang mengunggah sesuatu untuk ditonton yang seharusnya tidak hilang. Semua orang meninggalkan klausa WHERE dari pernyataan UPDATE sekali dalam hidup mereka. Bagaimana Anda bereaksi itulah yang penting. Di mana kita berada, semua devs cenderung untuk menutup, menolak untuk berbicara tentang siapa yang secara salah bersalah jika ada yang bertanya, itu hanya diperbaiki.
Tom Morgan

Yang tampaknya seperti benar-benar cara yang bagus untuk menangani kesalahan.
Trufa

3
Duckie Integrasi Berkelanjutan , Hahahaha
AttackingHobo

43

"Maaf! Badaku!" adalah bagaimana saya biasanya meminta maaf ketika saya telah merusak bangunan. Itu terjadi. Tetapi seperti yang dikatakan orang lain, ini adalah kesempatan untuk memperbaiki sistem Anda sehingga satu orang tidak dapat dengan mudah merusak bangunan untuk orang lain.

Saya tidak akan membuat permintaan maaf formal dalam keadaan ini, tetapi jika Anda benar-benar merasa bahwa permintaan maaf yang lebih formal itu tepat, maka permintaan maaf Anda harus melakukan hal-hal ini:

  • Menyatakan penyesalan.
  • Katakan masalahnya.
  • Mengambil tanggung jawab.
  • Menebus kesalahan.
  • Simpan muka.

Yaitu, "Saya minta maaf [EXPRESS REGRET] bahwa saya membuat Anda tidak nyaman [MENGAMBIL TANGGUNG JAWAB] secara tidak sengaja [HEMAT WAJAH] merusak bangunan [NEGARA MASALAH]. Donat ada pada saya besok. [MAKA PERUBAHAN]"

Setiap bagian diperlukan dalam permintaan maaf yang tepat; jika Anda tidak menyatakan masalahnya maka tidak jelas. Jika Anda tidak mengungkapkan penyesalan, bertanggung jawab, dan menebus kesalahan, maka orang-orang merasa Anda tidak tulus. Bagian penyelamatan wajah adalah bagian permintaan maaf yang paling diabaikan; bagian penyelamatan wajah adalah yang mengingatkan pihak yang terluka bahwa Anda adalah rekan kerja yang berharga yang terkadang melakukan kesalahan, dan bukan idiot (atau penyabot!)

Akhirnya, beberapa pemikiran tentang membangun melanggar:

Saya bekerja di tim kompiler C # / Visual Basic. Tentu saja hari ini Visual Studio sekarang merupakan proyek besar yang memiliki tim sendiri hanya untuk mengelola membangun infrastruktur, dan sebuah ruangan besar dengan sistem pendingin udara yang didedikasikan. Kembali pada pertengahan 1990-an ketika saya mulai sebagai magang, tim membangun Visual Basic adalah satu magang - saya - dan lemari penuh dengan mesin. Waktu telah berubah!

Kembali pada hari-hari sebelum integrasi berkelanjutan dan proses checkin yang kuat, tim akan memiliki berbagai hukuman karena melanggar membangun. Pada beberapa tim, hukumannya adalah jika Anda melanggar build, Anda harus mengenakan topi lucu setiap hari di tempat kerja sampai orang lain merusak build. Pada beberapa tim, jika Anda mengenakan topi itu, Anda bertanggung jawab untuk memverifikasi bahwa bangunan malam itu benar.

Suara terakhir itu terdengar kejam, tetapi sebenarnya memiliki tujuan yang berharga. Karena hampir semua orang merusak bangunan pada satu waktu atau yang lain, akhirnya seluruh tim akan mempelajari proses untuk memverifikasi bangunan malam.


15

Jangan minta maaf. Rekan kerja Anda yang harus disalahkan karena tidak meninjau komit pertama Anda dan tidak memiliki sistem umpan balik cepat untuk pembuatan seperti server integrasi berkelanjutan.

Pada pekerjaan saya saat ini, kami memiliki aturan informal bahwa seseorang yang diam-diam melakukan sebelum meninggalkan pekerjaan dan ternyata merusak gedung harus membawa permen / kue / minuman untuk seluruh tim pada hari berikutnya. Tetapi kami memiliki integrasi berkelanjutan yang memperingatkan kami tentang bangunan yang rusak pada siang hari. Dan aturan itu mungkin tidak berlaku untuk komitmen pertama seseorang.

Bagaimanapun, surat permintaan maaf resmi mungkin agak terlalu banyak.


Poin bagus - peer review seharusnya menangkap ini. Karena Anda melakukan perubahan peer review sebelum diterapkan ke master / HEAD / default, kan?
Frank Shearar

11

Aturan mendasar - saat Anda salah, akui: - | Anda tidak perlu merendahkan diri dalam permintaan maaf. Setiap orang membuat kesalahan. Pro mengakui itu. Itu kerja tim. Anggota tim lainnya harus bekerja sama untuk membantu Anda menyelesaikannya. Jika tidak, Mintalah bantuan. Yang paling harus dikatakan sesudahnya adalah - apa yang bisa kita pelajari darinya?

Mereka mengatakan pernikahan yang sukses didasarkan pada tiga kata kecil - "Saya salah".

Jika seseorang tidak melakukan kesalahan sesekali, mereka tidak berfungsi, tetapi kesalahan yang tidak dipelajari adalah dua kesalahan.


Saya pikir ini adalah jawaban yang bagus dan jauh lebih baik daripada jawaban "Jangan minta maaf" yang memiliki suara tertinggi. Anda dapat meminta maaf kepada semua orang karena melanggar pembangunan, tetapi mereka juga perlu menunjukkan sedikit rahmat. Mereka juga harus mengatakan "jangan khawatir, kita semua telah merusaknya sebelumnya, setelah semua, itulah gunanya". Selama Anda mencoba untuk tidak merusaknya lagi, mereka harusnya tenang dengan itu. Jika Anda mengabaikan semua orang dan pergi dan melakukan kesalahan yang sama maka itu cerita yang berbeda.
Rocklan

6

Permintaan maaf terbaik adalah memperbaiki waktu istirahat dengan cepat


5

Jika perusahaan Anda sudah memiliki cara untuk menguji perubahan build Anda, maka (A) perubahan Anda gagal (tetapi Anda tetap memeriksanya) atau (B) mereka berhasil (dan Anda perlu membuat case test baru).

Jika kolega Anda dengan hati-hati menguji perubahan mereka dan berharap menemukan jeda pada build malam, maka (C) Anda memiliki proses rapuh (dan Anda perlu memperkenalkan pengujian seperti yang ditemukan di Extreme Programming).

Ada kemungkinan bahwa (D) Perubahan Anda menyebabkan perubahan yang tidak terduga dalam kode Bill yang sudah ada sebelumnya atau berubah pada build yang sama seperti milik Anda.

Bergantung pada bagaimana Anda dan perusahaan Anda menguji, saya akan meminta maaf berdasarkan kasus per kasus:

  • (A) Saya gagal tes build tetapi memeriksa perubahan saya. Maaf, saya mengubah proses saya jadi saya tidak akan melakukannya lagi.
  • (B) Saya lulus uji build dan menambahkan uji JUnit XYZtest.java untuk mengurangi kemungkinan terjadinya kembali.
  • (C) Karena kami tidak memiliki proses pengujian build, saya membuat satu untuk perubahan saya. Saya ingin berbagi dengan Anda bagaimana kami dapat meningkatkan proses pembangunan kami.
  • (D) Saya akan bekerja dengan Bill untuk menulis tes JUnit XYZtest.java untuk mengurangi kemungkinan terjadinya kembali.

Saya yakin ada (E) yang belum saya pikirkan.

Perhatikan bahwa saya mengatakan "untuk mengurangi kemungkinan terjadinya kembali" daripada "agar tidak terjadi lagi." Itu akan terjadi lagi. Tetapi Anda dapat meningkatkan proses Anda untuk mengurangi kemungkinan itu. Itu, saya pikir, adalah salah satu tanda programmer yang menang.


2

Jangan minta maaf. Anda manusia dan Anda akan membuat kesalahan. Setiap orang akan merusak bangunan sesekali, kuncinya adalah memperbaikinya dengan cepat.

Adapun orang-orang melompati Anda ... baik saya ingin tahu apakah mereka pernah menulis bug.


2

Cara pendekatan ini tergantung pada suasana di grup Anda. Jika ini budaya menyalahkan, saya akan sangat berhati-hati dalam meminta maaf dan bagaimana Anda melakukannya. Jika itu adalah suasana yang kolaboratif dan positif, maka ya, sesuatu di sepanjang baris "Aku kacau, aku minta maaf. Bagaimana kita bisa menghindari ini di masa depan?" mungkin ide yang bagus.

Bagaimanapun, kesalahan seperti ini harus disertai dengan semacam post-mortem ke a) mencari tahu bagaimana hal itu terjadi dan b) bagaimana meminimalkan kemungkinan hal itu terjadi lagi.

Saya tidak terbiasa dengan struktur Anda (saya bekerja di lingkungan yang sangat berbeda) tetapi pada akhirnya, kenyataannya adalah bahwa kadang-kadang, orang membuat kesalahan, dan segala sesuatunya rusak. Anda belajar dari pengalaman dan terus maju.


2

Di lingkungan saya jika Anda melanggar bangunan Anda akan mendapatkan ribbing natured yang baik dan beberapa cometary cerdas. Saya tidak yakin di negara mana Anda yang berbahasa Inggris, tetapi bisa jadi sebagai penutur asli bahasa Inggris Anda tidak mendapatkan sifat menggarisbawahi dari komentar tersebut.

Berasal dari sisi lain sebagai pengembang Senior, saya pernah mengomentari ulasan kode yang beberapa cara melakukan x "mengisap" bukan karena kode itu buruk tetapi lakukan untuk struktur proyek. Lebih banyak komentar pada diri saya bahwa saya perlu memperbaiki masalah struktural. Baru kemudian saya menemukan bahwa Jr Dev meskipun saya sangat marah padanya karena pidato sembrono saya yang tidak akurat.


2

Um Anda mendapatkan token build yang rusak . Serahkan rabies ke penerima yang beruntung berikutnya. Terjadi sepanjang waktu. Kualitas itu penting, tetapi kesalahan tidak bisa dihindari. Perbaiki mereka. Berpindah. Malu cowok malang berikutnya.


1
Saya sudah sering melihat ini. Yang lain adalah Anda bisa "menjaga" bangunan malam sampai orang lain merusaknya. Ini tidak berarti memperbaikinya, tetapi mencari tahu mengapa dan siapa yang harus memperbaikinya.
Stephen Darlington

1

Sebagai aturan umum, saya akan mengatakan:

Jika checkin Anda menyebabkan kesalahan kompiler, Anda akan mengetahui bahwa Anda telah melakukan "dapatkan terbaru" sebelum check-in, "whoops, my bad" yang sederhana sudah beres. (terutama jika Anda berjalan pada pukul 10 keesokan paginya, sementara semua orang memutuskan perubahan mana yang akan dikembalikan)

Jika lapor masuk Anda menyebabkan perilaku tak terduga yang umum, bahkan kesalahan runtime, saya pikir itu tidak seharusnya dilakukan terhadap Anda. Itu datang dengan wilayah itu. Selama semua orang "mendapatkan terbaru" umumnya akan melewati kompiler mereka, orang benar-benar tidak boleh melemparkan cocok (dengan beberapa pengecualian seperti menghapus database, menghapus salinan server proyek dan semua perubahan, atau apa pun yang begitu bodoh bahwa orang harus menganggap niat jahat).


1

TIM gagal.

Perusahaan Anda membutuhkan lebih banyak tinjauan kode pada pengembang yang melakukan pembangunan pertama kali.

Saya hanya tidak melihat bagaimana sebuah tim membiarkan ini berlanjut tanpa mereka melakukan review dan menawarkan beberapa jaminan sepanjang jalan bahwa Anda melakukan sesuatu dengan benar.

Menjadi dekat dengan waktu rilis bukan alasan, tetapi alasan yang lebih baik untuk memeriksa ulang kode baru.

Jika pembebasan Anda tidak dapat dibatalkan dengan mudah, ada masalah yang lebih besar dengan grup ini.


0

Saya tidak mengerti mengapa orang-orang menguasai Anda. Jika sistem diatur dengan baik, mereka harus dapat menghapus perubahan Anda / memperbaikinya dengan sangat cepat.

Tetapi sekali lagi, jika Anda adalah salah satu dari orang-orang yang memecahkan jendela yang rusak, Maka ... Saya tidak dapat membantu. (Sangat sulit untuk melakukan btw - sebelum ada yang mempertanyakan MS membangun filosofi, tetapi sekarang dan kemudian seseorang melakukannya - dan seluruh perusahaan QA berhenti selama sehari).

Dan yeah - jangan minta maaf. Hanya mengobrol dengan manajer Anda dan buat dia mengerti bahwa Anda belajar dari apa yang telah Anda lakukan.


0

Bangun istirahat sepanjang waktu. Bug dan kesalahan adalah fakta kehidupan, dan itulah sebabnya Anda harus memiliki proses yang meminimalkan efek bug dan kesalahan.

Jika build build adalah masalah besar, itu berarti proses Anda rusak.

Anda harus melakukan pembangunan berkelanjutan, bukan pembangunan malam.


+1 untuk "jika build build adalah masalah besar, itu berarti proses Anda rusak." Di sisi lain, Anda masih harus berurusan dengan proses yang rusak, dan itu berarti melakukan apa yang dapat Anda lakukan untuk menghindari menghancurkan bangunan malam sampai proses diperbaiki.
Caleb

0

Lebih baik jawaban yang terlambat daripada tidak pernah ...

Seperti yang dikatakan banyak orang lain, jangan minta maaf karena melanggar pembangunan. Cukup akui bahwa itu adalah Anda dan mulai bekerja. Hal-hal ini akan terjadi baik Anda ada di sana atau tidak, dan tidak ada yang pantas diperlakukan dengan buruk karenanya. Orang bereaksi sangat buruk di bawah tekanan, jadi jika Anda bisa tetap tenang dan melanjutkan pekerjaan, Anda akan menonjol ketika itu penting. Saran saya ketika orang memberi Anda waktu yang sulit adalah dengan menghindari defensif, meredakan situasi dengan memberi tahu orang lain bahwa Anda sedang dalam masalah, atau Anda cepat mencari nasihat jika Anda merasa Anda terjebak.

Secara pribadi, saya melihat bangunan yang rusak sebagai peluang.

  • Jika build rusak dan Anda dapat membuktikan bahwa itu adalah kesalahan Anda, maka kemungkinan besar akan menunjukkan bahwa integrasi terus menerus dan proses build melakukan pekerjaannya. Ini adalah hal yang baik, karena memvalidasi proses Anda. Jika bangunan tidak pernah rusak, saya khawatir ada yang salah dengan itu.
  • Jika Anda telah melanggar bangunan dengan cara yang cukup umum, dan itu sering terjadi dengan cara ini, maka mungkin ada sesuatu yang hilang dari proses CI. Ini adalah kesempatan untuk meningkatkan proses Anda sehingga skenario kegagalan umum dapat dikelola dengan lebih baik.
  • Jika Anda telah melampaui tugas dan benar-benar mengacaukan gedung dengan masalah yang tidak jelas, maka Anda memiliki kesempatan untuk mempelajari sesuatu yang baru yang mungkin cukup penting untuk memicu peringatan kepada anggota tim lainnya.

Jadi yang saya katakan adalah bahwa melanggar bangunan kadang-kadang berarti orang melakukan pekerjaan mereka. Tentu Anda mungkin telah melakukan kesalahan, tetapi jika Anda menggunakannya sebagai kesempatan untuk belajar, Anda melakukan pekerjaan Anda hanya dengan belajar melakukannya dengan lebih baik lain kali.


-1

Beri tahu mereka bahwa mereka membutuhkan CI build per check-in. Dengan begitu Anda tidak perlu menunggu sampai malam tahu itu rusak. YA!!! Katakan pada mereka itu adalah proses yang salah, tidak ada yang lain. Anda baru saja mengidentifikasi celah dalam sistem mereka .

Tapi ya, pastikan untuk memperbaikinya. Bukan masalah besar. Itu tidak dalam produksi. Hanya malam yang tidak berharga.


-2

Praktik yang biasa di perusahaan saya adalah:

  • Berteriak "itu bukan aku!" (biasanya bukti CVS / SVN sebaliknya)
  • Mengenakan t-shirt bertuliskan "my-userlogin ist Schuld!" (ya, 50% dari pengembang kami memiliki kemeja seperti itu)
  • Mengklaim bahwa itu berfungsi di sendbox lokal dan semua tes lulus dengan baik

Perusahaan saya juga memiliki cara yang bagus untuk menangani "insiden" seperti itu:


-2
  • Saya tidak akan meminta maaf.

  • Saya akan menyalahkan CI memimpin karena mengizinkan saya melakukan pembangunan yang rusak.

  • Harus ada proses CI di tempat untuk menghentikan pengembang dari melakukan kode yang rusak.

  • Jika build lokal gagal, maka seharusnya tidak diizinkan memasuki build server.


1) Tidak semua proyek diatur untuk melakukan integrasi berkelanjutan. Sangat menyenangkan untuk memiliki, dan dapat membantu dengan situasi seperti OP, tetapi jauh dari pasti. 2) Tidak ada salahnya untuk meminta maaf bahkan ketika itu bukan masalah besar, bahkan ketika ada alat yang bisa mencegah masalah. 3) Menyalahkan orang lain atas masalah yang Anda sebabkan, apakah itu benar-benar kesalahan Anda atau tidak, adalah ide yang buruk.
Caleb

Ada dua masalah di sini: 1 - kode rusak pada mesin lokal. 2 - kode rusak pada server build. Masalah pertama sangat kecil karena semua pengembang membuat kesalahan. Perubahan dapat dibatalkan dan tidak akan ada dampak pada sistem atau departemen. Masalah kedua kemungkinan memiliki dampak negatif yang jauh lebih besar pada sistem dan departemen.
CodeART

-2

Sementara saya pikir semacam permintaan maaf bisa dilakukan, tolong jangan katakan: "Saya akan memastikan ini tidak terjadi lagi." Karena itu akan. Dan jika itu terjadi, itu akan menggigit Anda.


-2

Jika Anda bekerja pada proyek sumber terbuka,

katakan saja "Maaf, saya merusak gedung. Mungkin saya terlalu mengantuk!"

dan menambahkannya sebagai komentar github.

Itu karena banyak pengembang open source menulis kode pada tengah malam.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.