I once wrote that I want to post blog entries in two languages, namely English and Bahasa Indonesia. My motivation was to explain conceptual topics in Bahasa Indonesia to help fellow Indonesians grasp important basic concepts, but judging from traffic and comments posted, people don't seem to care.
I was idealistic, but then I realize I don't have all the time in the world to do time-consuming-but-insignificant work. From now on I'm going to stick on using English.
Wednesday, August 18, 2010
Thursday, August 12, 2010
Programmer dan tukang jahit
Profesi programmer agak mirip dengan profesi tukang jahit. Keduanya bisa bekerja di industri yang terkomoditas, atau bekerja di industri yang lebih menghargai mereka sebagai individu. Gw kasih contoh.
Tukang jahit, yang just like another tukang jahit, bekerja di pabrik konveksi bersama ratusan just another tukang jahit lainnya. Kita sebut mereka Tipe A. Di tempat lain, tukang jahit berpakaian casual di kantor, naik pesawat ke berbagai daerah untuk bertemu klien, dan gajinya lebih besar dibanding kolega mereka yang bekerja di pabrik. Kita sebut mereka Tipe B.
Kenapa Tipe B terlihat lebih beruntung? Karena mereka not just another tukang jahit. Mereka masih perlu menjahit, dan harus bagus dalam menjahit, tapi menjahit bukanlah satu-satunya tugas/kemampuan mereka. Mereka merancang baju, memberikan saran kepada klien, dan mungkin menulis artikel di majalah fashion. Mereka memiliki nilai tambah yang menjadikan mereka lebih dari tukang jahit.
Demikian juga dengan programmer. Baru-baru ini ada diskusi di milis JUG Indonesia yang meng-undervalue pekerjaan programmer dibanding analyst. Sampai ada yang menyesal, "Harusnya gw jangan lama-lama jadi programmer. Harusnya jadi analyst." Hmm.. programmer yang seperti apa dulu?
Kalau kamu jadi programmer yang hanya tahu bagaimana (how) melakukan sesuatu tanpa tahu kenapa (why) kamu harus begitu, kamu tidak ada bedanya dengan tukang jahit di pabrik konveksi. Di dunia Java, tidak hanya persaingan yang ketat, tapi ada puluhan framework bermunculan setiap hari seperti upil. Kalau kamu tidak menguasai konsep, kamu akan kewalahan.
Tidak hanya harus mumpuni di bidang spesifik kamu (coding dalam bahasa Java), kamu juga harus familiar dengan siklus software engineering dari pengumpulan requirements sampai User Acceptance Test (UAT). Banyak hal lain yang harus dikuasai, yang untungnya (atau sayangnya?) tidak begitu berhubungan dengan coding.
Secara umum, seorang programmer yang memiliki nilai tambah harus:
Note: Tulisan ini tidak bermaksud mendiskreditkan tukang jahit apalagi yang bekerja di pabrik konveksi.
Tukang jahit, yang just like another tukang jahit, bekerja di pabrik konveksi bersama ratusan just another tukang jahit lainnya. Kita sebut mereka Tipe A. Di tempat lain, tukang jahit berpakaian casual di kantor, naik pesawat ke berbagai daerah untuk bertemu klien, dan gajinya lebih besar dibanding kolega mereka yang bekerja di pabrik. Kita sebut mereka Tipe B.
Kenapa Tipe B terlihat lebih beruntung? Karena mereka not just another tukang jahit. Mereka masih perlu menjahit, dan harus bagus dalam menjahit, tapi menjahit bukanlah satu-satunya tugas/kemampuan mereka. Mereka merancang baju, memberikan saran kepada klien, dan mungkin menulis artikel di majalah fashion. Mereka memiliki nilai tambah yang menjadikan mereka lebih dari tukang jahit.
Demikian juga dengan programmer. Baru-baru ini ada diskusi di milis JUG Indonesia yang meng-undervalue pekerjaan programmer dibanding analyst. Sampai ada yang menyesal, "Harusnya gw jangan lama-lama jadi programmer. Harusnya jadi analyst." Hmm.. programmer yang seperti apa dulu?
Kalau kamu jadi programmer yang hanya tahu bagaimana (how) melakukan sesuatu tanpa tahu kenapa (why) kamu harus begitu, kamu tidak ada bedanya dengan tukang jahit di pabrik konveksi. Di dunia Java, tidak hanya persaingan yang ketat, tapi ada puluhan framework bermunculan setiap hari seperti upil. Kalau kamu tidak menguasai konsep, kamu akan kewalahan.
Tidak hanya harus mumpuni di bidang spesifik kamu (coding dalam bahasa Java), kamu juga harus familiar dengan siklus software engineering dari pengumpulan requirements sampai User Acceptance Test (UAT). Banyak hal lain yang harus dikuasai, yang untungnya (atau sayangnya?) tidak begitu berhubungan dengan coding.
Secara umum, seorang programmer yang memiliki nilai tambah harus:
- Menguasai bahasa dan API platform spesialisasinya.
- Menguasai satu atau dua framework populer.
- Mengetahui konsep beberapa framework lain yang kamu tidak kuasai (supaya kamu tahu ada solusi lain untuk masalah yang lain).
- Familiar dengan siklus software engineering.
- Berpartisipasi aktif dengan analyst, jangan hanya terima mentah-mentah.
- (Soft-skill) Mampu mengerti motivasi dibalik requirements dari klien (Kenapa mereka mau itu? Kenapa solusi yang kita tawaran begitu? Kenapa bukan yang lain?).
Note: Tulisan ini tidak bermaksud mendiskreditkan tukang jahit apalagi yang bekerja di pabrik konveksi.
Wednesday, August 4, 2010
Java dan istri tua
Baru-baru ini muncul diskusi hangat di milis JUG Indonesia, judulnya seru: "Ask pemrograman yng keren selain java". Inti diskusinya, "Java konsumsi memory-nya besar (Isu #1) dan fitur bahasanya tidak semenarik bahasa-bahasa modern lain (Isu #2)". Blog ini adalah komentar gw soal diskusi itu.
Ingat bahwa Java(tm) terdiri dari tiga komponen:
- Java Virtual Machine (JVM)
- Java API
- Bahasa pemrograman Java (syntax)
Untuk Isu #1, Endy Muhardin berkomentar, "Ah yang bener". Gw setuju dengan Endy. Kita pakai analogi yuk. Anggaplah JVM sebagai mobil dan platform lain yang konsumsi memory-nya jauh lebih kecil sebagai motor. Untuk keliling kompleks perumahan atau ke warung, motor memang lebih ideal. Tapi kalau dari Jakarta ke Semarang, masak naik motor?
Meski ke luar kota bisa naik motor (dan beberapa orang melakukannya), bukan berarti itu cara yang ideal. Demikian juga dengan software. Untuk beberapa aplikasi mungkin kita tidak memerlukan semua bells-and-wistle sebuah JVM sehingga overhead-nya tidak bisa kita terima, tapi untuk kebanyakan aplikasi bisnis, JVM (atau secara umum, VM, seperti CLI untuk .NET) adalah platform yang ideal.
Sekarang Isu #2: Bahasa pemrograman Java tidak seksi lagi.
Java diciptakan pada tahun 1995, bahasa-bahasa lain yang lebih seksi baru muncul belakangan ini. Ini seperti membandingkan bintang film tahun 1980 dengan artis muda jaman sekarang, atau lebih tepatnya membandingkan istri tua dengan istri muda. Mereka tidak bisa dibandingkan langsung—masing-masing ada kelebihan dan kekurangannya, "penggunaannya" pun berbeda (Catatan: bukan berarti gw mendukung poligami lho).
Ada opini untuk "meremajakan" Java dengan memasukkan fitur-fitur seksi ke dalam Java. Ini seperti memaksa istri tua kita untuk operasi plastik dan pengencangan payudara. Bisa sih. Tapi apakah perlu?
Ingat bahwa bahasa pemrograman Java digunakan oleh banyak orang—istri tua kita di-sharing ramai-ramai! Beberapa orang mungkin tidak nyaman kalau sang istri sejuta umat itu diubah-ubah. They like her the way she is. Kemungkinannya ada dua:
UPDATE: Hira Sirojudin mengeluh, "saat suatu aplikasi diminta untuk handling hingga ribuan user bahkan diatas 100ribu connected users, investasi infrastrukturnya mahal berlipat, ngak cukup hanya dengan 1 mesin berprosesor xeon 8core dan mengandalkan cluster&balancing di sana sini.intinya dirasa antara performance dan costnya ngak seimbang, walopun itu ngak semuanya mesti disalahkan sama javanya". Keluhan diterima. Tapi sebelum menyalahkan Java, mungkin harus dilihat aplikasinya dulu. Kalau biaya rumah tangga membengkak, belum tentu itu karena salah istri tua kita kan? :)
Ingat bahwa Java(tm) terdiri dari tiga komponen:
- Java Virtual Machine (JVM)
- Java API
- Bahasa pemrograman Java (syntax)
Untuk Isu #1, Endy Muhardin berkomentar, "Ah yang bener". Gw setuju dengan Endy. Kita pakai analogi yuk. Anggaplah JVM sebagai mobil dan platform lain yang konsumsi memory-nya jauh lebih kecil sebagai motor. Untuk keliling kompleks perumahan atau ke warung, motor memang lebih ideal. Tapi kalau dari Jakarta ke Semarang, masak naik motor?
Meski ke luar kota bisa naik motor (dan beberapa orang melakukannya), bukan berarti itu cara yang ideal. Demikian juga dengan software. Untuk beberapa aplikasi mungkin kita tidak memerlukan semua bells-and-wistle sebuah JVM sehingga overhead-nya tidak bisa kita terima, tapi untuk kebanyakan aplikasi bisnis, JVM (atau secara umum, VM, seperti CLI untuk .NET) adalah platform yang ideal.
Sekarang Isu #2: Bahasa pemrograman Java tidak seksi lagi.
Java diciptakan pada tahun 1995, bahasa-bahasa lain yang lebih seksi baru muncul belakangan ini. Ini seperti membandingkan bintang film tahun 1980 dengan artis muda jaman sekarang, atau lebih tepatnya membandingkan istri tua dengan istri muda. Mereka tidak bisa dibandingkan langsung—masing-masing ada kelebihan dan kekurangannya, "penggunaannya" pun berbeda (Catatan: bukan berarti gw mendukung poligami lho).
Ada opini untuk "meremajakan" Java dengan memasukkan fitur-fitur seksi ke dalam Java. Ini seperti memaksa istri tua kita untuk operasi plastik dan pengencangan payudara. Bisa sih. Tapi apakah perlu?
Ingat bahwa bahasa pemrograman Java digunakan oleh banyak orang—istri tua kita di-sharing ramai-ramai! Beberapa orang mungkin tidak nyaman kalau sang istri sejuta umat itu diubah-ubah. They like her the way she is. Kemungkinannya ada dua:
- Alasan psikologis. "Gw malas ah belajar yang baru lagi."
- Alasan bisnis. Bagaimana dengan compatibility? Training? Semakin banyak fitur tentu semakin banyak yang dipelajari dan semakin banyak yang perlu di-maintain (arguably).
UPDATE: Hira Sirojudin mengeluh, "saat suatu aplikasi diminta untuk handling hingga ribuan user bahkan diatas 100ribu connected users, investasi infrastrukturnya mahal berlipat, ngak cukup hanya dengan 1 mesin berprosesor xeon 8core dan mengandalkan cluster&balancing di sana sini.intinya dirasa antara performance dan costnya ngak seimbang, walopun itu ngak semuanya mesti disalahkan sama javanya". Keluhan diterima. Tapi sebelum menyalahkan Java, mungkin harus dilihat aplikasinya dulu. Kalau biaya rumah tangga membengkak, belum tentu itu karena salah istri tua kita kan? :)
Subscribe to:
Posts (Atom)