Pengembang Dosa Mematikan

Secara singkat tentang apa yang paling mengkhawatirkan di dunia pembangunan modern dan mengapa Anda perlu membuktikan, belajar, menguji dan tidak malas.

Saya seorang pengembang, tetapi saya belum menulis kode untuk waktu yang lama

Nichrome Anda bukan pengembang.

Jika Anda berpikir bahwa menulis kode adalah persyaratan opsional untuk pengembang yang baik, maka silakan keluar dari planet ini. Ada banyak kesempatan untuk hidup, tetapi berhenti menulis kode. Anda dapat pergi ke manajemen, Anda dapat bermigrasi ke manajemen personalia, Anda dapat naik ke posisi tinggi, atau Anda bisa pergi ke biara. Tetapi dalam situasi ini, Anda berhenti menjadi pengembang jika Anda tidak lagi menulis kode.

Mengapa Pertama: kodenya bukan sepeda, jika Anda tidak berlatih, Anda lupa. Kedua: para pengembang sangat tersinggung ketika “semacam manajer” mencoba menyamar sebagai milik mereka (ya, secara umum, ini berlaku untuk profesi apa pun). Ketiga: berbahaya bagi CSV; jika Anda pindah ke bidang / industri lain, maka tumbuhkan keterampilan Anda dengan karisma lagi, dan jangan seret referensi ke kesuksesan masa lalu (lihat dosa terakhir).

Dari contoh-contohnya.

1. Saya pernah wawancara di kantor Amerika. Di sana, di salah satu tahap, seorang pria yang memperkenalkan dirinya sebagai CEO mulai menanyakan permainan sengit tentang Ruby dengan selembar kertas (dalam arti template yang disiapkan di Google). Untuk pertanyaan tentang apakah dia menulis kode itu sendiri dan mengapa ketidaksenonohan bertanya kepada pelamar, dia dengan bijaksana membalikkan pembicaraan dan meminta untuk fokus pada tugas.
2. Ada manajer sumber daya yang dikenalnya yang bekerja sebagai psikolog di waktu luangnya. Jadi sampai sekarang, pria ini telah menulis kode di waktu luangnya dan kadang-kadang dapat mengejutkan seorang kandidat dengan pengetahuan yang aneh di bidang yang tampaknya tidak biasa. Tampaknya bukan menjadi programmer, tetapi semua orang mengambilnya sendiri.

Saya menjalankan tes, mengapa menguji aplikasi dengan tangan saya?

Mengandalkan semata-mata pada hasil tes (bahkan jika di antara mereka integrasi boneka end-to-end) adalah dosa serius. Setidaknya satu kali selama pengembangan fitur apa pun, Anda perlu mengambil dan menggunakan tangan Anda untuk mengklik seluruh siklus fitur ini. Pertama, Anda akan sedikit lebih berpengalaman dalam platform dan bagaimana pengguna melihatnya, dan bukan bagaimana itu diatur di dalamnya. Dan kedua, Anda mengikuti skenario baru dan akal sehat dan Anda mungkin menemukan sesuatu yang jelas bagi Anda, tetapi tidak terlihat oleh autotest. Bagaimanapun, autotests adalah tambahan untuk verifikasi manual oleh pengembang, bukan pengganti untuk itu.

Segera saya akan katakan tentang fitur. Saya tidak berbicara tentang pengujian manual lengkap oleh pengembang, ada orang-orang QA terlatih khusus untuk ini. Saya berbicara tentang perlunya menjalankan proyek lokal dan memeriksa minimum untuk setiap perubahan di sana. Dan kemudian di autotests, pada gadis, panggung, preprod dan prod.

Jadi ya, harus ada holivar tentang kompleksitas banyak proyek dan "ketidakmampuan" mereka untuk dijalankan secara lokal. Secara pribadi, saya tidak percaya pada proyek epik seperti itu. Namun dalam kemalasan dan keserakahan - saya percaya. Karena itu, mari kita bahas secara singkat masalah yang mungkin terjadi dalam meluncurkan proyek secara lokal.

