Showing posts with label lesson learn. Show all posts
Showing posts with label lesson learn. Show all posts

Sunday, September 18, 2016

Lesson Learn #2 : menjadi software engineer

Disclaimer : ini adalah pendapat pribadi penulis, penulis bukan expert engineer, masih junior dan butuh banyak masukan *pray*

Permasalahan

  • Engineer yang baru bergabung dengan tim, meski sangat pintar, namun kadang tidak bisa mengimbangi tim nya. Hal ini bukan melulu hal yang buruk, permasalahan-permasalahan yang terjadi misalnya
  • Tempat yang baru cukup santai, namun bertanggung jawab, dimana bisa work from home (WFH) kapan saja asal deliver. Si anak baru belum terbiasa dengan hal ini, karena mungkin butuh diskusi langsung, pair programming untuk bisa familiar dengan codebase yang ada.
  • Tempat yang baru sangat fleksibel dan realistis dengan apa yang harus di achieve di tiap sprint, si anak terlalu pintar dan memikirkan semua hal, sehingga achivement nya hanya setengah dari apa yang ada.
  • Tempat yang baru tidak peduli dengan anak baru atau anak lama, ketika ada yang masuk silahkan tenggelam atau berenang (dengan inisiatif sendiri).

Uraian di atas merupakan sedikit dari banyak permasalahan-permasalahan yang terjadi dalam dunia software engineering. Kali ini saya akan membahas dari satu sisi, yaitu sudut pandang engineer baru.

Saya belum lama-lama banget berkecimpung di dunia software engineering, namun pernah bekerja di beberapa perusahaan dengan latar belakang yang berbeda membuat saya banyak mengambil hikmah, dan membuat saya bersyukur dipertemukan dengan orang-orang hebat di masing-masing perusahaan tersebut sampai dengan saya yang sekarang. *maaf jadi melow :(

Attitude, habit, and culture come first before code quality

Attitude

Why? Menurut saya ini tidak hanya tentang menjadi seorang engineer, namun menjadi seorang manusia.
Di atas langit masih ada langit, apa yang kita tanam pasti akan kita tuai nanti (malah jd berpepatah ria :D). Sebagai seorang manusia, apalagi engineer di dunia IT yang perkembangan nya nggak akan ada habisnya jelas, pepatan diatas langit masih ada langit, pas banget buat saya, yang serba pas-pas an dan cupu untuk masalah teknologi yang kekinian.
Hubungan nya dengan attitude jelas, yang pertama kita harus bisa menerima feedback apa pun, ketika mereka memberikan kritik, marah, apapun, itu berarti masih ada kepedulian terhadap kita. They want us to run together with them, so they give us feedback and we can run faster with them.
Yang ke dua, do as best as I can (ada hubungan nya sama pepatah apa yang kita tanam, pasti akan kita tuai nanti :D). YOLO lah alias you only live once, jangan sampe menyesal karena kita nggak berusaha semaksimal mungkin sampe titik darah penghabisan. Sebagai engineer, ketika malas sudah merajai (ibarat nya googling aja males) please just leave. Kasar nya, perusahaan sudah membayar untuk bekerja 8 jam sehari, jika tiap hari cuma ngeluh, males-males an, facebookan, youtube an, nge-game, banyak alasan, ke laut aja dah.
Kenapa saya bilang ke laut aja, karena di perusahaan manapun dengan metal produktifitas yang rendah, pasti tidak akan bertahan lama juga (kecuali di perusahaan-perusahaan yang habit nya memang demikian).
Mental ini, jelas akan menghambat tim, sebagai seorang engineer, ekspektasi nya adalah dia bisa menyelesaikan masalah yang ada, namun jika berusaha saja dia tidak mau :( bisa jadi blocker buat tim, masih berjalan ketika tim sudah berlari.
Saran saya jika memang menemukan sebuah permasalahan yang pelik, jangan langsung bertanya ini bagaimana solved nya? (karena jelas yang ditanya juga belum tentu tahu jawaban nya, sesama engineer :|) namun dicari dulu, dicoba, kalau memang sudah dicoba dan masih tidak bisa, baru di diskusikan, ya DISKUSI, bukan minta jawaban :)

Sebenernya attitude ini luas banget, namun ini menurut saya paling penting jelas selain menjunjung kode etik engineer :)

