Tahun kesepuluh akan segera datang, karena saya secara profesional terlibat dalam pemrograman. Sepuluh tahun! Dan selain pekerjaan formal, hampir dua pertiga dari hidup saya, saya menciptakan sesuatu di Internet. Saya hampir tidak ingat tahun-tahun ketika saya tidak tahu HTML: bahkan aneh jika Anda memikirkannya. Beberapa anak belajar musik atau balet, dan sebaliknya saya menciptakan dunia magis, mengkodekan di kamar anak-anak saya.

Memikirkan dekade pertama ini secara teratur menerima uang untuk memasukkan karakter aneh ke terminal, saya ingin berbagi beberapa pengamatan tentang bagaimana pemikiran saya telah berubah selama bertahun-tahun bekerja .

Mungkin junior saat ini akan menemukan beberapa kepercayaan mereka di sini dan melihat mereka dari sisi lain. Atau mereka menyadari bahwa mereka telah menyingkirkan ini, jadi mereka melangkah lebih jauh daripada saya di panggung Anda.

Para senior saat ini juga mungkin ingin berbagi cerita lucu (dan sedikit memalukan) tentang pelajaran apa yang telah dipelajari dari pengalaman junior mereka.

Untuk lebih jelasnya, saya menekankan bahwa junior sangat luar biasa : hanya muncul di tempat kerja untuk mempelajari hal-hal baru - ini sudah membutuhkan banyak keberanian. Artikel ini adalah tentang pengalaman dan pelatihan saya sendiri. Saya tidak menggeneralisasi sama sekali bahwa semua pengembang junior berpikir atau berperilaku seperti ini.

Saya harap Anda menikmati pos dan mengingatkan Anda tentang sesuatu dari masa lalu atau masa kini.

Terima kasih kepada Artyom dan Sarah atas umpan baliknya!

Kebenaran absolut dari junior yang darinya perlu dilepaskan

1. Saya adalah pengembang senior

Ketika saya pertama kali mencoba mendapatkan pekerjaan, saya berusia 19 tahun. Pekerjaan itu disebut "webmaster siswa." Ini adalah nama yang agak mengejutkan untuk karya ini, karena Anda dianggap sebagai "murid" dan "tuan" pada saat yang sama. Saat ini, semua orang ingin menjadi "insinyur," karena kedengarannya lebih modis, tetapi bagi saya, "tuan" adalah kata yang lebih baik untuk kerajinan ini. Bagaimanapun, pekerjaan saya adalah menulis PHP dan MySQL dan memelihara situs kami di Drupal, serta membuat beberapa alat internal.

Karena sebelumnya saya telah mengkode selama beberapa tahun di kamar saya, saya yakin tahun-tahun ini dianggap sebagai "tahun pengalaman". Karena itu, ketika ditanya tentang berapa banyak pengalaman yang saya tulis dalam PHP, saya dengan percaya diri menjawab: "3 atau 4 tahun!"

Saya pikir saya tahu banyak tentang SQL karena saya bisa melakukan outer joins (outer joins).

Dan ketika saya mencari di Google, saya tahu bahwa pengalaman tiga hingga empat tahun berarti banyak uang.

Mari kita beralih ke pekerjaan terakhir saya, yang saya dapatkan setelah lima tahun pengalaman "gabungan" siswa dan profesional (yang saya anggap pengalaman normal). Saat itu, kode saya hampir tidak pernah melalui tinjauan kode. Saya menjalankan ssh di server dan melakukan git pull. Saya yakin saya belum pernah melihat satu pun permintaan tarik. Jangan salah paham, dalam dua karya pertama saya belajar banyak hal luar biasa, saya hanya pernah bekerja dengan pengembang lain di basis kode yang sama. Namun demikian, saya melamar posisi "insinyur front-end senior", menerima tawaran dan menerimanya.

Jadi saya menjadi pengembang senior di usia dewasa 24 tahun.

Lagi pula, mereka tidak akan memberi saya posisi ini jika saya benar-benar bukan pengembang senior, bukan ?! Tentu saja, pengalaman saya yang mengesankan telah membawa saya ke puncak ini, jadi orang harus mendengarkan saya !!! Saya berada di puncak karir teknis saya, sedangkan yang termuda di kantor.