1. Proyek independen kecil - tidak ada hambatan untuk patriot!
2. Banyak integrasi eksternal. Jadi, Anda memiliki kotak pasir untuk masing-masing. Entah Anda memiliki stub atau emulator lokal untuk layanan eksternal. Atau Anda memiliki masalah besar yang akan segera dipecat.
3. Banyak layanan microser. Intinya adalah paragraf sebelumnya. Satu-satunya perbedaan adalah bahwa kemungkinan persaingan lokal berkembang. Sebagai contoh, satu set buruh pelabuhan dengan microservices nyata bukan bertopik.
4. Banyak data diperlukan agar proyek dapat bekerja. Tetapi sangat jarang Anda membutuhkan seluruh array data multi-terabyte untuk pengembangan. Dan jika Anda masih membutuhkannya, maka beberapa contoh untuk pengembang dibuat untuk ini. Misalnya, 2-3 contoh besar per tim yang terdiri dari 10-15 pengembang. Jadi ya, ini tidak terlalu nyaman dan mahal untuk bisnis, tetapi jika tidak, Anda akan membayar lebih banyak untuk pengembangan produksi, yang akan dilakukan terlepas dari keinginan manajer puncak.
5. Monolit mengerikan yang bekerja pada besi tertentu dan hanya pada fase bulan yang benar. Jika demikian, maka kemungkinan besar Anda berada di perusahaan berdarah dan akal sehat tidak bekerja di sana.

Saya sudah cukup tahu dan tidak bisa lagi belajar

Singkatnya: "dia yang tidak berkembang, dia menurun."

Dalam ilmu-ilmu teoretis, ada kasus-kasus ketika Anda bisa mengetahui dasar dan berhenti padanya. Semuanya lebih atau kurang stabil, terbukti dan tidak berubah di sana. Untungnya, hukum fisik tidak berubah setiap periode lima tahun. Jadi, jika Anda tidak pergi ke ujung tombak ilmu pengetahuan, Anda dapat hidup dan bahkan bekerja. Di sini, misalnya, adalah integral di sepanjang kontur: Feynman menyelesaikannya di Los Alamos setelah Perang Dunia Kedua dan sekarang mereka diselesaikan dengan metode analitik yang kira-kira sama.

Tetapi dengan pengembangan dan pemrograman tidak akan bekerja seperti itu. Satu bahasa pemrograman ilahi yang tidak berubah-ubah belum ditemukan (konsep dari Longsoran itu menarik, tetapi belum terbuka). Kecepatan perubahan teknologi dari beberapa dekade dalam hal sistem operasi dan database menjadi beberapa bulan dalam kasus JavaScript. Dan jika Anda tidak berkembang, maka dalam satu atau dua tahun Anda bisa kehilangan level, dan dalam periode lima tahun Anda hanya mendapatkan nol.
Agar tidak terlalu holistik tentang kecepatan perubahan teknologi, saya akan memberikan beberapa contoh. Ada buku pembotolan Kernigan dan Solder 1992. Dengan menggunakannya, Anda dapat mempelajari Unix dengan baik dan tidak akan terkejut dengan perubahan yang terjadi 15 tahun kemudian. Anda dapat mengambil buku Tom Kite tentang Oracle 8, yang dirilis sekitar tahun 2000 dan tidak terlalu terkejut dengan perbedaan yang terjadi pada versi 18c. Tetapi buku apa pun di JS lima tahun lalu dapat dengan aman dimasukkan ke kayu bakar.

Saya cukup keren dan tidak bisa membuktikannya

Menurut saya, ini yang paling sulit dan paling umum.

Sayangnya atau untungnya, Anda perlu membuktikan keterampilan, kecocokan profesional, dan kewarasan Anda sepanjang hidup Anda. Ketika Anda berhenti melakukan ini, Anda mungkin menemukan bahwa Anda sudah pensiun, atau Anda menderita demensia, atau Anda baru saja kehabisan tenaga. Bagaimanapun, Anda harus menemui spesialis.

Frekuensi bukti berbeda. Dalam kasus teman dan kerabat, bukti tidak sering diperlukan. Dan dalam kasus orang asing - secara teratur dan penuh. Tempat-tempat di mana bukti dibutuhkan sangat beragam: di wawancara, di konferensi, kepada kolega baru, kekasih baru ... bahkan di toko, jika pembeliannya sedikit lebih rumit daripada bangku.

Jika Anda berpikir bahwa cerita tentang pengalaman Anda tanpa konfirmasi keterampilan adalah normal dan memadai, maka kunjungi planet tetangga. Bagi saya, ini disebut fopping dan arogance.

Mengenai contoh di bidang ini, sangat ketat, karena kebanyakan dari mereka negatif dan, saya pikir, pembaca sendiri akan mengingat sesuatu yang sesuai dari pengalamannya. Dan dengan hal positif itu bahkan lebih sulit, karena mereka tidak diperhatikan dan hanya menghasilkan dialog yang konstruktif. Oleh karena itu, saya percaya pengalaman hidup pembaca dan, saya harap, semua orang akan memberikan contoh yang layak.