Cara bertanya seputar Programming

ini error kenapa ya gan

Sebelumnya pernah menulis tentang ini di Medium, tapi karena akunku sudah di delete, jadi akan aku tulis ulang lagi disini dengan isi yang lebih segar.

Dunia programming adalah dunia yang lumayan unik. Lihat, banyak orang yang memiliki ketertarikan yang sama lalu berkumpul pada suatu tempat membicarakan & mendukung tentang apa yang mereka tertarikkan tersebut.

Yang biasa disebut dengan komunitas.

Komunitas terkait dunia programming ini relatif ramah baik kepada anggota lama maupun anggota baru. Sayangnya, mungkin belum semua familiar dengan komunitas programming ini  (atau lebih spesifiknya komunitas secara dasar ataupun online).

Dan juga, terkadang tidak semua komunitas belum memiliki "aturan", "panduan", "kode etik" dan lain sebagainya yang berlaku pada komunitas tersebut. Sehingga anggota mungkin merasa bingung lalu melakukan apa yang mereka 'ketahui' layak untuk dilakukan terlepas mengikuti aturan atau tidak.

Disini, kita akan fokus membahas tentang judul dari tulisan ini. Ya, adanya komunitas salah satu fungsinya adalah untuk saling membantu anggota—orang yang memiliki ketertarikan yang sama—satu sama lain. Tapi, agar kita bisa menjadi pribadi yang lebih baik dan lebih mandiri, mungkin "saran-saran" yang ada disini bisa membantu kamu untuk mencapai itu.

So, here we go.

Baca pesan error

Biasanya, kita memberikan pertanyaan seputar error yang kita alami. Dan biasanya, di pesan error tersebut sudah jelas apa yang salah dan apa yang harus diperbaiki.

ini contoh

Lihat error diatas, bukankah sudah jelas apa kesalahannya dan apa yang harus dilakukan, bukan? Membaca pesan error bukanlah hal yang sulit, karena biasanya ditulis menggunakan bahasa inggris bukan sunda.

Dan juga, biasanya di "program asli" tidak hanya menampilkan pesan error saja, melainkan beserta dengan bagian mana yang menyebabkan error berikut dengan baris, kolom, dan skop nya.

udah jelas belum errornya apa?

Biasakan dirimu untuk bisa membaca pesan error, melakukan debugging sederhana dengan membaca "stack trace" yang ada sehingga "komunitas" tidak dibanjiri dengan pertanyaan-pertanyaan mungkin sederhana karena jawabannya sudah ada di pesan tersebut.

Googling pesan error

Kalau kamu masih bingung dengan pesan error yang ada, sebelum bertanya, biasakan untuk googling terlebih dahulu pesan error tersebut. Kamu tidak sendirian, mungkin ada jutaan orang lebih diluar sana yang memiliki error yang sama dan sudah pernah di solve. Jika belum ada, mungkin kamu termasuk orang yang kurang beruntung.

Misal seperti error ini:

contoh aja

Kamu gak ada ide apa maksud dari error tersebut, entah karena kurang mengerti atau karena ada istilah yang baru diketahui (circular???). Tapi ada klu nya disitu, "TypeError: Converting circular structure  to JSON". Let's see.

ini googling

Ini buat contoh aja, misalnya untuk kasus ingin melakukan debugging™ via console.log pada suatu object yang mungkin kita tidak tau kalau object tersebut berjenis circular tapi kita ingin tau isi dari object tersebut. Dan sepertinya, link paling atas sepertinya menarik untuk dikunjungi?

Lalu kita mengambil salah satu jawaban dari link tersebut.

sesuai ekspektasi

Lihat, sekarang kita bisa menampilkan nilai dari object tersebut dengan sukses dan tanpa bertanya! Ajaib, bukan?

Baca dokumentasi

Mungkin kita sudah membaca pesan error, lalu googling pesan tersebut. Namun sayangnya masih tidak membantu. Mungkin kita bisa saja menyerah lalu coba bertanya langsung ke komunitas (siapa tau ada yang pernah memiliki masalah serupa) tapi ada satu hal yang paling mendasar yang belum dilakukan: Membaca dokumentasi.

Dokumentasi adalah pedoman, jika kamu percaya dengan konsep agama, dokumentasi adalah seperti kitab suci yang menjadi pedoman dalam hidupmu sebagai pemeluk agama tertentu. Agar terarah & tidak tersesat.

contoh

Anggap kode diatas berjalan di mesin yang berbeda. Di mesin kita kode tersebut berhasil berjalan sedangkan dimesin yang satu tidak. Pesan error nya mungkin kurang jelas, dan googling pun tidak membantu.

Tapi kita tau itu adalah sintaks Spread, yang tidak kita ketahui adalah mengapa di mesin A bisa tapi di mesin B tidak. Lalu berdasarkan dokumentasi semi-resmi yakni MDN Web Docs, bagian yang menarik adalah ini:

kompatibilitas

Kita menggunakan node v8.1.0 sedangkan sintaks tersebut hanya mendukung versi node >= 8.3.0. Lalu kita install mesin yang satu lagi dengan versi yang sudah didukung.

berhasil

Wow sekarang kode kita bisa berjalan tanpa error berbekal dari membaca dokumentasi di bagian kompatibilitas! Ajaib, ya?

Cara bertanya

Anggap 3 kasus diatas tidak membantu, dan cara terakhir adalah bertanya ke komunitas. And it's okay!

Bagian ini adalah tentang cara bertanya yang baik dan belum tentu benar, setidaknya baik lebih baik daripada tidak baik, oke?

To the point

It's okay kalau kamu ingin to the point, tapi harus yang jelas. Misal, kalau lo pengen tau jawaban dari pertanyaan "mas/mbak ke dago caranya gimana yaa" ya orang pun (semoga gue aja) sebenernya males jawabnya.

Mungkin lo terburu-buru, atau bingung, atau emang gak bisa basa-basi, tapi caranya gak gitu, bos. Cobain jabarin to the point yang baik, seperti "mas/mbak cara ke dago dari buah batu gimana ya", setidaknya walau orang gak tau buah batu yang lo maksud itu dimana, setidaknya ada gambaran jelas.

Misal seperti ini, "mas/mbak ini ada error di webpack, errornya kenapa ya". Ya errornya dimana? Pas mulai? Pas sedang berjalan? Pas build? Atau gimana? Dengan menambahkan 7 kata "pas mulai bisa tapi build gak bisa" setelah kata error diatas membantu orang lain untuk mengetahui masalah yang kamu alami.

Ya, meskipun pastinya harus ada penjabaran yang lebih lanjutnya, setidaknya masalah yang lo alami sudah terbayang sedikit.

Skrinsut

Menyalin pesan error tentu tidak masalah, tapi kalau pesannya terlalu panjang jadinya malah menganggu. Skrinsut pun ada caranya, tidak sebatas mengirim gambar dari layar kamu, seperti ini misalnya:

contoh skrinsut yg salah

Oke kalau contoh diatas mungkin sedikit jelas, kalau tidak jelas? Atau misalnya skrinsut seperti ini:

ini yang paling gue kesel

Mungkin karena alesan "rahasia", "NDA", atau apapun itu. Gue paling benci sama yang ngirim skrinsut pelit kayak diatas, kalau memang terkait rahasia ya setidaknya effort dikitlah disensor "bagian" rahasianya.

effort

Diatas cara yang sedikit benar, tapi harusnya pengen itu rahasia atau enggak, orang juga gak peduli tentang project lu, bos. Pengen itu project multi-billion dollar ideas sekalipun, misal dengan nama direktori tanian alias i have no idea and don't give a fuck with the fuck u are doing.

Elaborasi (PoC)