Persis seperti bos.

Apa yang akhirnya saya mengerti

Tidak semua pengalaman itu sama . Pengalaman pengkodean saya di kamar tidur, pekerjaan seorang programmer mahasiswa berbeda dari penelitian ilmiah dalam ilmu komputer dan bekerja dalam startup yang sedang tumbuh. Ini pengalaman yang berbeda. Selama setahun bekerja dalam dukungan teknis di awal karir Anda, Anda dapat belajar sepuluh kali lebih dari lima tahun dalam proyek-proyek individual (atau dengan umpan balik minimal). Jika kode Anda tidak pernah dilihat oleh rekan kerja, pelatihan jauh lebih lambat.

Itu sebabnya mentor sangat penting , dan tim Anda jauh lebih penting daripada perbedaan dalam beberapa dolar dalam gaji. Jangan puas dengan posisi junior di mana Anda akan bekerja sendiri! Dan jangan memilih pekerjaan pertama Anda (atau, sejujurnya, pekerjaan apa pun) hanya berdasarkan gaji. Tim adalah tempat nilai sebenarnya.

Saya juga belajar bahwa jabatan tidak berarti apa-apa . Posisi CTO dapat berada dalam tim yang terdiri dari 5 orang, 50 atau 500 orang. Ini adalah pekerjaan yang sama sekali berbeda, meskipun namanya identik. Jadi gelar "senior" saya sama sekali tidak menjadikan saya seorang programmer terkemuka. Selain itu, judul hierarkis secara inheren cacat dan sulit untuk dibandingkan. Saya menyadari bahwa penting untuk tidak terjebak dalam nama dan Anda tidak boleh menggunakannya sebagai semacam pemeriksaan eksternal.

2. Semua orang menulis tes

Paruh pertama karir saya, saya bekerja di bidang penelitian. Secara khusus, tiga setengah tahun pada satu proyek dengan dana negara, dan kemudian satu setengah tahun di universitas di departemen pemrosesan bahasa alami. Saya dapat mengatakan satu hal: pemrograman dalam lingkungan ilmiah sama sekali berbeda dari pemrograman dalam industri komersial .

Sebagian besar, Anda tidak membangun aplikasi. Anda bekerja pada algoritme atau menganalisis kumpulan data. Atau, jika Anda membuat aplikasi, kemungkinan besar pekerjaan itu didanai oleh negara. Ini berarti gratis untuk orang lain dan biasanya open source. Dan ketika sesuatu itu gratis, itu berarti bahwa biasanya Anda tidak bertanggung jawab untuk memastikan bahwa itu selalu tersedia.

Karena ... yah, gratis.

Anda juga tidak bertanggung jawab atas pendapatan finansial atau hasil tertentu. Namun, pekerjaan seorang programmer di lembaga ilmiah adalah topik untuk artikel yang sama sekali berbeda.

Singkatnya, saya meninggalkan institut dengan harapan besar.

Harapan tentang bagaimana industri ini bekerja. Penerapan otomatis. Tarik permintaan dan ulasan kode. Itu akan luar biasa! Akhirnya, kualitas kode yang saya impikan! Tetapi terlepas dari kode berkualitas tinggi dengan standar yang tepat dan praktik terbaik , saya sangat percaya bahwa dalam industri perangkat lunak setiap orang menulis tes .

Hm ...

Jadi bayangkan kejutan saya ketika pada hari kerja pertama di startup saya tidak menemukan tes. Tidak ada tes di antarmuka. Tidak ada tes di backend. Tidak ada tes sama sekali.

Nda. Tidak ada Nol NaN. Tes tidak ada sebagai fenomena.

Tidak hanya tidak ada tes , tetapi sepertinya tidak ada yang punya masalah karena ini! Dengan sedikit naif, saya menyarankan bahwa alasannya adalah karena orang tidak tahu bagaimana menulis tes untuk AngularJS. Jika saya mengajar mereka, semuanya akan berhasil - dan kami akan mulai melakukan tes. Kesalahan! Secara umum, hanya beberapa tahun kemudian kami menerapkan tes otomatis dalam kode, dan itu tidak semudah yang saya kira.

Tetapi bukan karena orang tidak tahu cara menulisnya.

