Jangan main-main dan optimalkan kinerja 😂 Baru saja melihat komentar: > Setelah diskalakan, bahkan bug yang Anda tulis akan memiliki pengguna. Pekerjaan pertama saya setelah kuliah adalah di sebuah perusahaan di mana ada seminar orientasi besar untuk karyawan baru. Suatu hari, mereka menceritakan kisah tentang pertengahan 90-an, ketika tim teknis mengoptimalkan waktu pemuatan perangkat lunak dari 5 menit menjadi 30 detik. Akibatnya, umpan balik negatif dari pelanggan meledak secara instan. Optimalisasi waktu pemuatan ini justru menghancurkan budaya perusahaan perusahaan itu. Ternyata sebelum pengoptimalan, semua orang pergi ke kantor, menyalakan komputer, dan menggunakan waktu pemuatan selama 5 menit untuk mengobrol, minum kopi, dan memulai hari yang santai. Dan sekarang, sebelum mereka bisa bangun dari meja mereka, perangkat lunak siap untuk mengerjakannya! Moral dari cerita ini—dan kutipan di atas—bukanlah untuk memberi tahu Anda untuk tidak memperbaiki keadaan. Sebaliknya, ini adalah pengingat bahwa perangkat lunak yang Anda bangun tidak hanya ada di PRD (Dokumen Persyaratan Produk) atau rangkaian pengujian. Ini adalah sistem yang berinteraksi dengan orang-orang di dunia nyata. Orang-orang membangun kebiasaan di sekitarnya, mengembangkan solusi, dan bahkan mengandalkan bug tertentu untuk skenario penggunaan praktis. Ini sangat penting bagi Anda sebagai insinyur perangkat lunak: Anda harus memahami untuk apa perangkat lunak yang sebenarnya digunakan dan bagaimana perangkat lunak itu digunakan di dunia nyata. Tugas Anda bukan untuk menyelesaikan banyak tiket dari manajer produk, tugas Anda adalah membangun perangkat lunak yang memecahkan masalah pengguna. Tautan: