Mengapa Pengodean Kolaboratif Adalah Peretasan Karir Utama

Mengambil langkah pertama Anda dalam pemrograman seperti mengambil bahasa asing. Pada awalnya, sintaksnya tidak masuk akal, kosakatanya tidak dikenal, dan semuanya terlihat dan terdengar tidak dapat dipahami. Jika Anda seperti saya ketika saya mulai, kelancaran terasa mustahil.

Saya berjanji tidak. Ketika saya mulai coding, kurva pembelajaran memukul saya — keras. Saya menghabiskan sepuluh bulan untuk mengajari diri saya sendiri dasar-dasarnya sambil mencoba mencegah perasaan ragu-ragu yang sekarang saya kenal sebagai sindrom penipu. Baru setelah saya mulai pergi ke pertemuan ramah pemula, saya menyadari bagaimana pengkodean secara kolaboratif membuka kemungkinan yang luar biasa. Anda hanya perlu komunitas orang yang tepat untuk berlatih.

Bagi saya, komunitas itu adalah Founders and Coders, bootcamp JavaScript gratis yang membantu saya mengubah karir saya dari copywriting ke coding. Bahkan sekarang, kurang dari setahun setelah menyelesaikan kursus, saya hampir tidak percaya bahwa saya dibayar untuk mengembangkan perangkat lunak.

Pengkodean kolaboratif adalah tentang mengatasi masalah dan menemukan solusi bersama. Ini mencakup teknik seperti pemrograman berpasangan, yang oleh beberapa perusahaan teknologi dianggap cukup serius untuk disaring selama proses wawancara mereka. Ini juga memupuk keterampilan berguna yang sulit dipelajari jika semua yang Anda lakukan hanyalah coding sendirian di rumah.

Baik Anda baru memulai di industri teknologi atau memiliki pengalaman beberapa tahun, pengkodean kolaboratif tidak pernah berhenti berguna. Pada artikel ini, kita akan melihat bagaimana keterampilan evergreen ini membekali Anda untuk karir yang panjang dan sukses dalam pengembangan perangkat lunak.

Pasangan Sempurna

Pengalaman pertama saya tentang pemrograman berpasangan adalah pada pertemuan untuk pemula yang disebut Coding For Everyone. Begini cara kerjanya: orang berpasangan, sering kali dengan orang yang belum pernah mereka temui, untuk menyelesaikan tantangan JavaScript bersama di laptop yang sama. Satu orang berperan sebagai 'navigator' dan mengusulkan kode yang menurut mereka harus ditulis. Orang lain, 'pengemudi', mengetik saran mereka di laptop dan mengajukan pertanyaan setiap kali ada sesuatu yang tidak jelas. Anda terus melakukan ini, sering bertukar peran, sampai akhir sesi dua jam.

Secara teori, itu sederhana. Dalam praktiknya, tidak begitu banyak.

Saya merasa cukup mengganggu untuk memiliki seseorang yang tidak saya kenal menonton layar saya saat saya mengetik, dan saya enggan untuk menyerahkan kendali ketika tiba waktunya untuk bertukar peran. Saya menemukan navigasi bahkan lebih rumit. Ketika sebuah ide tidak dapat keluar dari kepala Anda ke komputer tanpa terlebih dahulu melalui tangan pasangan Anda, setiap kata yang Anda ucapkan penting. Itu menuntut tingkat komunikasi dari kami berdua yang kami tidak terbiasa, dan saya yakin kami berdua akan belajar lebih banyak jika kami berpisah untuk bekerja secara terpisah.

Untungnya, kami terjebak dengan itu; Saya pergi lagi ke pertemuan minggu berikutnya. Sejak itu saya telah menghabiskan ratusan jam berpasangan dengan lusinan pengembang, dan saya telah belajar lebih banyak daripada yang saya kira mungkin.

Pemrograman berpasangan adalah cara yang sangat cepat untuk belajar. Keajaiban dari metode ini — setelah Anda mengatasi kecanggungan awal — adalah bahwa metode ini memberikan hasil langsung. Beberapa putaran umpan balik, seperti gelembung di pasar saham, bisa memakan waktu berjam-jam, berhari-hari, atau bahkan berbulan-bulan untuk menghasilkan koreksi. Pemrograman pasangan membutuhkan waktu beberapa menit, jika bukan detik. Saat Anda salah menempatkan titik koma, dua pasang mata dapat melihat kesalahan lebih cepat dari satu. Perlu mencari petunjuk di StackOverflow tentang pesan kesalahan nakal? Anda dan pasangan masing-masing dapat membaca utas yang berbeda, mengurangi separuh waktu yang diperlukan untuk menemukan jawaban.

