1. Tinggalkan ego di depan pintu
Pengembang memiliki ego yang membengkak. Itu adalah fakta. Tapi kenapa? Saya akan mengatakan bahwa siapa pun yang serius dengan profesinya menganggap diri mereka sebagai seseorang yang memiliki seni. Ya, kami tidak bernyanyi di depan jutaan orang dan tidak menggambar "Mona Lisa", tetapi terkadang kami menulis kode yang memecahkan masalah kompleks dengan sangat efisien dan elegan sehingga kami tidak bisa tidak bangga dengan pekerjaan kami. Saya pikir pengembang, dengan pendekatannya terhadap masalah, sama seperti seorang ahli seni seperti ahli matematika. Karena itu, kami cenderung merangkak di sekitar kode seperti induk beruang di sekitar keturunannya. Kami menulis, menyukainya, dan benci ketika orang-orang di sekitar berdebat tentang seberapa salah kode itu atau tidak.
Di sisi lain, itu belum membantu siapa pun. Kami mencintai pekerjaan kami, tetapi kami harus memahami bahwa kami sedang memecahkan masalah. Dalam mendiskusikan ide dan solusi kita dengan orang lain, alternatif yang lebih baik mungkin muncul. Tidak ada yang salah. Padahal, kolaborasi cenderung menghasilkan solusi yang lebih baik. Saya telah mengamati semua jenis ego, tetapi saya belum pernah melihat situasi di mana ego akan bekerja untuk pengembang.
Nasihat apa yang bisa saya berikan? Sejak Anda mulai bekerja sebagai pengembang, tinggalkan ego Anda di depan pintu. Telanlah dan dengarkan apa yang orang lain katakan tentang pekerjaan Anda. Terimalah bahwa ide terbaik mungkin tidak ada di kepala Anda dan dapat meningkatkan profesionalisme Anda. Anda hanya akan menang jika Anda mendengarkan umpan baliknya.
2. Bahasa adalah alat. Apakah Anda hanya tahu palu? Maka semua masalah seperti paku
Berhenti menyebut diri Anda pengembang Java atau pengembang JavaScript. Ya, ada bahasa yang Anda sukai karena sintaks atau kemampuannya. Ini sangat normal. Namun, Anda menang jika Anda meluangkan waktu untuk mempelajari hal lain. Mempelajari bahasa baru, terutama jika mereka mengikuti paradigma yang berbeda dari biasanya, dapat membantu membuka pikiran Anda terhadap pendekatan berbeda untuk pemecahan masalah.
Saya bahkan tidak tahu betapa pentingnya hal ini: mempelajari bahasa baru dan menerapkannya akan bermanfaat bagi keterampilan Anda. Saya membaca buku Tujuh Bahasa dalam Tujuh Minggu beberapa tahun yang lalu, dan buku itu membuka banyak pilihan bagi saya hanya karena buku itu menunjukkan cara-cara untuk memecahkan masalah yang tersedia dalam bahasa lain.
Kami adalah pengembang. Kami tahu bagaimana memecahkan masalah dengan kode. Jangan batasi diri Anda. Lihatlah melampaui batas, berpikirlah di luar kotak, pelajari opsi lain, bahasa, cara memecahkan masalah. Bahkan jika Anda tidak melakukannya dalam waktu lama, Anda akan kembali ke alat yang Anda kenal dengan ide-ide segar dan pemikiran yang lebih luas.
3. Ini bukan tentang menghafal algoritme, tetapi menemukannya
Beberapa pengembang pemula berpikir bahwa mereka perlu hafal algoritme, jadi mereka merasa tidak enak begitu menyadari bahwa mereka mulai lupa cara menulis perulangan for. Ini tidak hanya normal. Saya akan mengatakan bahwa itu bahkan berguna. Terlalu banyak yang harus kita ingat. Tapi ini juga tidak perlu. Kami perlu menerima kenyataan bahwa Internet hanyalah alat lain yang diperlukan sebagai IDE kami untuk menemukan jawaban.
Kita semua melakukan ini. Dan jika itu membuat Anda merasa buruk, jangan buang waktu untuk perasaan itu. Cukup telusuri Google untuk jawabannya dan pahami masalah Anda. Pikirkan tentang ini. Setiap bahasa memiliki cara yang serupa, tetapi sedikit berbeda dalam mengimplementasikan pola Observer. Apa yang lebih berguna? Memahami untuk apa pola itu bagus dan masalah apa yang dipecahkannya, atau mengingat bagaimana menerapkannya dalam setiap bahasa yang Anda gunakan?
Jika Anda tahu bahwa polanya akan menyelesaikan masalah Anda, berarti Anda sudah menyelesaikannya. Yang lainnya hanyalah mencari cara terbaik untuk menerapkannya di Google. Pencarian ini tidak menghilangkan rasa hormat untuk Anda, pekerjaan Anda, atau pengalaman Anda. Hal yang sama berlaku untuk pencarian lainnya. Fokus pada apa yang penting, pada penyelesaian masalah, dan biarkan Google mendorong ingatan Anda. Itulah mengapa itu ada.
4.
Atau lebih tepatnya, Anda harus belajar untuk seluruh karier Anda. Keputusan apakah Anda mengikuti perkembangan terbaru dalam industri ini terserah Anda. Tetapi yang terbaik adalah melakukan ini jika Anda ingin mencocokkan.
Bahasa dan teknologi berkembang, dan itu sangat normal. Tentu saja, beberapa ekosistem berubah lebih cepat daripada yang lain, dan mengikutinya mungkin tampak seperti tugas besar, tetapi fokuslah pada hal-hal penting, ingatlah bahwa Anda hanya manusia dan tidak dapat mengetahui segalanya. Oleh karena itu, jika Anda perlu mempelajari satu hal, saya sarankan belajar untuk belajar.
Saya tahu ini mungkin terdengar konyol, tetapi mungkin pengembang memiliki keterampilan nomor satu ini. Kita harus belajar mempelajari keterampilan baru dengan cepat. Jika tidak, Anda berisiko mendapatkan label "kedaluwarsa".
Di sinilah beberapa pelajaran lain dalam artikel ini berperan. Variabilitas, perubahan, tantangan baru, kurangnya ego - semua ini akan membantu Anda mempelajari dan memperluas jangkauan keterampilan Anda. Semakin banyak Anda mempraktikkannya, semakin baik. Akhirnya, Anda akan menyadari bahwa semua bahasa itu serupa. Anda akan mulai melihat akar yang sama dan dapat bekerja dengan salah satunya. Yang harus Anda lakukan adalah membaca beberapa hal penting. Sepanjang karir Anda, Anda akan belajar:
- Bahasa baru.
- Paradigma pemrograman baru (dan lama).
- Pendekatan baru untuk bekerja.
- Cara baru untuk memecahkan masalah.
- Cara baru untuk berinteraksi dengan rekan satu tim.
- Pendekatan baru untuk meninjau dan menguji kode Anda.
Jika Anda belum siap menjadi siswa kekal, pertimbangkan apakah karier seperti itu cocok untuk Anda. Perhatikan, saya tidak mengatakan, "Segera pergi," tetapi pertimbangkan apakah Anda siap untuk membuka pikiran Anda untuk terus belajar.
5. Bekerja lebih baik dari ideal
Sebagai seorang manajer, saya sudah terlalu sering mendengar ini. Tetapi sebagai pengembang, kami cenderung berpikir bahwa kode harus sempurna sebelum dirilis. Dan ini bukan hanya tidak benar, tetapi berpotensi menjadi masalah. Mengoptimalkan lebih awal merupakan masalah karena Anda akhirnya menghabiskan banyak waktu dan tenaga untuk hal-hal yang mungkin tidak memerlukan pengoptimalan. Dan dalam beberapa situasi, saat melakukan pengoptimalan ini, Anda membuat asumsi yang merusak fungsionalitas.
Jadi fokuslah pada pekerjaan yang harus diselesaikan dan masalah yang Anda coba selesaikan. Setelah memecahkan masalah, ujilah, ulangi hasilnya, dan lihat apa yang tim Anda pikirkan tentang solusi Anda, bahkan jika Anda sudah dapat melihat cara untuk memperbaikinya. Jika Anda akan menghabiskan dua hari lagi hanya untuk membuat kodenya sempurna, tetapi mungkin masuk ke produksi sekarang, kemungkinan itu harus dalam produksi sekarang.
Pada akhirnya, Anda memecahkan masalah tersebut. Semakin cepat Anda menyelesaikan masalah, semakin baik bagi pengguna Anda.
6. Buat kode berfungsi, lalu optimalkan
Menurut beberapa poin sebelumnya, jangan masuk ke lubang hitam pengoptimalan awal. Meskipun Anda merasa Anda akan menyelesaikan kode dengan cepat, setelah kode tersebut keluar (jika memang berhasil), Anda akan melihat bahwa efek dilatasi waktu itu nyata.
Prioritas pertama Anda sebagai pengembang perangkat lunak yang menulis fitur baru atau memperbaiki bug adalah membuatnya berfungsi, tidak peduli seberapa jelek tampilan kode atau seberapa tidak efisien solusinya. Jika kode berfungsi, Anda baru saja membuktikan bahwa kode dapat ditulis. Ini setengah dari pertarungan.
Langkah kedua adalah pengoptimalan. Langkah ini opsional. Detail yang cenderung dilupakan sebagian orang. Waktu yang Anda miliki untuk mengoptimalkan kode Anda bergantung pada banyak variabel yang terkadang tidak Anda kendalikan. Jadi fokuslah untuk membuat kode berfungsi dan kemudian cari tahu apakah Anda benar-benar punya waktu untuk mengoptimalkannya.
Mengoptimalkan lebih awal berarti mengoptimalkan kode Anda saat Anda menulisnya. Ini adalah praktik yang berbahaya karena saat mengoptimalkan, kami membuat asumsi tentang runtime, persyaratan data, persyaratan memori, dan faktor lain yang belum kami lihat beraksi. Asumsi seperti itu bisa salah, dan pada akhirnya Anda akan memasukkan kesalahan ke dalam logika Anda.
Pikirkan tentang alur kerja TDD:
- Tulis pengujian untuk memahami semua yang perlu dilakukan untuk fungsi Anda (pengujian akan gagal).
- Tulis kode Anda sehingga tes berhasil.
- Sekarang khawatir tentang mengoptimalkan kode Anda.
Langkah kedua diperlukan. Pertama, Anda perlu melakukan pengujian, yang berarti fungsinya berfungsi. Pengujian tidak peduli bahwa Anda menggunakan tiga pernyataan if bersarang dalam algoritme. Ini akan menjadi penting, mungkin pada tahap peninjauan kode.
7. 10% terakhir dari proyek membutuhkan 90% waktu
Ini sangat penting jika Anda bekerja sendiri, tetapi tim juga menderita karena tidak mendapatkan detail matematika kecil ini dengan benar. Siapapun yang telah menyelesaikan sebuah proyek akan mengatakan hal yang sama (dan terus terang, ini tidak hanya terjadi di industri kami). Pertama, Anda terburu-buru melalui banyak detail untuk dipikirkan nanti.
Dan ini sangat normal. Kami cenderung fokus terutama pada fitur besar, meninggalkan detail kecil atau bahkan bug yang diketahui sampai akhir. Namun demikian, Anda harus melawan mereka - dan di sini 90% tambahan muncul. Anda harus menguji, memperbaiki kode, menguji lagi, mengajari pengguna cara menangani solusi, mengirimkan versi final solusi, dan seterusnya. Tentu saja, semuanya tergantung pada konteksnya, siapa klien Anda, dan banyak faktor lainnya, tetapi selalu ada sesuatu. Jadi ingat, ketika Anda merasa hampir selesai dengan kodenya, Anda mungkin lupa sesuatu.
8. Saat Anda berada dalam sebuah tim, Anda membutuhkan abstraksi.
Pengkodean adalah tentang perilaku abstraksi. Dengan mengabstraksi logika umum, kita dapat menggunakannya kembali di tempat lain, tetapi pada awalnya kita melupakan pentingnya abstraksi. Inilah aturan pribadi saya: jika kode diulang di dua tempat, itu dikirim ke suatu fungsi (metode, modul); Anda mengerti. Jika dua pengulangan tampak seperti angka kecil di mata Anda, perlu diingat bahwa mungkin ada tempat lain di masa mendatang untuk menerapkan kode yang baru saja Anda abstraksi. Dan dengan segera mengabstraksi kode, Anda akan segera memiliki akses ke sana.
Abstraksi adalah penskalaan. Sepotong logika abstrak dapat digunakan berkali-kali dengan sedikit usaha, sementara salin-tempel (meskipun mudah dilakukan) - semakin Anda menggunakannya, semakin banyak usaha yang dibutuhkan. Pikirkan tentang apa yang terjadi jika, karena bug, Anda perlu mengubah sepotong logika yang diulangi 5 kali. Untuk memperbaiki bug, Anda benar-benar mengubah bagian kode yang sama 5 kali.
Logika yang sama berlaku untuk tugas sehari-hari. Jika Anda melakukan sesuatu lebih dari sekali, itu mungkin bisa otomatis. Ini adalah kunci efisiensi, jadi cari pengulangan tidak hanya dalam kode Anda, tetapi juga dalam tindakan Anda. Jika Anda mengotomatiskan tugas yang memakan waktu 10 menit sehari, Anda akan menghemat 5 jam dalam sebulan.
9. Proyek sampingan bersifat opsional, tetapi dapat membantu
Beberapa orang mengatakan bahwa jika Anda ingin menjadi pengembang yang sukses, Anda memerlukan proyek sampingan. Menurut saya ini tidak benar. Saya pribadi mengenal banyak pengembang hebat yang hanya menulis kode di tempat kerja, "dari 9 hingga 17". Sejujurnya, saya mengagumi mereka. Mereka ahli dalam bidangnya, dan di waktu luang, melakukan sesuatu yang lain, mereka menikmati hidup. Sama sekali tidak ada yang salah dengan itu. Namun, terkadang Anda membutuhkan latihan ekstra. Kadang-kadang Anda merasa tertinggal di belakang kolega Anda; di sini dan membantu proyek sampingan.
Saya tidak berbicara tentang revolusi dalam industri - mengembangkan kerangka kerja dengan jutaan pengguna. Tulislah jika Anda mau, tetapi saya sedang berbicara tentang menyalin proyek orang lain untuk belajar darinya. Saya juga berbicara tentang berkontribusi pada proyek orang lain, memperbaiki bug, dan menambahkan fungsionalitas.
Anda dapat menulis proyek sampingan untuk mengalami aspek pengembangan lainnya yang biasanya tidak Anda sentuh. Jika Anda menulis pengujian unit 8 jam sehari, Anda mungkin berpikir untuk menulis sesuatu dari awal atau mengembangkan beberapa fungsi. Jika Anda lelah bekerja sendiri, berkontribusi pada proyek orang lain yang ada dan rasakan apa artinya mengoordinasikan pekerjaan Anda dengan orang lain. Anda dapat menulis proyek sampingan untuk meningkatkan tingkat keterampilan Anda dengan mengatasi kelemahan. Tetapi sekali lagi, Anda tidak merasa perlu mengerjakannya dengan bilah aktivitas Github hijau untuk dianggap sebagai pengembang yang serius. Ini konyol.
Kesimpulan
Berikut adalah 9 pelajaran sulit saya sebagai pengembang selama 18 tahun terakhir. Mudah-mudahan, dengan berbagi pengalaman saya, saya telah menjelaskan masa depan atau karir Anda saat ini. Pernahkah Anda mempelajari hal lain yang ingin Anda bagikan? Saya ingin mendengar dari Anda di komentar, saya ingin belajar sesuatu dari Anda.
Profesi dan kursus lainnya