Manual itu nyawa software

Urutan bertanya ke orang lain

1tweetretweet

1

setiap hari kita dituntut untuk survival didunia ini untuk menunjukan manfaat kita bagi orang lain, setelah membaca artikel tentang RTFM mas endy, misalnya saya. saya sebagai seorang programmer pasti menemui masalah setiap harinya waktu koding program, lalu pikiran kita pertama kali pasti “tanya ke orang lain”. mungkin sulit untuk memulai sesuatu hal khususnya untuk seseorang ataupun saya. tapi saat anda tanya ke orang lain dalam kondisi blank/belum mencari tahu atau mencoba “try and error” ke orang lain sadarkah anda sedang menyiksa orang lain karena mempelajari sistem orang lain itu membutuhkan waktu dan berpikir lebih apalagi ditambah cara koding yang terkadang amburadul, dengan menyuruh orang lain untuk mempelajari program yang kadang anda sendiripun tidak tahu bahkan disuruh untuk menggambarkan alurnya saja anda masih bingung. bukan maksud seseorang untuk menolak menjawab pertanyaan anda tapi sudahkan anda bertanya ke anda apa yang sudah anda coba lakukan sebelum bertanya/menyuruh orang lain untuk mempelajari program anda. bukan maksud untuk tidak mau menjawab !!!! lanjut next paragraph

RTFM bisa diartikan sebagai Read The Fine Manual atau Read The Fucki*ng Manual, itulah salah satu hal yang malas bukan bodoh dilakukan oleh orang. mungkin maunya langsung bisa tanpa waktu lama. menyingkat tapi memperlama sama saat anda melihat film india tree idiots, disana ada 2 orang yang belajar dengan cara yang berbeda. (cara pertama_)ada yang menggunakan menghapal tanpa pemahaman dan satunya menggunakan pemahaman tanpa hapalan(cara kedua). dan untuk cara yang pertama memang membutuhkan waktu yang singkat tapi anda takkan pernah tau arti yang sebenarnya selain menghapal dan cara yang ke dua anda akan paham tentang arti dan dapat memanipulasi pemahaman dengan fungsi yang anda harapakan.

kalimat yang saya sering terima adalah “error xxxxxxx, gimana caranya ……… ???? “,, masak harus debugging sana sini Xjhfsddflkgdfgndgbdkfjgndkfgndkgnd :X.  karena banyak sekali sekarang ini review source code yang bisa kita gunakan, pelajari dan jangan lupa baca manual karena manual itu nyawa software tanpa manual pasti kereportan.

Berikut urutan pertanyaan saya:

1. Sudah download?
2. Sudah extract?
3. Sudah baca dokumentasinya?
4. Sudah coba jalankan contohnya?
5. Sudah lihat dokumentasi/FAQ/forum di websitenya?
6. Sudah cari di Google?

Misal, ada yang tanya, “Bagaimana cara membuat mapping one-to-many di Hibernate?” Maka respon saya adalah:

1. Sudah download Hibernate?
2. Sudah extract hibernate-xx.zip?
3. Sudah baca dokumentasinya?
4. Sudah coba jalankan contohnya?
5. Sudah lihat dokumentasi/FAQ/forum di websitenya?
6. Sudah cari di Google dengan keyword “hibernate one to many mapping”?

Sayang sekali, sampai saat ini belum ada yang sampai nomer 6. Biasanya para penanya sudah “menyerah” di nomer 3. Pada beberapa kasus menyedihkan, nomer 1 saja dijawab “Belum”.

Untuk mereka yang menyerah di nomer 1, Anda hanya membuang waktu dan bandwidth saya yang berharga. Mereka ini adalah tipikal orang yang ingin gampang dan tidak memikirkan kepentingan orang lain. Sama saja dengan menganggap saya sebagai petugas 108 yang siap menjawab segala pertanyaan, karena memang dibayar untuk itu.

Bagi mereka yang menyerah di nomer 3, saya masih sedikit berempati. Mungkin penguasaan bahasa Inggrisnya kurang. Atau mungkin keder melihat dokumen berpuluh-puluh halaman, dalam bahasa Inggris pula. Walaupun mungkin juga ada yang bermentalitas cari gampang seperti nomer 1 di atas.

Tapi saran saya adalah, bacalah dokumentasi. Kalau bahasa Inggris yang kurang, kursus. Kalau ngeri melihat dokumen yang banyak, jangan dibaca semua. Gunakan Ctrl+F alias fasilitas find.

Jika Anda ingin serius dalam karir duniawi, investasi Bahasa Inggris sangat penting. Kemampuan membaca tulisan Inggris akan memungkinkan Anda maju secara mandiri. Kalau tidak, kemajuan Anda akan tergantung kepada orang-orang baik hati yang mau membantu Anda. Orang seperti ini tidak selalu ada. Mereka sangat mungkin memiliki kesibukan lain, sehingga kemajuan Anda akan menunggu ‘bala bantuan’ tersebut punya waktu luang untuk membantu Anda. Konsekuensinya jelas, Anda hanya akan jadi orang tertinggal.