Untuk masalah yang lebih rumit, pemrograman mob bisa menjadi langkah lebih lanjut. Metode ini membutuhkan bagian lintas fungsi dari tim untuk berkumpul di sekitar layar komputer yang sama dan bertukar pikiran solusi secara realtime sementara satu orang mengetik.

"Semua pikiran brilian bekerja pada hal yang sama, pada saat yang sama, di ruang yang sama, di komputer yang sama."

— Woody Zuill, Pelatih Agile dan Pelatih Pemrograman Massa

Meskipun mungkin tampak seperti cara yang tidak efisien untuk bekerja, pendukung pemrograman massa seperti Woody Zuill mengatakan itu benar-benar dapat menghemat waktu dengan menghilangkan kebutuhan untuk tinjauan kode individu karena semua orang meninjau kode secara realtime saat sedang ditulis. Selain produktivitas, saya pikir mobbing adalah cara yang fantastis untuk belajar tidak hanya tentang kode, tetapi tentang bagaimana orang lain mendekati masalah. Jika pemrograman berpasangan menggandakan jumlah perspektif yang Anda hadapi, pemrograman massal menghasilkan lebih banyak wawasan.

Itu tidak berarti bahwa memasangkan — atau memang mengeroyok — adalah hal yang mudah. Sesuatu yang awalnya saya perjuangkan adalah mengesampingkan ego saya untuk mengajukan pertanyaan yang menurut saya mungkin terdengar bodoh. Dalam situasi ini, ada baiknya untuk mengingat bahwa pasangan Anda mungkin memiliki pemikiran yang sama, terutama jika Anda berdua baru memulai.

Jika Anda menemukan diri Anda berpasangan dengan seseorang yang lebih senior, mungkin di tempat kerja, jangan takut untuk memilah otak mereka dan membuat mereka terkesan dengan rasa ingin tahu Anda. Bahkan seseorang yang hanya sedikit lebih maju dari Anda mungkin memikirkan hal-hal yang tidak akan terpikirkan oleh seseorang yang lebih senior. Beberapa pemrogram pasangan favorit saya hanya memiliki pengalaman beberapa bulan lebih banyak daripada saya, namun mereka sepertinya selalu tahu persis kesalahan mana yang akan saya buat dan bagaimana mengarahkan saya ke arah yang benar. Ketika pengembang ini mengatakan tidak ada yang namanya pertanyaan konyol, mereka sungguh-sungguh. Pasangan programmer terbaik berbicara dengan bebas, tanpa perlu terlihat fantastis atau takut terlihat bodoh.

Pemrograman berpasangan membutuhkan latihan, tetapi perlu disempurnakan. Studi menunjukkan bahwa programmer yang berpasangan untuk memecahkan masalah cenderung lebih percaya diri, produktif, dan terlibat dengan pekerjaan mereka. Apakah Anda sedang mencari pekerjaan Anda berikutnya atau Anda sedang merekrut karyawan baru, berpasangan itu peduli.

Sumber Daya Dan Bacaan Lebih Lanjut

• “Peran Pemrograman Pasangkan,” Jordan Poulton, GitHub
• “Persahabatan yang Membuat Google Besar,” James Somers, The New Yorker
• “Pemrograman Massa: Pendekatan Seluruh Tim,” Woody Zuill, YouTube

Empati Rekayasa

Ketika saya mulai belajar JavaScript sendiri, kode saya sangat mirip dengan lantai kamar tidur saya: Saya akan membiarkannya semakin berantakan sampai saya tidak punya pilihan selain merapikannya. Selama browser web saya dapat memahaminya, saya tidak peduli bagaimana tampilannya.

Baru setelah saya mulai meninjau kode orang lain, saya menyadari bahwa saya perlu menunjukkan lebih banyak empati kepada orang-orang yang mengulas kode saya.

Empati mungkin merupakan alat yang paling diremehkan di gudang pengembang mana pun. Itulah alasan mengapa IDEO menempatkan riset pengguna di pusat proses desain mereka, dan mengapa Etsy meminta desainer dan manajer produk mereka untuk melakukan rotasi teknik. Empati muncul ketika kita memiliki kesempatan untuk melihat bagaimana pekerjaan kita berdampak pada orang lain. Tidak heran pengkodean kolaboratif adalah cara yang bagus untuk membangunnya.