PoC atau Proof of Concept adalah tentang melakukan elaborasi, tentang menjabarkan langkah-langkah mengapa kasus tersebut terjadi. Gak perlu ribet-ribet bikin pakai format Post-mortem misalnya. Cukup kasih tau sedikit mengapa & kapan kasus tersebut terjadi, itu lumayan membantu.

Misal begini:

Halo gan/sist, ini saya ada masalah di Next.js.

Sebelumnya aman tidak error, tapi kok pas saya tambah
dependensi `react-helicopter`di windows malah jadi error ya?

Padahal di ubuntu bisa

Nah kondisi diatas kan lumayan jelas, apa yang dipakai; kapan error tersebut muncul, sistem operasi apa yang digunakan, dll. Kita bisa berasumsi seperti mungkin masalahnya ada di cross-platform, atau LF/CRLF problem, dsb.

Ingat, yang butuh itu kita sebagai penanya, jadi, jadilah penanya yang baik, oke?

Snippet/sandbox/playground

Ini yang lebih asik, lo bener-bener niat untuk bertanya dan untuk dijawab. Yakni dengan cara membagikan kode lengkap/semi-lengkapnya, sehingga kita bisa lebih mudah menebak-nebak kenapa masalah tersebut muncul.

Tapi kita programmer bukan dukun, kita mungkin have no idea terhadap kode yang kamu tulis, dan kalo kita niat mungkin kita akan coba menjalankannya di mesin kita.

Nah, agar sama-sama enak, coba membuat sandbox/playground yang bisa dijalankan. Mungkin bisa menggunakan CodeSandbox, Repl.it, atau tunneling dari mesin lokalmu. Yang intinya, media yang bisa dijalankan yang mencerminkan kode & masalah yang kamu miliki tersebut.

Push sumber kode ke layanan seperti GitHub pun membantu kok, asal bukan cuma pertanyaan yang sangat to the point apalagi skrinsut ngeselin yang cuma setengah-setengah.

Keep calm

Jangan perlu memusingkan apalagi meribetkan tentang ini. Ini cuma "panduan" sederhana yang baik & belum tentu benar khusus tentang bertanya seputar programming. Kita bukan sedang memberikan quiz, ataupun bermain tebak-tebakan, jadi, jelaskanlah sejelas-jelasnya, ya.

Be nice

Perlu diingat, yang memiliki kebutuhan adalah kita (penanya), singkatnya, jadilah seseorang yang menyenangkan jika berharap ingin diperlakukan menyenangkan.

Jangan ragu, malu, minder, apalagi takut terhadap masalah yang kamu miliki. Komunitas ada salah satunya untuk saling membantu terhadap sesuatu yang sama-sama disenangi tersebut.

Layak diingat, komunitas adalah tempat berkumpul orang-orang yang memiliki ketertarikan sama, bukan kumpulan orang-orang yang memberikan support™ dan konsultasi gratis. Yang maksudnya, be nice. Jika kamu ingin mendapatkan 24/7 support, mungkin yang kamu butuhkan adalah konsultan bukan komunitas?

Penutup

Bukan bermaksud untuk mencoba "membuat sepi" komunitas yang ada, tapi cuma sebatas "saran" sebagai seorang teman yang mungkin peduli dengan kamu & kemajuan kamu. Gue membayangkan bagaimana bila komunitas dipenuhi dengan jawaban daripada pertanyaan & lebih banyak tentang berbagi apa yang dipelajari, yang menurut gue lebih menarik dari—no offense—menjadi kumpulan free support services.

Mengapa gue cuma membahas tentang error? Karena kebanyakan (setau gue) yang gue liat cuma sebatas itu. Masalah-masalah lain yg mungkin lebih next level jarang gue temuin, kalau nemu pun dari LGLG.

Semoga tulisan ini bermanfaat, agar lebih mudah diakses, halaman ini ada bisa dikunjungi di https://evlfctry.pro/bertanya.

Terima kasih!