Dalam proses membaca dan memahami dokumentasi, pengetahuan kita akan meningkat. Bukan saja kita mendapat jawaban atas masalah kita, tapi kita mendapatkan pengalaman memahami dokumentasi teknis. Ini adalah skill yang sangat bermanfaat, dan telah terbukti berguna pada waktu saya mengalami kesulitan.

Ada satu skill lagi yang sangat bermanfaat, yaitu skill problem solving. Anda mendapat masalah, kemudian melakukan langkah-langkah pemecahan. Kalau tidak berhasil, mungkin ada yang perlu diperbaiki di sistematika pemecahan masalahnya. Kemampuan problem solving sangat penting bagi karir Anda. Anda akan dianggap orang yang ‘bisa bekerja secara mandiri‘ atau ‘mampu bekerja dengan supervisi minimal‘. Sering lihat kan kriteria seperti ini di lowongan pekerjaan?

Problem solving skill bukan teknik instan. Ini harus dilatih terus menerus sepanjang hidup. Semakin banyak masalah yang kita hadapi dan kita coba pecahkan, kemampuan kita akan meningkat, berhasil itu cuma masalah waktu saja.

Bagi mereka yang sudah menjawab Ya sampai nomer 5, saya ucapkan selamat untuk Anda. Anda sudah membuktikan bahwa Anda telah mengerjakan PR Anda sebelum akhirnya memutuskan untuk meminta waktu saya. Dan kalau ternyata memang belum menyelesaikan masalah, saya tidak keberatan untuk membantu Anda.

Untuk kaum nomer 5, biasanya prosedur standar saya adalah menggunakan Google untuk mencari jawaban. Kemungkinan pertama, search langsung menghasilkan jawaban. Pada kasus ini, saya akan memberikan keyword google yang saya gunakan dan menunjukkan pada entri keberapa jawaban ditemukan. Harapan saya adalah, pada kesempatan berikutnya si penanya akan tahu metode dan teknik memilih keyword supaya hasil Google-nya akurat. Dengan demikian, si penanya akan bisa lebih mandiri.

Kemungkinan yang lain, saya harus bersusah payah mencari sebelum berhasil menemukan jawaban. Biasanya alirannya begini: Google -> Website -> dapat keyword lain -> Google lagi, dan seterusnya sampai ketemu. Kalau begini kejadiannya, saya akan menjelaskan proses berpikir saya dalam menelusuri internet kepada si penanya. Lagi-lagi tujuannya adalah supaya si penanya bisa mencoba sendiri di kemudian hari.

Buat mereka yang sudah lulus sampai nomer 6, tapi masih belum ketemu jawaban, lalu tanya saya … hmm … sejauh ini belum ada Kalau sudah lihai pakai Google dan gak ketemu, kecil sekali kemungkinan saya bakal ditanya. Kalaupun ditanya, jawaban saya cepat. Kalau saya sudah pernah mengalami masalah yang sama, saya akan jawab. Kalo belum pernah, ya saya bilang belum pernah, sehingga saya sama tidak tahunya dengan si penanya.

Pertanyaan yang saya benci adalah pertanyaan debug. Misalnya begini, “Saya bikin kode seperti ini , kemudian muncul NullPointerException, kenapa ya?”

Saya tidak suka karena:

1. Baca source code di Y! adalah penyiksaan, lewat SMS itu mungkin sudah melanggar HAM  . Jangan ketawa, ada yang pernah kirim source code via SMS ke saya.
2. Untuk bisa debug, paling efektif adalah dengan coding langsung, pasang println disana-sini, recompile, re-run, lihat hasilnya.

So, jangan ajukan pertanyaan debug ke saya. Coba kirim ke milis. Mudah-mudahan ada yang mau bantu. Kalo saya sih tidak … lihat source code yang ditulis sendiri aja pusing, apalagi source code orang, lewat SMS pula …

Kalau ada pertanyaan yang dibenci, tentunya ada pertanyaan yang disukai. Pertanyaan yang saya suka adalah yang konseptual. Misalnya, “Apa itu anonymous inner class, dan kapan kita menggunakannya”. Contoh lain, “Teknik mapping inheritance mana yang paling baik untuk kasus saya, one-table-for-all, table-per-subclass, atau table-per-class”?

Pertanyaan seperti ini mencerdaskan kedua belah pihak. Si penanya mendapat wawasan baru, sedangkan saya mendapat kesempatan untuk menguji apakah pemahaman saya sudah lengkap dan benar.

Jadi, mari bertanya secara cerdas demi kebaikan kita semua.

dikutip dan dikembang kan dari RTFM !!!