Ketika edisi Rusia pertama dari buku terkenal "How to Graze Cats" diterbitkan, didedikasikan untuk topik sulit mengelola secara tidak wajar oleh profesional alam dan bukan pengembang perangkat lunak, kolega saya yang lebih berpengalaman, manajer proyek, mencatat: "Akan lebih tepat untuk menyebutnya" Bagaimana cara merumput ternak "" . Ungkapan itu diingat, dan karena pengalaman itu terakumulasi sejak saat itu dalam berinteraksi dengan acara programmer - seorang kolega benar.
Bagaimana programmer Nena melihat rekan mereka
Di Habré ada cukup banyak artikel yang ditujukan untuk metodologi pengembangan perangkat lunak, komunikasi dan interaksi dalam tim proyek, pemilihan dan perekrutan programmer. Tanpa berlebihan, setiap artikel tersebut mengumpulkan banyak komentar marah dari programmer, di mana mereka menyalahkan "piemas", penguji, staf departemen personalia, analis, pelanggan - untuk siapa saja yang tidak mencintai diri sendiri karena kekurangan dalam metodologi tertentu atau untuk kegagalan dalam proyek. Dalam artikel dan komentar kepada mereka, pendapat yang berlaku adalah bahwa pengembang selalu benar. Prevalensi pendapat ini disebabkan, antara lain, oleh kenyataan bahwa programmer membuat sebagian besar penonton di Habr. Pada saat yang sama, spesialis yang bukan pemrogram bekerja di organisasi dan tim proyek. Artikel ini secara pribadi mengungkapkan dengan tepat sudut pandang satu sisi atau sisi lain yang terbentuk di sisi lain “barikade”.
Hari ini, My Young Friend, saya akan menggambarkan dunia kepada Anda melalui mata rekan-rekan Anda dan memberi tahu Anda tentang bagaimana Anda, Pengembang Perangkat Lunak, Programmer Hebat dan Selalu Benar, menampakkan diri kepada mereka di dunia ini. Apakah Anda yakin bahwa Anda adalah Pusat Semesta, seperti kucing Anda, dan bahwa semua orang berhutang
peti mati sebelum proyek berakhir. Pendapat Anda ini didukung, antara lain, oleh keunggulan kuantitatif kohort Anda di tim proyek, tetapi sebenarnya di sebagian besar proyek di mana Anda, seorang muda atau sudah beruban, tetapi masih belum mendapatkan cukup teman pikiran-pikiran, anggota tim lainnya tenang. membenci kemahatahuanmu dan kesombongan diri yang berlebihan. Keangkuhan Anda hanya diblokir oleh keangkuhan arsitek yang terlalu tinggi dan terlalu tinggi, tetapi berbicara tentang
kasta itu akan terjadi di lain waktu.
Seorang analis bisnis membenci Anda karena bagian-bagian spesifikasi yang paling memakan waktu yang diduga tidak direalisasi karena pengawasan.
Penguji membenci Anda karena meluncurkan bangunan terakhir dengan koreksi 5 menit sebelum akhir hari kerja dan dengan tenang pulang, dan mereka masih harus menghabiskan beberapa jam lembur di malam hari memeriksa lima puluh koreksi dan pengujian regresi sebelum rilis besok.
Manajer proyek membenci Anda karena meludahinya dari menara lonceng tertinggi, karena masa depan Anda, serta gaji di perusahaan, tidak bergantung pada pendapat dan umpan baliknya, tetapi hanya bergantung pada atasan langsung Anda, yang hampir selalu akan menemukan jalan untuk melindungi Anda dari segala kegagalan Anda. Yah, tentu saja, dia membencimu bahkan lebih dari penguji, karena setelah mereka menyelesaikan pengujian mereka dan memberikan lampu hijau untuk rilis final build, dia, pada jam 11 malam, masih harus menyelesaikan pembuatan laporan rilis final untuk tim penempatan dan pemeliharaan untuk pelanggan.
Layanan dukungan membenci Anda untuk kode "didokumentasikan sendiri" dan untuk menghindari jawaban untuk pertanyaan mereka, bahkan jika jam untuk mendukung kode teralienasi secara khusus dialokasikan dalam jadwal Anda dalam proyek baru yang ditugaskan untuk Anda.
Namun, hal pertama yang pertama.
Jalan hidup seorang programmer biasa
Entah bagaimana, setelah satu proyek yang
sukses , saya, dengan persetujuan kepala departemen pengembangan, menyiapkan presentasi untuk kelompok pemrograman, yang, antara lain, termasuk "grafik" yang menggambarkan jalur kehidupan programmer, dari awal, coding di notepad pada usia sekolah melalui pengembangan lingkungan pengembangan terintegrasi (20 tahun), manajemen cacat (25 tahun) dan interaksi dengan kelompok spesialis lain dan kontraktor eksternal (30 tahun), sebelum menerapkan praktik integrasi berkelanjutan dan pengembangan otomatis yvaniya rilis mencapai
penampilan rambut abu-abu 35 tahun (tonggak usia, tentu saja, kondisional, dan hanya melayani untuk menggambarkan cara hidup rata-rata). Seorang programmer, tidak seperti orang lain di dunia modern, dipaksa untuk terus-menerus belajar dan meningkatkan secara teknis dan profesional, dan sangat banyak yang sangat sukses dalam hal ini. Pada saat yang sama, sebagian besar dari mereka yang menulis program
penipuan-peluit pertama mereka "Hello, World" dan menerbitkan resume di hh.ru / monster.com segera mulai menyebarkan jari-jari mereka pada wawancara dan dengan bangga menyebut diri mereka "seorang profesional sejati", - ini sebenarnya tidak.
Dalam proyek itu, satu pengembang berhasil lupa untuk menempatkan kode yang diperbarui dalam repositori umum dan dua rekannya setengah hari dalam mode ekstrem mencoba menentukan mengapa fungsi tidak berfungsi seperti yang dinyatakan? Pengembang lain membuat kesalahan dalam skrip penerapan, dan jika itu tidak diperhatikan oleh manajer proyek (!), Implementasi hasil kolaborasi tim untuk seluruh iterasi akan ditunda sampai siklus berikutnya dari pelepasan kode ke lingkungan produk, mis. selama 2 minggu.
Kedua spesialis memiliki lebih dari satu tahun kerja di belakang mereka, mereka adalah profesional dalam pengembangan perangkat lunak, yaitu Menerima kompensasi uang untuk pekerjaan mereka, tetapi tidak memberi kode "untuk diri mereka sendiri" atau dalam proyek open-source gratis. Namun demikian, mereka membuat kesalahan yang "kekanak-kanakan" tidak peduli apa yang mereka lihat. Ini adalah hal yang terkenal, semua orang mengalami kekurangan, hanya orang yang tidak melakukan apa pun yang tidak memotong. Tapi itu sebabnya saya ingin membuat presentasi itu untuk diperlihatkan oleh para pengembang, berdasarkan pengalaman saya menasihati berbagai tim proyek, yang bidang masalahnya miliki hampir semua programmer dan apa yang tidak terletak di bidang pengetahuan teknologi pemrograman tertentu, tetapi dalam bidang terkait, tempat Anda sangat dicintai, MUD, perancang dan penghancur berakhir, dan keterampilan mulai bekerja dengan persyaratan, alat, cacat, perencanaan, dll. Karena itu, jika di suatu tempat saat membaca artikel dalam salah satu contoh di atas, Anda secara tidak sengaja mengenali diri Anda sendiri, dan setelah membacanya menarik kesimpulan yang tepat dan berhasil "tumbuh di atas diri Anda" - orang lain akan melihat Anda sebagai seorang profesional di bidangnya dan akan bersukacita karenanya. yang bekerja dengan Anda dalam proyek dan tim yang sama.
Interaksi dengan non-programmer
Beri tahu Anda, My Skillful Friend, bahwa spesialis lain yang bekerja sama dengan Anda di tim proyek, seperti penguji, analis, penulis teknis, perancang, dan lainnya, tidak kurang bertanggung jawab atas keberhasilan proyek daripada Anda
, oh keajaiban alam semesta . Dan semua orang bukan manusia ini memainkan peran tidak kurang, dan dalam beberapa proyek bahkan lebih besar daripada peran Anda sebagai pembuat enkode, dan karenanya interaksi yang kompeten dan baik hati dengan mereka adalah bagian integral dan kunci dari pekerjaan Anda, di mana Anda menerima banyak uang dari ATM dua kali sebulan (untuk dalam satu kata - uangnya
jauh lebih besar daripada yang dikeluarkan orang-orang ini dari ATM yang sama). Anda sering melihat mereka dan kebutuhan desain mereka dari atas atau melalui jari-jari Anda, tanpa perhatian yang mereka butuhkan. Dan mereka memiliki kebutuhan dan harapan profesional, dan beragam, tergantung pada peran mereka.
Analis, misalnya, mengharapkan bahwa Anda tidak hanya akan berdalih tentang dan tanpa setiap huruf dalam spesifikasi, tetapi juga akan dengan cermat menerjemahkannya ke dalam kode program. Dan Anda tidak akan melakukan goggle ketika, selama pengujian, mereka bertanya mengapa Anda tidak mengimplementasikan fungsi kunci yang termasuk dalam rilis besok dan menetapkan persyaratan sebelum Anda ditunjuk ke tim proyek setahun yang lalu, selalu ada di sana. dan sejak itu tidak pernah mengubah satu huruf pun.
Penguji berhak untuk mengharapkan dari Anda hasil kualitas bebas bug dari pekerjaan Anda. Ketika dia dipekerjakan, dia dijanjikan dan oleh karena itu dia berharap bahwa dia tidak akan menjadi bagian dari metodologi pengembangan TDD, yang menurut Anda, MUD, "membuang" produk yang belum selesai untuk pengujian dan, berdasarkan hasilnya, melengkapi bagian-bagian fungsional yang hilang dan memperbaiki cacat yang jelas. Dan penguji tentu berharap bahwa Anda tidak akan menyebarkan pembusukan karena fakta bahwa dia tidak tahu cara menguji produk selain dari manual, atau bahwa keahliannya dalam bekerja dengan bahasa query database jauh lebih rendah daripada milik Anda. Pada akhirnya, jangan lupa bahwa mereka membayarnya untuk pengujian manual beberapa kali lebih sedikit daripada yang Anda lakukan untuk pemrograman, dan bahwa jika dia tahu SQL sebaik Anda, maka dia akan duduk di kursi Anda di depan monitor Anda, dan tidak Anda, karena dengan kualifikasi yang sama antara Anda, itu akan menjadi dia yang lebih suka meninggalkannya di tim dan organisasi, karena, tidak seperti Anda, setelah melewati jalan yang sulit dari penguji, dia tidak akan pernah menyebar busuk pada rekan-rekannya seperti Anda.
Pengetahuan teknik teknologi
Sudahkah Anda menyelesaikan institut
taman kanak -
kanak dan pada wawancara Anda berhasil menjelaskan bagaimana perancang berbeda dari destruktor? Saya akan memberi tahu Anda sebuah rahasia bahwa dunia profesional dalam menciptakan perangkat lunak tidak terbatas pada pengetahuan ini, dan jika Anda terus berpikir bahwa kode tertulis dan entah bagaimana dapat dieksekusi adalah hasil yang cukup dari pekerjaan Anda untuk
tidak mendapatkan lyuley
dari manajer proyek / pelanggan untuk menerima sn dua kali sebulan, Anda berada di dalam karir masa depan Anda, Anda akan menyapu lebih banyak masalah di kepala Anda sendiri, dan yang paling penting, Anda akan menjadi sumber sakit kepala persisten bagi semua orang yang tidak cukup beruntung untuk bekerja di sebelah Anda.
"Versi? Mengomentari kodenya? Mengikuti standar pengkodean dan penamaan? Tidak, saya belum pernah mendengar! " Jadi katakan kolega Anda di sini dan di sini di berbagai tim dan organisasi proyek. Teman muda, Anda merengek tentang segala sesuatu yang tidak terkait langsung dengan "penusukan kode": tentang perlunya menambahkan komentar, tutup kode dengan uji blok sesuai dengan standar yang ditetapkan di perusahaan atau departemen, menggabungkan cabang repositori ... Apa yang bisa kita katakan tentang hal-hal yang lebih kompleks yang memerlukan maju atau benar-benar sangat berkualitas: otomatisasi uji, implementasi dan dukungan untuk integrasi berkelanjutan, menyiapkan bundel Bambu-Mentimun-Maven-Boneka, banyak jam menggali ke dalam log sistem dalam pencarian x bukti kesalahan perangkat lunak - semua ini untuk Anda kebosanan dan ampas yang tidak memungkinkan Anda untuk meningkatkan keterampilan pengkodean Anda secara langsung dan yang Anda temukan meremehkan FAQ Anda. Selain itu, dengan menolak untuk menggunakan perangkat keras tertentu, Anda, seorang pengembang perangkat lunak profesional, seringkali menyembunyikan ketidakmampuan Anda untuk menggunakannya. Saya ingat reaksi dan wajah seorang programmer yang, sebagai upaya untuk menangkap cacat "mengambang" yang sulit ditemukan, disarankan menggunakan profiler yang ada di dalam IDE: Saya diberitahu bahwa itu bukan pekerjaan anjing dari manajer proyek untuk memberi tahu alat apa yang harus digunakan oleh programmer dalam pekerjaannya.
Keterampilan Alat
Seberapa otomatis pekerjaan Anda di dalam workstation Anda? Sudahkah Anda memompa keterampilan Anda dalam bekerja dengan ekspresi reguler, membuat dan menjalankan file batch? Atas permintaan kolega, penguji, analis atau pelanggan, dapatkah Anda menguraikan beberapa ratus ribu baris log pada server jarak jauh dalam 3 menit, menemukan entri yang diperlukan dari parameter kunci, mengemas output, meneruskannya ke alamat yang ditentukan dan kembali ke tugas yang terganggu? Seberapa cepat, MUD, Anda tahu bagaimana melakukan operasi rutin yang membutuhkan pengulangan berulang selama hari kerja?
Seperti yang Anda ketahui, memulai kompilasi di lingkungan pengembangan modern dimungkinkan dengan menekan F5 (atau F6? Atau F13? .. Pada akhirnya, mengapa saya, manajer proyek, perlu mengetahui hal-hal seperti itu? Anda tidak tahu, MUD, seberapa cepat, dalam beberapa menit) bongkar dari Jira, format dengan benar di Excel dan kirim e-mail ke pelanggan tentang laporan cacat dengan
blackjet dan grafik
pelacur dan tren, tetapi Anda tidak akan pernah gagal menyematkan "piem" Anda di ruang merokok di antara rekan kerja Anda bahwa itu tidak bodoh tahu bagaimana destruktor berbeda dari konstruktor). Tetapi untuk karir yang cukup panjang, saya belum pernah bertemu dengan begitu banyak programmer yang menggunakan pintasan keyboard pada keyboard untuk menjalankan tindakan standar tertentu - kebanyakan dari mereka menggunakan manipulator "mouse" yang lebih lambat. Conditional "Tab - 1000 - Tab - 1 - Tab - 0 - Tab - Backspace - 2 - Ctrl + S - Ctrl-F6 - Enter, Alt-Tab, F5" dalam 6 detik memungkinkan pro nyata untuk melakukan apa dengan menjentikkan dan menusuk mouse dengan jari telunjuk pada keyboard, yang lambat melakukan lima menit panjang. Dan ketika operasi seperti itu dilakukan ratusan kali sehari, dalam konteks tenggat waktu yang mendekat, manajer proyek lain kadang-kadang ingin
mengambil dan ...... memindahkan "profesional" dari keyboard dan membuat perubahan / kompilasi / tata letak kode yang dapat dieksekusi dan berikan lampu hijau kepada kelompok pengujian Bangunan baru akhirnya siap.
Oleh karena itu, MUD, jangan malas dan habiskan waktu untuk menguasai pencetakan sepuluh jari yang buta dan metode kerja yang efektif dengan alat-alat dan percayalah pada orang yang lebih berpengalaman, bahkan jika beberapa dari mereka begitu tidak dicintai oleh manajer proyek Anda - kali ini akan terbayar dengan baik. Sementara itu, Anda, anak muda yang canggung, belum mencapai kesempurnaan dalam hal ini - Pergilah, kubur diri Anda di monitor dan Tulis Kode, Bl ..!
Penilaian tenaga kerja
Anda tidak tahan ketika manajer proyek melakukan intervensi dalam proses sakral "penulisan kode." Tetapi pada saat yang sama, Anda tidak akan pernah menyangkal diri Anda kesenangan mengeluarkan komentar pedas tentang tenggat waktu "tidak realistis", persyaratan "bocor", permintaan perubahan yang tidak tepat waktu, manajer proyek yang tidak kompeten. Ketika, dalam kerangka metodologi tertentu, mereka berpaling kepada Anda untuk pendapat ahli tentang penilaian biaya tenaga kerja untuk iterasi berikutnya atau untuk seluruh proyek, Anda membuat wajah terkejut dan mulai "membuat alasan" tentang spesifikasi yang tidak dapat dipahami atau tidak lengkap, teknologi yang tidak diketahui, dan bahwa itu bukan urusan Anda sama sekali. untuk merencanakan, Anda tidak punya waktu untuk "omong kosong" dan lebih baik Anda pergi dan melakukan hal yang nyata - menulis kode. “Estimasi biaya tenaga kerja dengan metode poin fungsional? Dengan analogi berdasarkan hasil sebelumnya? Berdasarkan jumlah formulir layar dan permintaan I / O basis data? Tidak, saya belum pernah mendengar! "
Karena itu, seorang teman muda, diamlah dalam lap ketika bukan urusan Anda merencanakan pekerjaan di proyek, atau tingkatkan keterampilan Anda sendiri dalam mengeluarkan penilaian ahli yang sesungguhnya, dan jangan dengan jari Anda di langit. Dan sampai Anda menguasai yang terakhir -
IPKB !!!
Kode Hindu
Salah satu hiburan favorit Anda adalah mengkritik kode perangkat lunak yang dibuat oleh pengembang India. Jangan memberi Anda roti, tetapi biarkan kami mengolok-olok gaya pemrograman "pasta". Lebih dari membahas kode "Hindu", Anda hanya suka mengobrol tentang teknologi (lihat di bawah). Dan semua ini terlepas dari kenyataan bahwa Anda sendiri memanggil metode dengan nama bangga kolbasa (), menyalin potongan kode yang tidak dapat dimaafkan ke tempat yang berbeda dalam program ini dan membuat kelas ukuran selusin atau dua layar.
Dengan tidak signifikannya pengalaman profesional Anda sendiri, , tidak familiar bagi Anda bahwa
omong kosong kode yang Anda tulis sendiri sering kali tidak lebih baik dan kadang-kadang lebih buruk daripada kode yang dibuat rekan kerja selatan Anda. Pemrogram yang menyedihkan hadir di negara mana pun, "jangan menilai, janganlah kita dihakimi", dan profesional sejati, saya akan memberitahu Anda sebuah rahasia, MJD, jangan turun ke celaan rekan-rekan mereka secara nasional, dan perlahan-lahan tingkatkan kualifikasi dan waktu mereka sendiri, dialokasikan untuk pembuatan produk perangkat lunak, mereka menghabiskan langsung untuk pemrograman, dan bukan untuk mencari
sedotan di mata orang lain dalam cacat pada kode orang lain.
Diskusi teknologi tanpa akhir
Anda tanpa henti berdiskusi dengan programmer lain apa Java ++ lebih unggul dari C ## atau versi apa nomor seratus dua puluh sembilan fraksi lima belas dari setiap perpustakaan Javascript lebih baik daripada versi seratus dua puluh sembilan fraksi tiga belas. Anda tidak pernah merasa menyesal atas diskusi seperti itu bahkan di hari-hari ketika 2-3 hari atau minggu tetap sebelum akhir iterasi atau proyek multi-bulan dan jumlah cacat serius yang tidak dikoreksi yang ditugaskan kepada Anda melebihi lima puluh.
Anda melakukan ini tanpa sedikitpun nurani selama jam kerja, dan tidak pada Jumat malam atau di akhir pekan untuk segelas bir. Anda terlibat dalam obrolan semacam itu meskipun fakta bahwa pertanyaan memilih dan menggunakan satu atau beberapa teknologi lain dalam suatu produk berada di luar ruang lingkup kompetensi Anda (karena ukuran kompetensi Anda, MJD, belum tumbuh dewasa), tetapi Anda masih menghabiskan waktu dengan majikan dan proyek pada trepot tidak produktif.Mengeluh tentang demonstrasi yang "tidak perlu"
Karena itu, ketika, setelah Anda baru saja menghabiskan waktu berbicara, saya berbicara selama 2 jam di dapur / ruang merokok dengan setengah lusin kode sandi yang sama tentang kerangka kerja / konferensi pers Google-Microsoft-Apple-Linus Torvalds kemarin, daripada mencuri beberapa orang- hari pembangunan, Anda tiba-tiba pada analisis negara iterasi selesai bahwa terlalu banyak pertemuan yang tidak perlu diadakan dalam proyek dan Anda perlu mempersingkat mereka - dalam menanggapi ini Anda hanya ingin berteriak: tutup mulut dan IPKB !!!Literate Russian
Ya, pada akhirnya, seperti kata mereka, yang terakhir, tetapi jauh dari yang paling tidak penting. Bahkan jika Anda, MUD, fasih dalam bahasa seperti C ## atau Brainwave - ini tidak sepenuhnya menyelamatkan Anda dari kebutuhan untuk menulis dan berbicara bahasa Rusia dengan benar (dan dalam bahasa Inggris juga, abad XXI di halaman). Oleh karena itu, sebelum waktu berikutnya Anda akan dapat menulis spesifikasi, komentar pada kode, surat kepada pelanggan atau artikel cerdas Anda dan komentar di sini atau pada beberapa sumber lain untuk coders cepat - pergi dan belajar bahasa Rusia dengan benar, bl ..! Lakukan agar apa pun yang Anda tulis - orang yang kompeten akan membacanya dengan mudah dan gembira, dan tidak akan tersandung pada setiap huruf ejaan Anda. Kunjungi dan hafalkan konten situs tsya.rudan ingat sudah akhirnya bahwa "tester" - sebuah perangkat untuk menentukan nilai-nilai parameter jaringan listrik yang berbeda, dan pengujian perangkat lunak profesional yang disebut " tester " dan bahwa "fungsional" - sebuah istilah matematika untuk satu set perangkat lunak fitur yang disebut "fungsional nost " bl .. !! 111Epilog
Saya berharap saran yang diberikan di atas akan cocok untuk Anda di masa depan, dan seiring waktu Anda akan tumbuh menjadi insinyur nyata untuk pengembangan perangkat lunak, seorang profesional di bidangnya yang kompeten dan sopan berinteraksi dengan kolega di toko, melakukan pekerjaannya secara efisien dan tepat waktu. Saya berharap Anda sukses dalam kerja keras Anda! Dan tolong, selalu ingat bahwa sesama non-programer Anda pantas mendapatkan cinta dan hormat tidak kurang dengan pekerjaan mereka daripada Anda dan kucing.
Selain itu
Dalam komentar untuk edisi pertama artikel, pertanyaan diajukan: di mana Anda mendapatkan pengembang seperti itu? Khususnya, tentu saja, penulis artikel tidak memilih orang-orang seperti itu dalam tim proyeknya, tetapi ada gambar yang sama di hampir semua organisasi.Tentu saja, tidak semua pengembang profesional yang bekerja di bidang IT mirip dengan yang dijelaskan dalam artikel. Penulis setuju dengan pendapat luas bahwa seorang programmer ahli 10 kali lebih produktif daripada rekan pemulanya. Produktivitas pengembang tangan rata-rata adalah sekitar 3 kali lebih tinggi daripada seorang pemula, pejalan kaki atau ketidakmampuan dan produktivitas, knalpot akhir dari seorang ahli, guru, "bison" juga sekitar 3 kali lebih tinggi daripada seorang profesional biasa.Dalam pengalaman saya, rasio kuantitatif dari jumlah pengembang berketerampilan rendah untuk biasa dan biasa untuk para ahli hampir sama: 1 hingga 3 dan 3 sampai 1. Proporsi ini dapat sangat bervariasi dari satu organisasi ke yang lain, tetapi rata-rata mereka cukup benar. Sepanjang karir saya, saya telah bekerja dengan empat orang, yang saya klasifikasikan sepenuhnya untuk diri saya sendiri dalam kategori " bintang " (bagian ekstrem dari "spektrum"). Mereka tahu segala yang diperlukan untuk pelaksanaan tugas mereka, ditambah lebih dari itu, para ahli menilai biaya tenaga kerja, melakukan pekerjaan dalam waktu yang ditentukan, setelah mereka bekerja di proyek, pada produk atau di perusahaan, mereka meninggalkan artefak yang terdokumentasi dengan jelas.“ Biasa saja"Pemrogram, mereka yang tahu bagaimana melakukan banyak hal" bintang "bisa, tetapi tidak bersama-sama, ada mayoritas absolut. Artikel mereka, jelas, tidak berkaitan, atau hanya menyangkut fakta bahwa beberapa sketsa yang diberikan dapat membuat mereka tersenyum seperti “tetapi, ya, saya ingat, saya ingat bahwa perusahaan melakukan hal yang sama di XYZ, Ya Tuhan, betapa bodohnya saya saat itu adalah (dua / lima / dua puluh tahun yang lalu)! ".Tentang jumlah yang sama dengan "bintang-bintang", saya bertemu dengan " mencungkil " yang sebenarnya, hanya mereka yang digambarkan secara tidak enak di artikel: licik, tergesa-gesa, bodoh, memandang rendah semua rekan mereka yang bukan programmer di kantor (kecuali untuk langsung mereka) bos), tidak mau belajar, atau tidak menyadari perlunya "ikspertov.Artikel ini dikhususkan untuk kategori terakhir.