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.

Pengetahuan wajib buat programmer

Setelah beberapa kali mewawancara calon programmer baru, saya menemukan bahwa cukup banyak dari kandidat pelamar kerja, baik fresh graduate maupun yang (ngakunya) experienced masih belum memahami beberapa pengetahuan dasar.

Entah apa sebabnya. Beberapa kemungkinan bisa saya perkirakan, sebagai berikut:

  • Tidak diajarkan di kuliah

  • Diajarkan, tapi mahasiswa bersangkutan lebih banyak dugem daripada kuliah

  • Diajarkan dan pernah mengerti, tapi karena jarang digunakan jadi lupa

Apapun masalahnya, yang jelas kenyataan ini sangat memprihatinkan. Indonesia tidak akan maju jika bibit tenaga kerjanya mudah merasa cukup.

Secara pribadi, saya punya standar sendiri dalam melakukan seleksi. Jadi buat yang mau melamar kerja, silahkan berlatih. Siapa tahu Anda berhadapan dengan saya di meja wawancara :D

Berikut menu wajib programmer:

  • Konsep dasar sistem operasi.

  • Konsep dasar jaringan.

  • Konsep dasar relational database.

  • Karena sekarang jaman internet, maka wajib memahami protokol HTTP, FTP, POP3, SMTP, SSH.

  • Karena sekarang jaman globalisasi, maka wajib memahami Unicode.

  • Lebih dari satu bahasa pemrograman.

  • Cara menggunakan Version Control.

Berikut pertimbangannya.

Kebanyakan dari programmer Indonesia biasanya membuat aplikasi di atas sistem operasi, sehingga banyak yang berpendapat bahwa tidak perlu memahami cara kerja sistem operasi. Pendapat ini boleh saja, kalau Anda adalah staf akunting yang kebetulan dipaksa bos untuk membuat aplikasi general ledger. Untuk programmer profesional, pemahaman ini akan membuat Anda lebih siap untuk membuat aplikasi server yang biasanya multithreaded dan harus efisien digunakan dalam waktu yang lama.

Pemahaman mendalam di salah satu sistem operasi juga merupakan nilai tambah yang signifikan. Dengan mengetahui struktur internal sistem operasi (misalnya Linux), kita dapat mengetahui berbagai pertimbangan dalam merancang aplikasi besar yang terus berkembang.

Saat ini, kalau kita harus membuat aplikasi, besar kemungkinannya aplikasi kita tidak berjalan sendiri. Aplikasi tersebut pasti harus berhubungan dengan internet, melayani banyak pengguna, atau berhubungan dengan perangkat lain seperti handphone atau PDA. Untuk itu, pemahaman atas konsep jaringan sangat penting.

Tes sederhana untuk menguji pemahaman Anda. Coba jelaskan proses yang terjadi mulai dari Anda mengetik http://endy.artivisi.com di browser Anda, sampai halaman ini terbentang di depan mata Anda. Dengan mendengarkan jawaban Anda, saya akan tahu kualitas Anda. Jawaban yang saya harapkan mengandung istilah name-resolve, http-request, virtual directory, query database, HTML response, dan CSS. Kalau Anda menyebutkan (apalagi menjelaskan) tentang routing, gateway, proxy, port 80, saya akan lebih senang lagi.

Tentang relational database. Saya tahu ini pasti pernah diajarkan di kuliah. Jadi lulusan informatika dan sejenisnya jangan bilang belum diajarkan. Yang saya maksud bukan sekedar sintaks SQL. Sintaks itu gampang, bisa dicari dengan mudah di internet. Yang saya inginkan adalah penjelasan tentang Boyce-Codd Normal Form, lengkap dengan contoh kasusnya, di luar kepala. Kalau sudah bisa menjelaskan ini, inner join, subquery, union, itu perkara sepele.

Protokol HTTP sekarang adalah protokol yang paling banyak digunakan di internet. Jangan salah, ini bukan tentang sintaks HTML atau CSS. Jadi apa? Begini, coba tampilkan halaman website ini dengan menggunakan telnet. Benar, bukan browser, tapi telnet.

Kalau sudah bisa browsing dengan telnet, sekarang coba untuk baca email via telnet. Menggunakan protokol POP3 atau IMAP tentunya. Punya account Gmail kan? Hare gene gak punya? Ya bagus, kalo punya coba aktifkan fitur POP3nya, setelah itu buka dengan telnet.

Unicode itu penting supaya aplikasi kita tetap bisa diinstal di komputer orang Jepang atau Korea, atau komputer berbahasa Sansekerta.

Pemahaman lebih dari satu bahasa itu penting agar wawasan kita terbuka. Bahwa tidak ada bahasa yang one-fit-all, bahwa ada cara berpikir yang berbeda dalam tiap bahasa, bahwa komunitas tiap bahasa berbeda budayanya. Semua ini akan berkontribusi dalam pendewasaan kita dalam berdiskusi dan menanggapi perbedaan (terutama pendapat).

Satu lagi, trend bahasa pemrograman adalah, tiap sepuluh tahun, market leader berganti. Dulu COBOL, kemudian C++, sekarang Java. Jadi, kemampuan belajar bahasa baru sangat penting. Bukan cuma bahasanya yang penting, tapi kemampuan belajarnya yang lebih penting.

Di tempat saya bekerja, penggunaan version control adalah wajib. Ini standar (de facto) internasional. Kalau kita punya project opensource, baik di Sourceforge, Apache, Codehaus, dan semua hosting project opensource, pasti kita akan diberikan version control. Silahkan download dan coba gunakan CVS atau Subversion.

Ok, itu standar minimal saya. Menurut Anda terlalu sulit? Hmm .. kalau begitu dunia IT menjadi programmer nampaknya kurang cocok buat Anda. Silahkan coba karir lainnya, misalnya notaris atau sopir busway :D


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.