Habit

Saya menyadari ini penting waktu menghadiri workshop ThoughtWorks di Binus beberapa tahun lalu, disitu mereka menceritakan how they work, menjadi lebih baik, menemukan proses bekerja yang lebih efektif adalah keseharian mereka.
Disitu juga saya pertama kali memahami tentang agile dan scrum. Implementasi agile di setiap tempat mungkin berbeda-beda, disini saya akan menceritakan pengalaman saya dengan tim saya yang sekarang.
Baru 3 bulan terakhir (semenjak 1 tahun tim dibentuk) kami menemukan ritme kerja yang lebih baik dan lebih produktif (meski belum sempurna dan masih banyak kekurangan sana sini). Dan ketika kami melakukan obrolan kecil (yang mungkin bisa dibilang evaluasi) ada beberapa hal mengapa hal ini bisa kami capai. Mungkin beberapa hal yang akan saya jelaskan di bawah ini sudah biasa dilakukan :D, namun ini hal baru bagi tim kami hehehe ^^v

Kami selalu melakukan diskusi di awal sprint apa yang akan akan kami lakukan setelah sprint planning. Diskusi teknikal dan pembagian task untuk masing-masing. Disini kami sudah tahu apa yang akan harus dilakukan, jika masih belum jelas, maka diskusi akan terus berlanjut :D atau kami break untuk memikirkan nya, dan membahas nya kembali esok hari (ini lebih sering sik hahhahaa)

Dalam proses development, kesulitan pasti ada, karena kita berhubungan dengan teknologi yang baru, namun kita tahu porsi masing-masing, dan kami ada di level yang sama (semuanya juga masih belajar :D) google, try, and discuss :)

Pull request, karena engineer juga tidak luput dari khilaf, bisa belajar dari code engineer lain, dan mendapat feedback yang membangun. Secara pribadi saya merasakan manfaatnya, bisa mempercepat learning curve, ketika ada code yang salah atau tidak efektif, maka engineer lain akan mengomentari dan memberikan feedback, saya akan bertanya kenapa dan akan berlanjut dengan diskusi, ilmu baru dari hanya sebaris code :)
Tim kami belum mempunyai QA, namun masing-masing dari kami tahu bahwa test itu penting, penting banget. Kami sadar akan hal tersebut dan memastikan code yang kami deploy sudah well tested. Plus, kami melakukan regression bersama-sama sebelum naik production, meski belum sempat melakukan test-test yang lain T_T

Meski kadang kami melakukan WFH, namun kami punya pengertian yang sama bahwa WFH means work from home, yang artinya selama jam kerja harus bisa dihubungi via slack atau apapun, dan tidak boleh menjadikan blocker buat tim.

Kesimpulan nya adalah menurut saya agile itu habit, kebiasaan, lebih bagaimana kita bekerja, dan berubah menjadi lebih baik setiap harinya. Bagaimana kita tahu apa tanggung jawab kita, dan apa yang harus dilakukan, untuk menjadi lebih baik untuk tim dan pribadi :)
Tanpa scrum master pun kita bisa :D

Engineering culture

Engineering culture disini ada hubungan nya dengan poin-poin yang sudah saya sebutkan di atas, attitude dan habit. Pull request and pair programming is a must. Pull request selain bisa meng-improve code kita, juga membiasakan dengan habit git flow, bahwa ketika bekerja dengan banyak engineer harus memikirkan engineer yang lain, jangan sampai code yang kita push menjadi blocker dan mengganggu engineer yang lain. Pair programming bisa sangat membantu engineer yang baru bergabung untuk mempercepat familiar dengan codebase yang ada.
Saya termasuk orang yang tidak mendukung lembur (saya pernah lembur btw). Beberapa engineer mungkin bependapat bahwa kalau nggak lembur nggak asik, bekerja di hari libur adalah hal biasa. Buat saya ketika kita harus lembur, it means there’s something wrong. Entah dengan estimasi yang salah, atau engineer nya tidah bekerja dengan produktif di waktu yang dijadwalkan, atau ada hal-hal yang lupa dikomunikasikan dan baru diketahui pada proses development.
Lembur membuat engineer kelelahan yang tidak wajar bahkan burn out, di situasi yang seperti ini, engineer bekerja dengan kurang maksimal. Jadi daripada lembur, kita harus mekakukan estimasi dengan baik, dan mengkomunikasikan segala permasalahan di awal sprint, dan tentu saja bekerja dengan produktif.
Salah satu keuntungan sprint yang pendek adalah kita bisa melakukan iterasi dengan cepat, meng evaluasi nya, dan menentukan apa yang harus dilakukan selanjutnya dengan melihat evaluasi sprint sebelum nya.

