Living life and Make it Better

life, learn, contribute

Endy Muhardin

Software Developer berdomisili di Jabodetabek, berkutat di lingkungan open source, terutama Java dan Linux.

RTFM !!!

Disclaimer: Saya menulis artikel ini bukan karena sudah tidak mau lagi menjawab pertanyaan. Bertanya boleh, sepanjang saya ada waktu dan bisa membantu insya Allah akan saya jawab. Tapi intinya adalah, bagaimana teknik bertanya yang dapat menghasilkan nilai tambah yang besar, bukan hanya untuk penanya, tapi juga untuk penjawab. Mengingat saya tidak dibayar untuk menjawab pertanyaan Anda, melainkan sebagai sedekah dan niat baik saja. Di lain pihak, dalam menjawab pertanyaan Anda, ada waktu yang saya gunakan. Waktu ini entah merupakan hak pelanggan saya (yang membayar untuk jasa saya), atau hak keluarga di rumah. Jadi untuk kebaikan kita semua, mohon baca artikel berikut sampai tuntas.

RTFM adalah singkatan dari Read The F!@#*ing Manuals, atau Read The Fine Manual, tergantung mood Anda saat mengucapkannya.

Kalimat sederhana, tapi entah kenapa banyak orang yang tidak melakukannya. Untuk kesekian kalinya, saya mendapat pertanyaan, “Bagaimana cara pakai ini? Bagaimana menjalankan aplikasi itu? Mengapa framework ini tidak berjalan seperti harapan saya?” dan pertanyaan lain yang sejenis.

Bukan, ini bukan tentang playbilling. Playbilling memang parah dokumentasinya, jadi bukan salah Anda kalo mengalami kesulitan :D

Yang sedang saya bicarakan adalah teknologi yang sehari-hari digunakan programmer. Misalnya PHP, Java, Hibernate, Spring, Freemarker, Linux, dan lainnya. Itu semua adalah produk mature, yang siap pakai, sudah banyak komunitasnya. Dengan demikian, manual dan dokumentasi pasti tersedia di mana-mana.

Sering sekali terjadi, ada yang tanya ke saya, baik melalui Y!, SMS, telpon, dan sebagainya. Dulu, saya masih mau menjawab panjang lebar. Akhir-akhir ini, pertanyaan semakin banyak, jadi respon standar saya adalah balik bertanya. 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 :D 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 :P . 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.


Intro Manajemen Proyek

Apabila kita ditunjuk menjadi project manager, ada beberapa hal yang harus kita kelola, yaitu:

  • Waktu

  • Uang

  • Orang

  • Teknologi

Semuanya adalah variabel yang sangat dinamis. Masing-masing seringkali berubah seenaknya sendiri.

Waktu tidak dapat diprediksi, manajemen seringkali memajukan deadline secara sepihak. Demikian juga dengan uang, banyak pos pengeluaran yang sulit diprediksi dan dapat membengkak tiba-tiba.

Mengelola orang tidak kalah sulitnya. Resign, sakit, cuti mendadak, adalah hal yang biasa bagi project manager yang berpengalaman (baik pengalaman sukses maupun gagal :P). Teknologi baru memiliki faktor ketidakpastian yang tinggi. Terlihat mudah di tutorial, tapi ternyata sulit sekali untuk menangani masalah yang kompleks.

Semua faktor di atas dapat disimpulkan dengan satu kata: RESIKO. Pekerjaan project manager sebetulnya adalah mengelola resiko.

Dalam mengelola resiko, cuma ada dua teknik: mitigasi dan kontingensi. Mitigasi adalah tindakan pencegahan, yaitu tindakan yang kita lakukan agar resiko tidak terjadi. Sedangkan kontingensi adalah tindakan pengobatan, yaitu tindakan yang kita lakukan ketika resiko sudah benar-benar menjadi perkara.

Dengan bermodalkan akal sehat dan sedikit inisiatif, kita sebetulnya bisa mengidentifikasi resiko proyek. Sebut saja identifikasi resiko ini sebagai PR buat project manager sebelum project mulai dijalankan. Beberapa resiko yang umum terjadi dapat diantisipasi di awal sehingga tidak menjadi perkara di kemudian hari.

Terdengar sederhana? Memang benar. Saking sederhananya, sering diabaikan orang.

Pada artikel selanjutnya, saya akan berikan contoh resiko yang pasti dihadapi dalam project. Tentu saja lengkap beserta teknik mitigasi dan kontingensinya.


Kategori Baru: Manajemen

Sudah beberapa bulan ini saya tidak coding seintensif biasanya. Ini berkaitan dengan project baru saya. Sekarang saya ada di divisi Business Process Improvement, yang intinya adalah membuat proses pengembangan software menjadi lebih baik.

Konsekuensinya, wawasan saya beralih dari perkembangan framework terbaru di Java menjadi teknik manajemen proyek yang baik.

Untuk merangkum pengetahuan yang saya dapat di dunia baru ini, saya buatkan kategori manajemen. Di sini nantinya akan ditulis berbagai pengalaman, best practices, jebakan maut, maupun tips dan trik. Tentunya sejauh tidak melanggar perjanjian kerahasiaan dengan client.

Nantikan saja tulisannya. :D


Bacaan Wajib

Sepanjang karir saya sebagai programmer, ada beberapa bacaan yang kontribusinya sangat signifikan terhadap perkembangan diri saya.

Selain yang spesifik untuk Java, tapi ada juga yang bersifat umum, dapat diterapkan di bahasa apapun.

Berikut daftarnya. Daftar ini dapat diupdate sewaktu-waktu. Jadi silahkan sering-sering membuka halaman ini.

Pemrograman Umum

  1. The Art of Unix Programming - Eric Raymond

  2. Pragmatic Programmer: From Journeyman to Master - Andy Hunt & Dave Thomas

  3. Refactoring - Martin Fowler

  4. The Mythical Man Month - Fred Brooks

  5. Peopleware - Tom DeMarco & Timothy Lister

  6. Joel on Software

  7. Design Patterns: Elements of Reusable Object-Oriented Software - GoF

Java

  1. Effective Java - Joshua Bloch

  2. Hibernate in Action - Christian Bauer & Gavin King

  3. J2EE Design and Development - Rod Johnson

Penerbit dan cara membeli/mendownload dapat diperoleh melalui Google. Semoga bermanfaat bagi para pembaca.


File Manager

Kadangkala, kita tidak terlalu beruntung, mendapatkan jatah akses internet yang serba terbelenggu. Cuma bisa browsing, tidak bisa ssh, tidak bisa chat, ataupun tidak bisa ftp.

Pada saat seperti itu, kita dapat menggunakan aplikasi chatting berbasis web, atau menginstal aplikasi file manager untuk mengelola file di server hosting kita.

Untuk file manager, saya menggunakan File Thingie, aplikasi PHP yang cuma terdiri dari satu file. Cukup kirim ke server, dan browse melalui browser.

File Thingie User Interface

Sederhana dan mudah.