Bagi mereka yang tidak terkait dengan pembuatan perangkat lunak, pekerjaan pengembang mungkin tampak cukup mudah: Anda laris di pasar, mereka membayar dengan baik, perusahaan berusaha menyenangkan nishtyaks yang menyenangkan, dan sebagainya. Semua ini benar, tetapi jika jujur, maka programmer memiliki banyak momen yang tidak menyenangkan. Kami telah mengumpulkan sepuluh hal paling populer yang paling sering membuat para pembuat perangkat lunak kesal.
10. Besi
Tentu saja, program membutuhkan peralatan untuk dijalankan. Dan tidak peduli bagaimana beberapa pengembang mencoba mengabaikan peran perangkat keras, cepat atau lambat ketika membuat dan men-debug perangkat lunak, mereka pasti akan menghadapi masalah khusus untuk peralatan. Oleh karena itu, pemula disarankan untuk selalu mempelajari fitur-fitur besi dan sistem di mana kode mereka akan dieksekusi, sehingga nantinya akan ada lebih sedikit kesulitan.
“Setiap programmer yang setidaknya pernah men-debug crash aneh pada server database atau mencoba memahami mengapa drive RAID tidak bekerja dengan benar tahu betapa menyakitkannya ini masalah perangkat keras.” Steve borthwick
"Pemrogram membenci perangkat keras karena mereka tidak selalu bisa menyalahkan semua yang ada padanya!" Anonim
9. Duduk sepanjang hari
Sampai Anda memiliki desktop dengan treadmill, pengembangan perangkat lunak tidak akan pernah menjadi semacam latihan aerobik. Kebanyakan programmer menghabiskan waktu berjam-jam duduk di pantat mereka, mengetuk keyboard dan menatap layar dengan saksama. Setelah beberapa waktu, duduk lama bisa menjadi sangat tidak nyaman. Dan jika Anda bahkan tidak bisa pindah ke tempat lain untuk mengubah lingkungan, maka ini terkadang dengan cepat membuat Anda sedih.
“Saya duduk sepanjang hari di kursi dan menatap layar. Itu dimulai beberapa waktu yang lalu ... pertama kembali, lalu leher, mata lelah dan seolah-olah terbakar, sakit kepala ... tidak ada ketenangan kaki ... Saya mencoba mengimbangi ini dengan kebugaran, taijiquan, yoga, qigong, saya pergi bekerja dengan sepeda - dan masih saya tidak bisa lagi duduk di atas delapan jam atau lebih. Untuk menghabiskan sepanjang hari di kantor ... menonton matahari menembus langit, tidak melihat ke atas dari kursi sialan ini sementara hidup berlalu. " Markus toman
8. Debugging
Bahkan kode terbaik yang ditulis dengan cermat bukan tanpa bug. Secara alami, pengembang dipaksa untuk secara teratur menghabiskan waktu mencari dan memperbaiki cacat - baik dalam kode mereka maupun dalam kode orang lain. Beberapa bug ditemukan dan dirawat dengan mudah, sementara yang lain dapat membuat kepanasan dengan kerasnya mereka, memaksa mereka untuk menghabiskan berjam-jam dan meragukan stabilitas jiwa mereka.
“Deteksi yang sulit untuk direproduksi atau, yang terburuk dari semuanya, bermanifestasi pada bug uji integrasi yang secara tidak sengaja melewati atau gagal pada kode yang sama !!! Maka rasanya seperti Anda tidak pernah dapat menemukan bug misterius terkutuk ini bersembunyi di suatu tempat dalam kode. Fu! " Emmanuel ngwane
"Kami menulis program besar seperti itu (kadang-kadang juga kecil) sehingga ketika debugging, kami mempelajari ke alam liar seperti itu dan melupakan apa bug itu sendiri . " Ayush Bhatnagar
“Debugging, terutama ketika mengerjakan proyek-proyek besar dengan ribuan jalur. Banyak Geeks seperti saya lebih suka menampilkan gambar melalui proyektor saat debugging, sehingga lebih mudah bagi mata. " Isaac perez
7. Dokumentasi yang buruk
Bekerja dengan kode orang lain terkadang menjengkelkan, tetapi tidak begitu banyak jika didokumentasikan dengan baik. Sayangnya, ini tidak selalu terjadi. Jika tidak ada komentar dalam kode atau penjelasan yang biasanya ditulis tentang cara kerja semuanya, Anda harus menghabiskan lebih banyak waktu untuk debugging, memperluas, atau mengintegrasikan aplikasi. Dan ini bukan cara terbaik yang mempengaruhi kesejahteraan programmer.
“Yang paling menjengkelkan adalah ketika Anda disewa untuk berurusan dengan perangkat lunak yang tidak terdokumentasi dengan baik. Ini membuat hidup sulit bagi mereka yang menerima pekerjaan di proyek. Kurangnya komentar dan semantik yang buruk, terutama ketika banyak bug dan kesalahan tetap ada setelah programmer sebelumnya. ” Angel Angeles III
"Persidangan menggunakan kode yang tidak berdokumen dan tidak diomentari yang ditulis oleh beberapa orang idiot." Abhishek chauhan
“Saya, seperti kebanyakan programmer, menghabiskan lebih banyak waktu untuk mempertahankan kode yang tidak terdokumentasi dengan baik daripada menulis yang baru.” Walt karas
6. Penggabungan kode
Sistem kontrol sumber seperti Git atau Subversion adalah alat hebat yang memungkinkan banyak pemrogram untuk bekerja pada basis kode yang sama pada saat yang sama, tanpa mendorong siku mereka. Tetapi pada akhirnya, perubahan harus dilakukan ke repositori, dan konflik dapat muncul di sini jika, katakanlah, dua pengembang mengubah satu file atau subrutin. Terkadang konflik seperti itu diselesaikan dengan sederhana, terkadang tidak demikian.
“ Saya tidak suka bergabung, karena saya ingin mengubah kode sehingga kolega saya ingin melakukannya secara berbeda - dan apa yang kita lakukan? "Saya selalu berusaha menemukan cara untuk menggabungkan kedua solusi, tetapi jika konflik nyata muncul, maka penggabungan menjadi tugas yang sangat tidak menyenangkan." Jessica su
"Konflik merger" kejahatan absolut . " Koustuv sinha
5. Harapan yang tidak realistis
Pengembang perangkat lunak - orang jauh dari bodoh. Tetapi justru karena alasan ini, semua jenis bos, manajer proyek, dan tenaga penjualan sering menunjukkan harapan yang tidak realistis dan tinggi tentang apa yang dapat dibuat oleh seorang programmer atau tim programmer pada tanggal tertentu, dan karenanya terlalu banyak merencanakan. Akibatnya, pengembang akhirnya kehabisan tenaga di tempat kerja dan umumnya tidak merasakan kesenangan darinya.
“Hal yang paling tidak menyenangkan adalah menjelaskan kepada orang-orang bahwa Anda bukan seorang penyihir, bahwa pengetahuan Anda memiliki batasan, apa yang sebenarnya dapat direalisasikan dengan bantuan alat yang tersedia dalam waktu yang ditentukan, dan mencoba untuk menyampaikan semua ini kepada orang-orang yang belum pernah terlibat dalam pemrograman dan tidak bersemangat untuk melakukannya. " . Mark miller
"Bos Anda mengharapkan banyak dari Anda dan kolega Anda, tetapi waktu dan sumber daya tidak cukup bahkan untuk mendekati hasil yang diharapkan." Kevin sekin
"Manajer proyek dan analis bisnis menjanjikan pelanggan untuk mengeluarkan bulan dari langit, dan programmer harus melakukannya dengan cara apa pun . " Ratnakar sadasyula
"Aku suka ketika seseorang meminta untuk melakukan sesuatu yang sepele, dan kemudian dengan santai memuntahkan tuntutan yang perlu dikembangkan ilmu komputer selama dua puluh tahun lagi . " Vladislav Zorov
4. Orang lain melanggar kode saya
Kode yang ditulis oleh pengembang mana pun, dengan satu atau lain cara, harus berinteraksi dengan kode programmer lain. Tidak masalah jika itu adalah bagian dari satu aplikasi, perpustakaan pihak ketiga, alat atau aplikasi lain secara umum. Kode kami tidak ada dalam isolasi. Akibatnya, seseorang dapat, karena tergesa-gesa, salah paham, atau kecerobohan, merusak kode orang lain, yang menyebabkan ketidakpuasan, pertengkaran, stres, dan sering kutukan.
“Hal terburuk yang saya miliki adalah ketika saya menulis sebuah program dengan seseorang yang, tanpa pemberitahuan, mengubah perpustakaan yang kami berdua maksudkan. Akibatnya, subrutin saya memanggil variabel yang hilang atau menambahkannya. Atau, lebih buruk lagi, kode perpustakaan menabrak di mana saya tidak memiliki akses. " Sheri fresonke harper
“Ketika sebagian kode Anda berhenti berfungsi karena seseorang telah mengubah bagian kode itu. Seringkali fungsinya mulai membutuhkan lebih banyak argumen daripada sebelumnya. Kadang-kadang fungsi umumnya hilang atau ditransfer ke file lain. " Jessica su
"Kebutuhan untuk terus-menerus kembali dan mengulangi kode yang Anda tulis beberapa hari yang lalu dan yang baru saja" rusak "(bukan yang pertama kali) karena perubahan yang dibuat pada sistem umum tanpa diskusi oleh seseorang yang bahkan belum diuji atau dinilai pada bahwa tes gagal. Dan sebagai hasilnya, mereka memberi tahu Anda bahwa kode Anda "tidak berfungsi" . " Simon hayes
3. Orang tidak mengerti apa yang saya lakukan
Meskipun semakin populernya profesi seorang programmer dan kemunculan perangkat lunak, banyak profesional non-TI masih tidak mengerti apa yang sebenarnya dilakukan oleh para pengembang. Bagi mereka, kami hanya "teknisi," dan mereka tidak melihat banyak perbedaan antara, misalnya, pengembang perangkat lunak dan perangkat keras. Kesalahpahaman yang konstan dan ide-ide yang tidak pantas, terutama di antara keluarga dan teman-teman Anda, dapat membuat seorang programmer gila.
“Di antara orang-orang yang tidak terkait dengan IT, ada kesalahpahaman yang tersebar luas bahwa sejak programmer bekerja pada komputer, mereka harus dapat memperbaikinya. Ini kira-kira sama dengan jika Anda mengendarai mobil, Anda harus dapat memilah gearbox. " Steve borthwick
“Ya, saya mencari nafkah dengan menulis kode. Tidak, saya tidak dapat membantu menyelesaikan masalah dengan printer, atau dengan membuka file yang terlampir pada surat, atau dengan komputer yang tidak bisa boot. Setidaknya - sampai Anda mentraktir saya makan siang atau bir, mungkin saya bisa membantu. " Phil johnson
"Jelaskan kepada orang-orang bahwa saya tidak memiliki di setiap sudut toko yang menginstal perangkat lunak bajakan di komputer mereka." Jeyabalachandran Anbalagan
“Keluarga dan teman-teman berpikir bahwa saya dapat memperbaiki segala sesuatu yang terhubung dengan komputer dari jarak jauh. Baik perangkat keras maupun perangkat lunak. Mereka tidak mengerti. Akibatnya, Anda harus mendengarkan komentar pedas mereka seperti "programmer seperti apa Anda, bahkan jika Anda tidak dapat memperbaiki drive DVD di laptop saya". " Jazib babar
"Hanya 1-2% orang yang tahu apa yang sebenarnya saya lakukan." Yasin Pekşen
2. Kurang waktu
Seperti kebanyakan bidang bisnis lainnya, membuat perangkat lunak yang baik membutuhkan waktu. Sayangnya, seperti di tempat lain, manajemen dan / atau pelanggan biasanya tidak ingin menunggu cukup lama untuk mengimplementasikan solusi ideal dengan benar. Akibatnya, pengembang sering didesak untuk membuatnya lebih cepat. Ini mengarah pada penggunaan peretasan yang tidak sedap dipandang, hutang teknis, dokumentasi yang buruk. Pada gilirannya, konsekuensi yang dijelaskan menyebabkan sakit kepala selama perbaikan dan pemeliharaan selanjutnya, terutama untuk programmer yang harus berurusan dengan kode yang sudah jadi.
“Saya ingin melakukan semuanya dengan baik , tetapi karena tekanan saya harus melakukannya dengan tergesa-gesa. Kadang-kadang ini dibenarkan, tetapi perasaan bahwa budaya pemrograman modern sudah terlalu jauh ke arah ini tidak pergi. " Tikhon jelvis
“Hal terburuk bagi saya adalah dengan terburu-buru menulis kode berantakan dan tahu bahwa saya bisa membuatnya jauh lebih elegan. Terus-menerus ditekan oleh kurangnya waktu ... " Gene Sewell
"... Ketika banyak dari apa yang kamu lakukan bahkan tidak menyerupai teknik pemrograman yang baik, dan hanya karena kecepatan lebih penting daripada kualitas, kamu harus melakukan apa yang kamu minta." Jose Palala
"... Selalu tidak ada cukup waktu dan uang untuk menciptakan solusi yang tepat, tetapi mereka selalu cukup untuk memperbaikinya di kemudian hari, lagi dan lagi . " Romi tercengang
1. Bekerja dengan kode orang lain
Cepat atau lambat, pengembang perangkat lunak harus berurusan dengan kode yang ditulis oleh orang lain. Apakah itu kode warisan yang diwarisi dari pendahulu di tempat kerja, atau API pihak ketiga, atau kode yang ditulis oleh konsultan, Anda tidak akan dapat sepenuhnya menghindari kebutuhan untuk memperbaiki, memperluas, dan / atau mengintegrasikan program orang lain. Dan ini sering membuat pengembang merobek rambut dari kepala mereka.
“... Hal terburuk adalah memanjat kode alien, memahaminya, men-debug-nya, mengkonfigurasinya. Dan itu benar-benar gelap ketika orang yang menulisnya telah berhenti dan tidak akan membantu Anda dengan cara apa pun. " Ratnakar sadasyula
"Mencoba mendekripsi ribuan baris kode tidak berdokumen." Simon zhu
"Ada saat-saat ketika saya harus berurusan dengan kode AWESOME yang ditulis oleh konsultan." Joe samson
“Masalah lain yang sangat membuat frustasi adalah API pihak ketiga. Terkadang Anda sangat bergantung pada mereka, dan kemudian Anda melihat masalah, atau beberapa jenis fungsi diperlukan, tetapi API tidak memungkinkan untuk menyelesaikannya sendiri, jadi Anda harus menghubungi penulis dan berharap untuk yang terbaik. " Kevin sekin
“Bug bahasa dan kerangka kerja. Anda menghabiskan waktu berhari-hari untuk mencari tahu mengapa kode Anda tidak berfungsi. Dan hanya untuk menemukan bahwa semuanya adalah bug dalam bahasa atau kerangka kerja . " John paul alcala
"Untuk menemukan kode yang ditulis oleh seseorang yang tidak memiliki kualifikasi yang tepat untuk membuatnya ..." Nani Tatiana Isobel
Mungkin ada hal lain dalam 10 besar Anda? Selamat datang di komentar :)