Point penting yang perlu saya garis bawahi adalah, diskusi teknikal setelah sprint planning, pull request, pair programming, dan bekerja produktif :)


Code quality is a must

Sebagai engineer jelas code quality is a must. Visi nya adalah bahwa kita menulis code bukan untuk mesin, namun untuk engineer lain (yang mungkin akan melanjutkan code kita) *kata-kata ini adalah kutipan, namun saya lupa darimana :|

Kesimpulan

Dari permasalahan-permasalahan diatas dapat disimpulkan bahwa sebagai engineer baru
  • Harus explore sendiri ketika memang tidak ada support, tidak sungkan bertanya, meminta waktu untuk diskusi, karena tim adalah yang nomor satu :)
  • Idealist itu penting namun realistis itu harus, solusinya saat sprint planning harus di sampaikan ideliasme nya, sehingga apa yang di achieve memang itulah yang diharapkan.
  • engineer come to solved problems, so don’t make any other problems :)

Thank you :)
#ilearnnewthingseveryday

Buku yang harus dibaca ^^v :
The Effective Engineer Book

Wednesday, June 15, 2016

Lesson Learn #1 : Pelajaran berharga selama bergabung dengan tim produk

Sudah hampir 1 tahun saya bergabung di tim product (product development team*). Dan dalam satu tahun itu banyak sekali hal yang saya pelajari.
Ada beberapa hal di tim product yang sangat berbeda dengan tim project, paling tidak uber membutuhkan waktu 3 tahun untuk sampai pada “better, faster, cheaper, than a taxi”.

Build your market first
Pada dasarnya hasil akhir sebuah product adalah ditentukan dari seberapa banyak user yang menggunakan. Sebagai contoh : jika itu marketplace selain seberapa banyak usernya, maka seberapa banyak repeat order yang terjadi.
Sebagai contoh adalah sejarah sale stock Indonesia yang menurut saya tech company paling top menurut hemat saya (jelas saya subjective ^^v). Awalnya sale stock bukanlah tech company, namun online shop biasa yang mengandalkan sirclo dan fan page di Facebook. Lesson learn yang bisa diambil adalah sebelum menentukan akan membagun sebuah product (dengan dukungan tech team) business model harus sudah tervalidasi terlebih dahulu. Market sudah ada, dan revenue sudah jelas. Yes, secure your demand and market first. Mengapa demikian? Karena invest tech team itu tidaklah murah, dan pada dasarnya mobile atau web adalah sarana pengganti proses yang sudah ada agar customer lebih mudah. Jika customer belum ada, bagaimana mungkin akan dapat revenue, mungkin itu bisa disebut bakar uang.

Product Owner, CTO and Product Manager is a must
Ini dibutuhkan ketika business model sudah tervalidasi dengan baik dan revenue sudah melimpah. Dalam gambar dibawah “You are here” merupakan product manager. Product owner dalam lingkaran bisnis dan CTO dalam lingkaran tech. Mengapa 3 role ini sangat penting. Ketika membangun sebuah product, hal utama memang bisnis, bagaimana bisnis bisa scale up dengan cepat, dan untuk mendukung bisnis dengan cepat perlu dukungan tech team. Tim bisnis punya roadmap, product owner berperan. Tim tech juga harus punya roadmap yang harus sejalan dengan bisnis yg ada, CTO yang berperan. Product Manager lah yang menjembatani keduanya agar dari sisi bisnis dan tech agar align. Ketika salah satu role tidak ada maka akibatnya, contohlah tidak ada CTO, so it will be no tech roadmap, dalam product development, tech roadmap itu penting karena product akan growth terus (jika sukses), dan itu perlu dipertimbangkan langkah demi langkah dalam proses pengembangan nya. Contoh sederhana, karena diburu waktu maka team tech melakukan development seadanya, dengan monolitik arch, akibatnya saat product makin compleks, susah untuk bisa scale. Begitu juga ketika tidak ada product manager, tidak ada yang menjembatani antara bisnis dan tech tim, antara bisnis dan tech tim bisa tidak align, tim tech sudah develop A, namun di akhir saat sudah jadi tim bisnis minta nya jadi B, itu akan jadi pekerjaan yang berulang-ulang dan membuang-buang waktu.