Tinjauan kode sejawat — tindakan memeriksa kode satu sama lain untuk kesalahan — meminta kita untuk melatih empati. Sebagai peninjau, penting untuk mengetahui bahwa seseorang telah berusaha keras untuk menulis kode yang akan Anda kritik. Karena itu, cobalah untuk menghindari penggunaan frasa yang mungkin menyiratkan penilaian atau meremehkan pekerjaan mereka. Saat Anda merujuk ke kode mereka, Anda ingin menunjukkan kepada mereka fungsi dan baris spesifik yang Anda ingin tanyakan, dan menyarankan bagaimana mereka bisa memperbaikinya. Berbagi sumber belajar juga bisa lebih membantu daripada memberi solusi. Beberapa umpan balik paling berguna yang saya terima dari ulasan kode datang dalam bentuk artikel pendidikan, video, dan bahkan rekomendasi podcast.

Menulis dokumentasi yang baik untuk kode Anda juga sangat membantu. Tindakan sederhana seperti membuat readme dengan petunjuk pemasangan yang jelas menunjukkan empati bagi siapa saja yang perlu bekerja dengan kode Anda. Pendiri GitHub Tom Preston-Werner menganjurkan pendekatan readme-first untuk pengembangan.

“Implementasi sempurna dari spesifikasi yang salah tidak ada gunanya. Dengan prinsip yang sama, perpustakaan yang dibuat dengan indah tanpa dokumentasi juga hampir tidak berharga. Jika perangkat lunak Anda memecahkan masalah yang salah atau tidak ada yang tahu cara menggunakannya, ada sesuatu yang sangat buruk terjadi.”

— Tom Preston-Werner, Pendiri GitHub

Saya juga telah berbicara dengan pendiri teknologi yang memperlakukan dokumentasi sebagai bagian penting dari keberhasilan orientasi. Seorang CTO mengatakan bahwa jika seorang pengembang junior berjuang untuk mencapai tingkat produktivitas dalam waktu enam bulan setelah bergabung dengan timnya, hal itu menunjukkan bahwa basis kode tidak cukup terdokumentasi dengan baik. Hanya perlu beberapa detik untuk menambahkan komentar penjelasan ke fungsi kompleks yang telah Anda tulis, tetapi itu bisa menyelamatkan orang berikutnya yang bergabung dengan tim Anda berjam-jam.

Sumber Daya Dan Bacaan Lebih Lanjut

• “Pada Permintaan Empati & Tarik,” Slack Engineering, Medium
• “Pengembangan Berbasis Readme,” Tom Preston-Werner, GitHub
• “Apa yang Dipelajari Google dari Pencariannya untuk Membangun Tim yang Sempurna,” Charles Duhigg, The New York Times Magazine

Prestasi tangkas

Dari jutaan jam kerja yang dihabiskan untuk membuat film CGI hingga pengembangan intens yang mengarah ke rilis video game beranggaran besar, pencapaian teknis yang menjulang membutuhkan upaya yang luar biasa. Pertama kali saya melihat basis kode majikan saya saat ini, saya terpesona oleh besarnya semua itu. Bagaimana orang bisa membangun ini?

Jawabannya adalah bahwa setiap orang dapat membangun lebih dari siapa pun , dengan kerangka kerja kolaboratif yang tepat. Di perusahaan yang mendorong pengkodean kolaboratif, perangkat lunak tidak muncul dari upaya seorang jenius tunggal. Sebaliknya, ada cara bekerja sama yang membantu tim hebat untuk melakukan pekerjaan yang luar biasa. Pengembang di Founders and Coders mempraktikkan metodologi pengembangan perangkat lunak populer yang dikenal sebagai 'Agile', dan menurut pengalaman saya, ini menempatkan 'fungsional' dalam tim pengembangan lintas fungsi.

Seluruh buku telah ditulis tentang Agile, tetapi berikut adalah ringkasan dari konsep inti:

• Tim pengembangan produk memecah pekerjaan besar menjadi unit-unit kecil yang disebut 'cerita pengguna', memprioritaskannya, dan mengirimkannya dalam siklus dua minggu yang disebut 'sprint'.
• Selama proyek berlanjut, siklus berulang, dan persyaratan produk baru dimasukkan ke dalam tumpukan tugas untuk sprint mendatang.
• Tim mengadakan pertemuan standup setiap hari untuk membahas kemajuan mereka dan mengatasi pemblokiran apa pun.
• Prosesnya bersifat inkremental dan berulang: perangkat lunak dibangun dan dikirimkan berkeping-keping dan disempurnakan dalam sprint yang berurutan.