Entah mereka tidak pernah mengalami masalah karena kurangnya tes, atau mereka mengalami masalah dari kehadiran tes lama . Dua hal yang belum pernah saya temui.

Apa yang akhirnya saya mengerti

Banyak perusahaan dan startup yang tidak memiliki tes . Ketika berjuang untuk pasar atau untuk bertahan hidup, banyak perusahaan mengabaikan pengujian pada tahap awal. Bahkan perusahaan-perusahaan trendi yang mensponsori konferensi atau open source sering membuat monolit kikuk besar dengan tes minimal. Tanyakan kepada pengembang tentang status basis kode.

Tidak ada perusahaan yang memiliki instalasi teknis yang ideal . Setiap perusahaan memiliki masalah, masing-masing memiliki hutang teknis. Pertanyaannya adalah apa yang mereka lakukan dengannya. Saat melamar pekerjaan, Anda perlu memahami dengan jelas bahwa semuanya tidak beres di sana, jika tidak mereka tidak akan membuka lowongan.

Menjadi terlalu percaya diri dalam hal-hal di mana Anda tidak memiliki pengalaman nyata agak sombong . Saya bertindak SEPERTI yang tahu segalanya, bersikeras pada implementasi tes yang luas, dengan hampir tidak ada pengalaman bagaimana benar-benar mengimplementasikan ini dalam skala besar. Jangan ulangi kesalahan saya. Penting untuk memiliki prinsip, tetapi tetap penting untuk terbuka dan benar-benar tertarik untuk memahami pengalaman dan pandangan orang lain.

3. Kami sangat ketinggalan (alias versi teknis dari sindrom untung )

Ini terkait erat dengan topik pengujian unit. Perusahaan saya tidak melakukan tes, tetapi, tentu saja, semua perusahaan lain melakukannya, kan?

Saya membaca banyak posting blog. Saya menyaksikan banyak pidato konferensi di YouTube. Sial, saya membaca "situs oranye itu" sepanjang waktu [mungkin mengacu pada Hacker News - kira-kira. trans.]. Semua orang tampaknya menulis aplikasi yang sangat canggih dan berkualitas tinggi dengan kinerja hebat dan animasi yang trendi, sementara saya hanya membuat tambalan yang mencoba mengejar tenggat waktu.

Saya benar-benar mengidolakan semua perusahaan lain yang saya baca, dan kecewa dengan seberapa banyak perusahaan saya dan proyek tertinggal di belakang mereka.

Apa yang akhirnya saya mengerti

Banyak presentasi konferensi mencakup bukti konsep, bukan skenario kehidupan nyata . Hanya sebuah cerita di sebuah konferensi tentang teknologi tidak berarti bahwa perusahaan menggunakan teknologi ini dalam pekerjaan sehari-hari atau bahwa semua kode mereka dalam kondisi sempurna. Speaker konferensi sering menghadirkan aplikasi mainan daripada aplikasi nyata: penting untuk membedakannya.

Bekerja dengan Legacy sepenuhnya normal . Tidak, serius, mudah untuk membayangkan bahwa beberapa perusahaan lain tidak memiliki warisan. Tetapi setelah menghabiskan waktu di konferensi, berbicara dengan orang-orang yang bekerja di perusahaan top, menjadi jelas bahwa kita semua berada di kapal yang sama. Cobalah untuk menemukan perusahaan yang TIDAK memiliki monolit besar di PHP atau Ruby yang mereka coba jinakkan (atau harus dijinakkan pada titik tertentu)? Kode lama adalah hal yang lumrah, dan bekerja dengannya sering mengajarkan Anda lebih dari membuat aplikasi dari awal, karena Anda bekerja lebih banyak dengan konsep yang masih belum Anda pahami.

4. Kualitas kode sangat penting.

Di masa lalu, saya bisa melakukan review kode yang sangat sulit .

Setidaknya saya sangat pemilih soal gaya. Gaya saya berubah menjadi versi modifikasi dari gaya panduan gaya JavaScript Airbnb, tetapi cocok dengan selera pribadi saya. Hal-hal seperti indentasi, pemformatan, penamaan - Tuhan melarang, Anda akan melakukannya secara berbeda. Benar-benar mustahil untuk melalui peninjauan kode tanpa satu komentar dari saya: Anda harus mempelajari keterampilan membaca pikiran dan, di samping itu, memenangkan lotre.