sumber https://media.licdn.com/mpr/mpr/jc/AAEAAQAAAAAAAAUxAAAAJDA0MmRhNjIzLWU0MjEtNGYyYi1hNTU0LTAyYzI2YzEyZDRmOQ.png

Both business roadmap dan tech roadmap is a must
Meskipun roadmap bisa berubah seiring waktu namun itu merupakan keharusan, karena roadmap merupakan guidance alias petunjuk kemana arah dan apa yang harus dikerjakan untuk mencapai target atau goal. Tanpa roadmap baik dari sisi bisnis maupun tech team akan kehilangan arah. Untuk tech team, you can’t code before the design and process is clear.

Get your priorities straight
Setelah roadmap nya jelas, maka perlu dipecah dalam task-task kecil dan saling disesuaikan antara tech team dan business team, priority mana yang harus dikerjakan terlebih dahulu. Target bisnis mana yang harus di achieve terlebih dahulu dengan support tech team. Jangan merubah prioritas ditengah-tengah development, karena akan menggangu development dan membuat tim memulainya dari 0. Jika memang ada sesuatu yang mendesak, priority yang berjalan, sebaiknya diselesaikan terlebih dahulu dalam sprint tersebut, di-release dan untuk sprint selanjutnya bisa dikaji ulang. 

Release sebanyak mungkin
Semakin banyak release, semakin cepat product tersebut bisa divalidate. Jika menggunakan sistem sprint (misal 2 minggu) maka setiap 2 minggu release, dan bisa divalidate. Untung nya adalah, ketika ada yang tidak sesuai, maka bisa diketahui lebih cepat, dan bisa dikaji untuk langkah selanjut nya.

Full role for tech team
Product tidak sama dengan project, project life time nya terbatas, namun kalau product, jika sukses, bisa seumur hidup. Membangun tech team di awal menurut saya (sekali lagi ini subjective) diluar CTO, tidak diperlukan banyak orang, namun masing-masing role ada. Minimal ada frontend engineer, backend engineer, QA engineer, dan system engineer. Tanpa salah satunya jelas akan keteteran. Contoh sederhana, di Indonesia (menurut saya) masih meremehkan peran QA, padahal kalau QA nya nggak happy (happy means no bug), gimana bisa release. Product merupakan sesuatu yang fiturnya akan selalu bertambah, dan perlu divalidate setiap hari, untuk bisa memastikan defect lebih awal, jika sebuah product di release tanpa melalui proses QA yang selayaknya, jangan harap user akan terpuaskan dengan product nya. Pada dasarnya engineer adalah manusia biasa yang bisa khilaf dan membuat bug. System engineer membantu kita dalam setup environment, FE dan BE engineer sudah pusing dengan dev apps, padahal untuk release butuh setup production server, security (contoh : implement https), dan lain-lain. 

Kesimpulan nya :

  • Membangun product bukan lah hal yang mudah, butuh rencana yang jelas, komitmen, kesabaran dan uang.
  • Sebagai bonus ada bacaan menarik apakah startup anda dying.


Sumber:
[ 1 ] http://www.foundingfuel.com/article/your-startup-is-dying/
[ 2 ] https://www.sirclo.com/blog/2014/09/berbagi-pengalaman-memulai-bisnis-online-sale-stock-indonesia
[ 3 ] https://news.greylock.com/taking-the-wrong-lesson-from-uber-ae4b41e7c7da#.104odukp6

Disclaimer :

  • *) Karena belum rilis jadi saya tidak bisa menyebutkan saya sedang membangun product apa :)
  • penulis bukanlah expert dalam product development, apa yang ditulis merupakan pendapat pribadi :)