Sebagai seorang pengotak-atik kronis yang proyek hobi solonya sering menyerah pada 'feature creep', saya tahu betapa mudahnya membuang waktu untuk membangun hal-hal yang tidak pernah digunakan siapa pun. Saya suka cara Agile memaksa Anda untuk memprioritaskan cerita pengguna sehingga seluruh tim dapat fokus dalam memberikan fitur yang benar-benar penting bagi pengguna Anda. Ini memotivasi untuk mengetahui bahwa Anda semua bersatu di sekitar tujuan bersama untuk membangun produk atau layanan yang akan terus memiliki kehidupan setelah Anda selesai mengerjakannya.

Memisahkan tugas menjadi cerita pengguna kecil juga merupakan cara yang bagus untuk sesi pemrograman pasangan kotak waktu. Tidak peduli seberapa dalam zona yang Anda temukan, menyelesaikan pekerjaan pada fitur utama selalu merupakan pengingat yang bagus untuk menjauh dari meja Anda dan beristirahat. Agile meminjamkan struktur untuk pengkodean kolaboratif di mana sebaliknya bisa kurang.

Sementara itu, standup harian memberi Anda kebebasan untuk membicarakan apa pun yang menghambat Anda, dan sprint retrospectives memberikan ruang untuk berbagi kemenangan utama dan menunjukkan dengan tepat di mana tim dapat berkembang. Upacara-upacara ini menumbuhkan rasa kolaborasi dan akuntabilitas, dan membantu kami untuk belajar lebih banyak bersama daripada yang bisa kami lakukan sendiri.

Menerapkan semua prinsip Agile ini ke dalam praktik dapat menjadi tantangan, terutama ketika tidak ada seorang pun dalam tim yang terbiasa dengan cara kerja ini. Di Founders and Coders, sebagian besar siswa membutuhkan waktu untuk membiasakan diri melakukan standup setiap hari. Namun, setelah 18 minggu praktik berbasis proyek, Anda menemukan bahwa proses dan keterampilan komunikasi Anda meningkat pesat. Pada saat Anda melakukan pekerjaan klien pertama Anda, Anda telah membentuk model mental yang jauh lebih jelas tentang cara membangun aplikasi web full-stack dalam sebuah tim.

Cara terbaik untuk belajar Agile adalah dengan membangun proyek yang menarik dengan orang lain. Menghadiri hackathon adalah cara terbaik untuk terhubung dengan calon kolaborator. Banyak proyek sumber terbuka membuat papan proyek kanban mereka menjadi publik, sehingga Anda dapat melihat masalah GitHub mana yang sedang dikerjakan oleh kontributor berbeda. Beberapa kontribusi sambutan dari pemula, dan Anda sering dapat menugaskan diri Anda untuk membuka masalah dan mulai mengajukan permintaan tarik.

Karena sebagian besar perusahaan teknologi berlangganan beberapa bentuk Agile, tidak jarang pengusaha menanyakannya dalam wawancara. Pengalaman apa pun yang Anda miliki dapat membedakan Anda dari pelamar lain yang mungkin tidak pernah membuat kode secara kolaboratif, apalagi dengan mempertimbangkan Agile.

Sumber Daya Dan Bacaan Lebih Lanjut

• “Apa itu Agile?,” Steve Denning, Forbes
• “Merangkul Agile,” Darrell K. Rigby, Jeff Sutherland, Hirotaka Takeuchi, Harvard Business Review
• “Peluang Permintaan Tarik Pertama yang Luar Biasa,” Shmavon Gazanchyan, Deloitte Digital

Rekomendasi Alat Pengodean Kolaboratif Jarak Jauh

Dalam beberapa tahun terakhir, alat kerja jarak jauh telah maju ke titik di mana perusahaan terkemuka seperti Gatsby dan Zapier sekarang menjadi "yang pertama dari jarak jauh". Meskipun masih harus dilihat apakah ini akan berubah menjadi tren, aman untuk mengatakan bahwa tim pengembangan jarak jauh akan tetap ada.

Dalam semangat itu, berikut adalah beberapa alat yang dapat membantu Anda dan tim Anda membuat kode secara kolaboratif dari jauh:

Jika Anda mengambil satu hal dari membaca artikel ini, saya ingin pemain tim mengalahkan kontributor individu. Di bidang di mana tampaknya ada kerangka kerja baru yang panas untuk dikuasai setiap minggu, keterampilan teknis kami menua dengan cara yang tidak dimiliki oleh keterampilan lunak kami. Hasilnya adalah bahwa pengembang yang dapat bekerja dengan baik dengan orang lain akan selalu menemukan bahwa kemampuan mereka dibutuhkan. Pengkodean kolaboratif bukan hanya cara yang efektif untuk belajar; itu adalah keahlian yang dicari yang dapat dikembangkan siapa pun dengan latihan dan kesabaran yang cukup.