Kirim lebih dari 50 komentar ke permintaan tarik Anda yang mencantumkan semua titik koma yang Anda lewatkan!

Karena saya memiliki mata seperti elang - dan elang ini ingin mendapatkan semua titik koma berkualitas tinggi!

(Untungnya, setelah bertahun-tahun bekerja di depan komputer, visi elang telah hilang, jadi sekarang Anda tidak perlu khawatir - # lelucon)

Apa yang akhirnya saya mengerti

Cukup bagus - itu sudah cukup . Saat mendekati kode ideal, hukum pengembalian yang semakin menurun berlaku. Kode tidak boleh sempurna, tetapi cukup bersih untuk bekerja dan bukan bencana yang lengkap untuk dukungan. Seringkali kode yang terlalu berulang atau terlalu bertele-tele lebih mudah dipahami orang lain. Selain itu, "kode yang baik" tidak sama dengan "kode yang sepertinya saya tulis sendiri."

Arsitektur lebih penting daripada nitpicking . Meskipun beberapa garis dapat diperbaiki, tetapi masalah utama adalah tatanan arsitektur. Lebih baik segera fokus pada struktur aplikasi, daripada pada potongan kode kecil individual.

Kualitas kode itu penting , jangan salah paham. Tetapi kualitas kode itu tidak seperti yang saya pikirkan. Ini bukan linting, format, atau gaya apa pun yang dijelaskan dalam artikel terakhir yang saya baca.

5. Semuanya harus didokumentasikan !!!

Ketika saya datang ke perusahaan nyata pertama saya, untuk pertama kalinya saya menemukan kode aneh untuk pertama kalinya. Tentu saja, saya bekerja sedikit dengan kode orang lain pada pekerjaan pertama, tetapi saya tidak pernah harus pergi ke basis kode yang ada dan mencari tahu apa yang sedang terjadi di sini. Satu-satunya saat ini terjadi, saya menulis ulang semua kode, alih-alih mencoba memahami cara kerjanya.

Bagaimanapun, fakta bahwa itu adalah kode AngularJS yang ditulis oleh pengembang Ruby tidak membantu situasi sama sekali, dan aku adalah seorang junior yang membayangkan dirinya seorang senior.

Jadi, bagaimana saya menghadapi kenyataan bahwa 300 baris kode asing membuat saya merasa seperti tenggelam?

JSDOC. DI MANA SAJA.

Saya mulai berkomentar semuanya untuk mencoba masuk akal. Anotasi untuk setiap fitur yang saya dapatkan.

Saya belajar semua sintaks JSDoc mewah Angular-spesifik ini. Kode saya selalu dua kali lebih panjang karena memiliki begitu banyak dokumentasi dan komentar.

Apa yang akhirnya saya mengerti

Dokumentasi terkadang bohong . Sangat mudah untuk berpikir bahwa dokumentasi menyelesaikan semua masalah. "Kita butuh dermaga!" Meskipun dokumentasi adalah kerja keras, itu perlu dilakukan. Anda hanya perlu mendokumentasikan hal-hal yang benar dengan cara yang benar. Dokumentasi berlebihan tentang hal-hal yang tidak perlu, sebagai suatu peraturan, mencegah orang-orang yang mencoba menyelesaikan masalah nyata.

Jika perlu, fokuslah pada otomatisasi alih-alih dokumentasi . Tes atau bentuk otomatisasi lainnya cenderung kehilangan relevansi. Oleh karena itu, saya mencoba untuk fokus pada penulisan tes yang bagus dengan bahasa yang jelas sehingga pengembang lain dapat melihat bagaimana proyek bekerja dengan kode kerja. Contoh lain adalah mengotomatiskan instalasi aplikasi dengan beberapa komentar, daripada panduan instalasi yang panjang dan terperinci.

6. Hutang teknis buruk

Jika setelah poin terakhir Anda menganggap saya seorang neurotik, baca saja yang ini! Untuk beberapa waktu dalam karier saya, saya menganggap kode kotor sebagai tugas teknis . Utang teknis adalah istilah yang lucu karena jika Anda meminta contoh, mereka mengatakan hal-hal yang sangat berbeda.

Karena saya menganggap kode "tidak teratur" sebagai tugas teknis, saya segera mencoba menghilangkannya dengan sangat keras!

Suatu kali saya benar-benar menghabiskan akhir pekan secara manual mengoreksi 800 kesalahan linting.

Itulah neurotik saya.

(Penafian: ini sebelum koreksi otomatis muncul).

Apa yang akhirnya saya mengerti

Kode yang tidak terorganisir atau berantakan tidak sama dengan tugas teknis . Hanya kondisi yang tidak sempurna tidak berarti bahwa itu adalah tugas teknis. Utang teknis sebenarnya memperlambat Anda dalam beberapa cara, atau membuat jenis perubahan tertentu sulit atau rawan kesalahan. Jika kodenya sedikit berantakan, itu hanya sedikit berantakan. Membersihkan mungkin tidak sepadan dengan waktu Anda.

Memiliki hutang teknis adalah hal biasa . Kadang-kadang kita mempersingkat jalan, karena kita perlu melakukan pekerjaan dengan segera, dan untuk ini kita “meminjamkan” sebagian waktu di masa depan. Memiliki cuplikan kode yang merupakan "utang teknis" nyata adalah normal jika Anda mengakui bahwa Anda mungkin harus mengembalikannya. Jika basis kode Anda, menurut Anda, bebas dari hutang teknis, kemungkinan besar Anda melebih-lebihkan penampilannya sehingga merugikan pengiriman . Dan Tuhanku, betapa aku melebih-lebihkannya!

7. Semakin tinggi posisi programmer, semakin baik programnya

Setelah mulai pemrograman pada usia yang cukup muda, saya menjadi profesional sejati dalam bidang loop, mengasah mereka untuk otomatisme dalam 15 tahun. Pemrograman itu sendiri seperti bernafas kepada saya. Ketika solusinya sudah jelas, saya hanya bisa mencetak kode non-stop, seperti teks di blog atau email. Saya dapat menyandikan solusi lebih cepat daripada yang lain, dan biasanya mengambil proyek yang lebih kompleks.

Untuk waktu yang lama, saya pikir itu adalah inti dari pengembang utama.

Apakah semuanya tampak cocok? Bagaimanapun, posisi itu disebut "pengembang utama", dan bukan "komunikator memimpin" atau "manajer proyek utama". Saya benar-benar tidak mengerti berapa banyak keterampilan yang perlu dikembangkan untuk menjadi "pemimpin" yang benar-benar.

Apa yang akhirnya saya mengerti

Insinyur senior harus menguasai banyak keterampilan selain pemrograman . Dibandingkan dengan awal karir, saya harus mengembangkan sejumlah keterampilan astronomi. Komunikasi, manajemen ketergantungan, berbagi konteks, manajemen proyek, mengevaluasi waktu proyek, dan berkolaborasi dengan kolega yang bukan pengembang. Keterampilan ini sulit untuk diukur dan membutuhkan banyak percobaan dan kesalahan sebelum dipelajari dengan benar.

Tidak setiap programmer akan menjadi "senior" . Ini adalah hasil akumulasi pengalaman bertahun-tahun. Namun demikian, pengalaman bertahun-tahun adalah kondisi yang diperlukan tetapi tidak cukup untuk tuan. Itu juga harus menjadi pengalaman yang tepat di mana Anda telah mempelajari pelajaran yang tepat dan berhasil menerapkan pengetahuan ini di masa depan. Kadang-kadang pelajaran penting akan muncul dalam satu tahun atau lebih - itulah sebabnya pengalaman bertahun-tahun masih penting, bahkan jika Anda seorang programmer yang sangat baik.

Di beberapa daerah kami masih junior . Tidak peduli berapa banyak pengalaman yang Anda miliki, selalu ada tempat di mana Anda memiliki sedikit pengetahuan. Mengenali ketidakmampuan Anda dalam bidang tertentu adalah langkah pertama untuk mengisi celah ini dan mendapatkan bantuan dari rekan yang lebih berpengalaman.

Bonus : Saya benar-benar menyukai artikel "Menjadi Programer Terkemuka" . Hebat, jika pada titik apa Anda bertanya-tanya apa artinya karya ini.