Alif Akbar's

1. Pindahkan raja ke tempat yang lebih aman

Pindahkan raja ke tempat yang lebih aman. Ke tempat yang tidak bisa mendapatkan skak (check). Dalam dunia nyata mungkin berusaha memposisikan diri jauh dari konflik. Untuk sementara, jadi orang yang selalu setuju, agar tidak kena serangan.

2. Posisikan bidak terkuat yaitu ratu di petak sentral

Posisikan bidak terkuat yaitu ratu di petak sentral. Agar banyak petak yang dikontrol, sehingga menjadi dominan. Dalam dunia nyata seperti berusaha melakukan pekerjaan yang sentral di tim, yang dampaknya besar. Sehingga kamu menempati peran sentral yang unreplaceable.

3. Pindahkan kuda menuju petak sentral

Pindahkan kuda menuju petak sentral untuk membuka rute. Untuk mempermudah langkah berbelok kuda dalam penguasaan ruang. Dalam dunia nyata seperti perbanyak skill, yang bahkan mungkin tidak inline dengan profesi yang tengah dijalani. Sehingga kapan pun dibutuhkan, kita siap membantu/bekerja untuk posisi itu.

4. Koneksikan pion yang terisolir

Koneksikan pion yang terisolir untuk membentuk rantai pion yang saling menjaga. Dalam dunia nyata, buka lagi koneksi ke teman2 lama. Agar bisa saling menolong, setidaknya bisa saling memberi referral ataupun menawarkan projek.

5. Pindahkan benteng ke lajur terbuka

Pindahkan benteng ke lajur terbuka (open file). Agar siap kapan pun untuk memindahkan benteng (rook lift). Dalam dunia nyata seperti bersiap kapan benteng tempat kerja harus pindah.

6. Hubungkan kedua benteng

Hubungkan kedua benteng agar saling menjaga. Biasanya satu benteng di lajur terbuka, satu lagi mengamankan raja. Dalam dunia nyata mungkin dengan bersiap seperti poin sebelumnya, namun sekaligus perkuat benteng diri. Seperti berhemat dan perbanyak emergency fund.

7. Posisikan peluncur di diagonal terpanjang

Last but not least, posisikan peluncur di diagonal terpanjang. Agar dapat membidik posisi terjauh sekalipun. Dalam dunia nyata, mungkin dengan memotong diagonal melalui gagasan atau inovasi lintas unit yang membuat kita dicari oleh banyak orang. Bisa juga dimulai dengan menempatkan pondasi yang dapat memberikan keuntungan dikemudian hari.

Apa itu pawang hujan?

Mungkin teman teman sudah tidak asing dengan istilah ini, karena bisa dikatakan sudah menjadi bagian dari budaya kita. Hampir setiap acara besar ataupun acara penting jasa pawang hujan selalu dicari. Pawang hujan sendiri adalah sebuah profesi klenik yang memiliki spesialisasi mengendalikan cuaca. Ia dipercaya bisa memanggil ataupun menunda hujan. Perlu digarisbawahi, kemampuan ini merupakan sebuah kepercayaan. Apakah kemampuan tersebut benar ataupun tidak, sulit untuk dibuktikan secara sains.

Satu hal yang menarik ialah, kemampuan mengendalikan cuaca ini bukan sesuatu yang khas dari Indonesia. Hampir semua kepercayaan di dunia memiliki sedikit banyaknya kemampuan yang mirip. Budaya kuno Aztec, Maya, menumbalkan manusia untuk mendatangkan hujan[1]. Ritual amagoi untuk meminta hujan[2] dan boneka Teru teru bōzu[3] untuk menolak hujan di jepang. Sholat istisqa dalam agama islam untuk meminta hujan [4].

Mendatangkan pawang hujan itu sebuah kebodohan!!

Respon negatif yang muncul umumnya berpusat pada klaim bahwa tindakan ini merupakan hal yang bodoh. Mengendalikan cuaca dengan pendekatan spritual adalah sebuah kepalsuan. Melakukan aksi ini dijaman modern sama dengan memamerkan kedunguan di depan publik. Respon negatif ini sangat masif, hingga hastag memalukan (#memalukan) menjadi trending di media sosial twitter.

Namun, menjadi masalah disini adalah klaim "bodoh" untuk sebuah hal yang berkaitan dengan kepercayaan. Karena dengan perbedaan kepercayaan maka standar bodoh ini akan berbeda, hanya akan berujung pada saling mencemoh. Mungkin bisa saya berikan contoh penerapan kepercayaan yang terdengar lebih saintifik. Coba jawab pertanyaan berikut

"Apakah di dalam kepala kamu ada otak?"

Kamu pasti akan menjawab "iya", dan memberikan berbagai alasan. Tapi taukah? kamu tidak akan pernah bisa 100% membuktikan kepercayaan mu itu, sebelum kepala mu dibuka. Bagi mereka yang percaya bahwa kepala berisi air akan mencari berbagai alasan untuk menolak bukti yang kamu ajukan. Bahkan jika kamu memberikan bukti isi kepala manusia lain yang telah meninggal (membedah mayat). Hal yang terbukti adalah isi kepala manusia itu ialah otak namun kepala mu belum tentu berisi otak.

Inilah kenyataan dari sains. Nilai kebenaran dari sains tidaklah 100%. Sains hanya dapat meningkatkan kepercayaan kita dengan bukti bukti dari observasi. Begitu ada bukti baru, kepercayaan dapat meningkat atau bahkan berubah 180 derajat. Bukan hanya bukti baru, perubahan perspektif pun dapat merubah kebenaran sains. Misal, gravitasi, sebuah gaya yang membuat benda jatuh kebawah, dengan perubahan perspektif dari pengamat dapat menjadi bumi-lah yang bergerak mendekati benda.

Jadi apakah pawang hujan bodoh? Hmm.. Tergantung.

Oke sekarang saya ingin mengajak teman teman sedikit mengganti perspektif. Mari kita mencoba melihat sudut pandang makro terhadap peristiwa ini. MotoGP sendiri adalah ajang industri untuk ujuk gigi kemampuan teknologi kendaraan termutakhir. Selain itu sirkuit mandalika yang dibangun dalam sekitar waktu satu tahun menjadi pembuktian Indonesia dalam kemampuan pengembangan infrastruktur. Hal ini menjadikan MotoGP seri madalika bukan hanya menarik penikmat balapan tapi juga dari dunia industri, arsitektur, dan bahkan politik.

Kreativitas jenius orang dibalik layar

Momen langka MotoGP mandalika sudah sepantasnya dimanfaatkan sebaik mungkin untuk meningkatkan nama Indonesia di mata global. Lalu, apakah atraksi penolakan hujan merupakan hal yang blunder?

Mengapa saya sebut atraksi? Pawang hujan bukan baru kali ini digunakan dalam acara besar, namun biasanya selalu disembunyikan, beraksi dibelakang panggung. Kali ini pawang hujan tersebut beraksi di depan kamera. Melakukan ritual dihadapan ribuan bahkan mungkin jutaan mata manusia. Diliput secara detail depan kamera dan bahkan hype telah dibangun beberapa hari sebelumnya. Jika itu tidak disebut sebagai atraksi, entah apa definisi atraksi buat kamu.

Kembali ke pertanyaan terkait blunder, sebelumnya izinkan saya untuk mengingatkan bahwa pemerintah sedang mengupayakan untuk melakukan diversifikasi ekonomi Indonesia. Salah satunya ialah melalui sektor pariwisata. Dimana hal ini berarti menginginkan sebanyak banyaknya orang asing datang ke Indonesia dan menghabisakan uangnya disini. Untuk itu pemerintah perlu melakukan marketing sepintar mungkin untuk menjual "produk" pariwisata ini.

Mungkin teman teman masih ada yang ingat ketika dulu presiden Jokowi menggunakan analogi dari film Game of Throne [5]. Lalu berikutnya ketika Asian Games, beliau diperankan melakukan aksi stunt motor[6]. Kedua topik ini berhasil membuat Indonesia viral dan menjadi bahan bicaraan di kawasan regional bahkan dunia. Indonesia berhasil mendapatkan atensi yang sangat dibutuhkan untuk meningkatkan pariwisata (Ingat teori marketing AIDA[7], Attention, Intention, Desire dan Action).

Kini, sebuah atraksi yang sangat mengundang rasa penasaran ditampilkan. Aksi mengatur hujan, yang umumnya orang sudah tinggalkan dibelahan bumi lain ditampilkan dengan bangganya didepan kamera beresolusi HD. Terlepas dari keberhasilan, kegagalan, maupun penolakan yang ada. Atraksi ini sukses mengundang percakapan bahkan liputan media di berbagai negara. Bukan tidak mungkin akan ada turis yang berminat ke Indonesia untuk sekedar membuktikan keahlian pawang hujan. Sungguh sebuah sentuhan tim kreatif yang sangat jenius.

[1] http://voicecream.jp/en/see/murou-ryuketsu-jinja/

[2] https://fpcj.jp/en/useful-en/wjn-en/p=45296/

[3] https://www.journals.uchicago.edu/doi/10.1086/203572

[4] https://www.merdeka.com/jateng/niat-shalat-istisqa-dan-tata-caranya-amalan-meminta-hujan-kln.html

[5] https://www.jawapos.com/ekonomi/12/10/2018/jokowi-ekonomi-dunia-dan-analogi-game-of-thrones/

[6] https://www.liputan6.com/global/read/3635160/stuntman-jokowi-di-pembukaan-asian-games-2018-buka-suara-ini-katanya

"Kak, Bagaimana cara (kamu) membuat aplikasi mobile?"

Untuk menjawab pertanyaan ini saya akan menulisnya menjadi beberapa bagian. Artikel kali ini merupakan bagian pertama dan akan membahas, langkah langkah awal yang saya lakukan saat diminta mengerjakan aplikasi.

Berikut adalah daftar topik yang akan saya bahas di rangkaian artikel:

Pre Development: Analysis, Plan, and Design (artikel kali ini)

Basic Git and Git Flow (coming soon)

Flutter State Management and Routing using GetX (coming soon)

Flutter Unit Testing and UI Testing (coming soon)

Architecting (Flutter) Mobile App using clean arch and deferred module (Coming Soon)

QA phase and results (coming soon)

App Deployment (coming soon)

((!!)) Saya akan membutuhkan waktu berminggu minggu bahkan mungkin berbulan bulan untuk menyelesaikan semua tulisannya. Selain itu, mungkin topik diatas tidak akan saya publish secara berurutan. Intinya sih doain aja saya rajin nulisnya 😉

Software Development Life Cycle (SDLC)

Software Development Lifecycle adalah rangkaian langkah yang mendefinisikan status pengembangan sebuah software. SDLC seringkali dimanfaatkan untuk mempermudah kita mengelola suatu projek pengembangan aplikasi. Dengan pengelolanan yang baik, diharapkan produk yang dihasilkan memiliki kualitas yang tinggi. SDLC umumnya terdiri dari 6 fase yaitu Analysis, Planning, Design, Development, Testing dan Deployment.

Image from: https://codecoda.com/en/blog/entry/software-development-lifecycle-management

Jadi seperti yang bisa kamu lihat, koding atau development merupakan fase ke-empat. Jika 3 langkah sebelumnya dilakukan dengan buruk, maka besar kemungkinan kita akan menghabiskan banyak waktu dan mungkin uang pada fase development. Beberapa hal buruk yang sering ditemui seperti fitur berganti atau bertambah ditengah masa koding, refactor yang berulang kali, dll.

Terdapat banyak metodologi mengenai bagaimana SDLC diterapkan, apa input dan output setiap fase, dst. Dua contoh metodologi terkenal adalah Waterfall dan Agile. Apa yang dipilih dan bagaimana diterapkannya dapat berbeda beda disetiap perusahaan.

Tahap 1: Requirement Analysis

Langkah paling pertama yang harus kita lakukan adalah melakukan analisis terhadap kebutuhan aplikasi. Sebaiknya tahap ini mengeluarkan sebuah dokumen yang disebut dengan Software Requirement Specification(SRS). Seringkali sebagai programmer kita memang diekspektasikan langsung mulai koding, dengan asumsi tahap ini telah dilakukan oleh orang lain, seperti oleh product owner dan product manager. Sehingga, peran programmer disini adalah memastikan kelengkapan dari SRS yang telah dibuat.

Isi konten dari SRS mungkin akan berbeda - beda di setiap tugas/projek pengembangan aplikasi. Misal, perlu dituliskan target platform aplikasi dan minimal spesifikasi perangkat. Yang penting diingat adalah, sebaiknnya SRS ini berbentuk sebuah dokumen. Sehingga dokumen tersebut bisa dirujuk sewaktu - waktu dan menjadi pembatas scope pekerjaan.

Saya pribadi seringkali hanya mencari 3 hal berikut didalam sebuah SRS pengembangan aplikasi mobile:

Mock up Design versi high-fidelity dari aplikasi yang akan dibuat.

Daftar fitur yang kemudian didetailkan menjadi sebuah ataupun beberapa Acceptance Criteria (AC).

Severity / Urgency level dari tiap fitur

Ya, benar, ketiga hal diatas bisa diwakili hanya dari sebuah file mock up yang well designed (lengkap dengan panah navigasi, diurutkan berdasarkan prioritas, dll). Oleh karena itu untuk pengembangan aplikasi yang belum terlalu kompleks dan dikerjakan oleh tim yg kecil dokumen SRS ini seringkali tidak dibuat. Source of truth yang dirujuk bersama adalah file mock up.

Mockup Aplikasi Pikobar (Source)

Tahap 2: Planning

Langkah kedua adalah perencanaan. Output dari fase ini juga bisa sangat beragam sesuai kebutuhan. Beberapa hal yang sering ditemukan antara lain dokumen terkait Risk & Conflict Management, Budget Management, Time Management, Test and Release Management, dll. Pada tahap kedua ini perlu dibahas beberapa hal terkait bisnis dan hal terkait teknikal. Oleh karena itu di fase ini terjadi kolaborasi oleh keseluruhan anggota yang ada di tim. Untuk tim kecil, disinilah terjadi diskusi antara orang product dan developer.

Menurut saya, sebagai developer, output yang paling penting dari tahap ini ialah Task list dan Gantt Chart. Task list (daftar tugas) sangat penting dibuat dengan baik, ia perlu dibuat dengan spesifik dan telah dilengkapi AC. Task list yang baik akan sangat membantu untuk memantau status pekerjaan dan mempermudah bekerja secara tim. Gantt Chart ialah tabel yang berisi time scheduling terkait keseluruhan proses. Tabel ini menemukan ekspektasi durasi kerja dari semua stakeholder, sehingga bisa membantu memastikan apakah suatu task feasible atau tidak. https://clickup.com/blog/scrum-board/

https://instagantt.com/gantt-chart-experts/top-8-best-online-gantt-chart-tools-in-2021

Tahap 3: Design

Pada tahap ini, orang product (seperti product owner, product manager dan product designer) sudah tidak terlalu terlibat. Mungkin sekilas terlihat membingungkan, tahap Design tapi product design-er tidak terlibat. Saya ingin mengingatkan kembali tahapan yang kita bahas adalah Software Development lifecycle sehingga tahap design disini adalah merancang software. Tentu bisa diperdebatkan apakah mendesign tampilan merupakan bagian dari merancang software, namun saya merasa product design lebih berupa sebuah user requirement.

Output yang diharapkan pada fase ini adalah sebuah Software Design Document(SDD). Beberapa konten yang sering ditemukan pada dokumen ini:

Data Structure

Architecture Design

Interface Design

Procedure Design (seperti flowchart, activity diagram, interaction diagram, dll)

Pada dasarnya tahap design ini adalah proses pendetailan hal teknikal yang sudah dibahas di tahap sebelumnya. Misal, jika aplikasi yang ingin dibuat perlu menggunakan sebuah back end dan terhubung ke sistem Google Map maka pada tahap ini perlu diperjelas bagaimana cara kita ingin melakukannya.

Sesungguhnya semakin detail output dari tahap ini maka akan semakin mempermudah ketika kita akan melakukan koding. Walaupun demikian, perlu diingat, tahap design ini adalah bagian dari perencanaan. Sehingga bisa saja ketika sudah melakukan implementasi diperlukan ada penyesuaian rancangan. Jika saya harus memilih output apa yang paling penting maka jawaban saya adalah Interface Design, yang bisa berupa sebuah API Documentation.

Design Thinking

Sedikit trivia tambahan, sejauh yang saya tau, product designer menerapkan lifecycle sendiri yang disebut Design Thinking Process. Saya tidak mengetahui prosesnya secara detail namun, bisa kita lihat di diagram dibawah, tahap terakhir disebut Implement. Menurut saya, inilah fase dimulai SDLC yang telah kita bahas diatas.

https://www.stephaniebaseman.com/design-thinking-process

Akhir kata

Current State of the Art

Flutter official website has a listing of all current available state management options. As on 1 Aug 2021, the following list are those that listed on the website.

I marked GetIt since it’s actually not a state management by it’s own. It’s a dependency injection library, but the community behind it develop a set of tools to make it a state management (get_it_mixin (45,130,81%) and get_it_hooks (6,100,33%)). There’s also two additional lib that not mentioned on the official page (Stacked and flutter_hooks). Those two are relatively new compared to others (since pretty much everything about flutter is new) but has high popularity.

What is Pub Point

Pub point is a curation point given by flutter package manager (pub.dev). Basically this point indicate how far a given library adhere to dart/flutter best practices.

Provider Package Meta Scores

Selection Criteria

I concluded several criteria that need to be fulfilled by a good state management library.

Well Known (Popular)

There's should be a lot of people using it.

Mature

Has rich ecosystem, which mean, resources about the library should be easily available. Resources are, but not limited to, documentation, best practices and common issue/problem solutions.

Rigid

Allow for engineers to write consistent code, so an engineer can come and easily maintain other's codebase.

Easy to Use

Easy in inter-component communication. In a complex app, a component tend to need to talk to other component. So it's very useful if the state manager give an easy way to do it.

Easy to test. A component that implement the state management need to have a good separation of concern.

Easy to learn. Has leaner learning curve.

Well Maintained:

High test coverage rate and actively developed.

First Filter: Popularity

This first filter can give us a quick glance over the easiness of usage and the availability of resources. Since both are our criteria in choosing, the first filter is a no brainer to use. Furthermore when it’s not popular, there’s a high chance that new engineers need more time to learn it.

Luckily, we have a definitive data to rank our list. Pub.dev give us popularity score and number of likes. So, let’s drop those that has less than 90% popularity and has less than 100 likes.

As you can see, we drop 6 package from the list. We also drop setState and InheritedWidget from the list, since it’s the default implementation of state management in flutter. It’s very simple but easily increase complexity in building a bigger app. Most of the other packages try to fix the problem and build on top of it.

Now we have 9 left to go.

Second Filter: Maturity

The second filter is a bit hard to implement. After all, parameter to define “maturity” is kinda vague. But let’s make our own threshold of matureness to use as filter.

Pub point should be higher than 100

Version number should be on major version at least “1.0.0”

Github’s Closed Issue should be more than 100

Stackoverflow questions should be more than 100

Total resource (Github + Stackoverflow) should be more than 500

The current list doesn’t have 2 parameter defined above, so we need to find it out.

So let’s see which state management fulfill our threshold.

As you can see, “flutter_redux” is dropped. It’s not satisfied the criteria of “major version”. Not on major version can be inferred as, the creator of the package marked it is as not stable. There could be potentially breaking API changes in near future or an implementation change. When it happens we got no option but to refactor our code base, which lead to unnecessary work load.

But, it’s actually seems unfair. Since flutter_redux is only a set of tool on top redux . The base package is actually satisfy our threshold so far. It’s on v5.0.0, has pub point ≥ 100, has likes ≥ 100 and has popularity ≥ 90%.

So, if we use the base package it should be safe. But, let’s go a little deeper. The base package is a Dart package, so it means this lib can be used outside flutter (which is a plus). Redux package also claims it’s a rich ecosystem, in which it has several child packages:

As i inspect each of those packages, i found none of them are stables. In fact, none of them are even popular. Which i can assume it’s pretty hard to find “best practices” around it. Redux might be super popular on Javascript community. We could easily find help about redux for web development issue, but i don’t think it stays true for flutter’s issue (you can see the total resource count, it barely pass 500, it’s 517).

Redux package promises big things, but as a saying goes “a chain is as strong as its weakest link”. It’s hard for me to let this package claim “maturity”.

Fun fact: On JS community, specifically React community, redux is also losing popularity due to easier or simpler API from React.Context or Mobx.

But, Just in case, let’s keep Redux in mind, let’s say it’s a seed selection. Since we might go away with only using the base package. Also, it’s might be significantly excel on another filter. So, currently we have 4+1 options left.

Third Filter: Rigid

Our code should be very consistent across all code base. Again, this is very vague. What is the parameters to say a code is consistent, and how consistent we want it to be. Honestly, i can’t find a measurable metric for it. The consistency of a code is all based on a person valuation. In my opinion every and each public available solutions should be custom tailored to our needs. So to make a codebase consistent we should define our own conventions and stick on it during code reviews.

So, sadly on this filter none of the options are dropped. It stays 4+1 options.

Fourth Filter: Easy to Use

We had already define, when is a state management can be called as easy to use in the previous section. Those criteria are:

Each components can talk to each other easily.

Each components should be easy to test. It can be achieved when it separates business logic from views. Also separate big business logic to smaller ones.

We spent little time in learning it.

Since the fourth filter is span across multiple complex criteria, I think to objectively measure it, we need to use a ranking system. A winner on a criteria will get 2 point, second place will get 1, and the rest get 0 point. So, Let’s start visiting those criteria one by one.

Inter Component Communication

Let’s say we have component tree like the following diagram,

In basic composition pattern, when component A needs something from component D it needs to follow a chain of command through E→G→F→D

This approach is easily get very complex when we scale up the system, like a tree with 10 layers deep. So, to solve this problem, state management’s tools introduce a separate class that hold an object which exposed to all components.

Basically, all state management listed above allows this to happen. The differences located on how big is the “root state” allowed and how to reduce unnecessary “render”.

Provider and BLoC is very similar, their pattern best practices only allow state to be stored as high as they needed. In example, on previous graph, states that used by A and B is stored in E but states that used by A and D is stored in root (G). This ensure the render only happen on those component that needed it. But, the problem arise when D suddenly need state that stored in E. We will need a refactor to move it to G.

Redux and Mobx is very similar, it allows all state to be stored in a single state Store that located at root. Each state in store is implemented as an observable and only listened by component that needs it. By doing it that way, it can reduce the unnecessary render occurred. But, this approach easily bloated the root state since it stores everything. You can implement a sub store, like a store located in E to be used by A and B, but then they will lose their advantages over Provider and BLoC. So, sub store is basically discouraged, you can see both redux and mobx has no implementation for MultiStore component like MultiProvider in provider and MultiBlocProvider in BLoC.

A bloated root state is bad due to, not only the file become very big very fast but also the store hogs a lot of memory even when the state is not actively used. Also, as far as i read, i can’t find any solution to remove states that being unused in either Redux and Mobx. It’s something that won’t happen in Provider, since when a branch is disposes it will remove all state included. So, basically choosing either Provider or Redux is down to personal preferences. Wether you prefer simplicity in Redux or a bit more complex but has better memory allocation in Provider.

Meanwhile, Getx has different implementation altogether. It tries to combine provider style and redux style. It has a singleton object to store all active states, but that singleton is managed by a dependency injector. That dependency injector will create and store a state when it’s needed and remove it when it’s not needed anymore. Theres a writer comment in flutter_redux readme, it says

Singletons can be problematic for testing, and Flutter doesn’t have a great Dependency Injection library (such as Dagger2) just yet, so I’d prefer to avoid those. … Therefore, redux & redux_flutter was born for more complex stories like this one.

I can infer, if there is a great dependency injection, the creator of flutter redux won’t create it. So, for the first criteria in easiness of usage, i think, won by Getx (+2 point).

There is a state management that also build on top dependency injection GetIt. But, it got removed in the first round due to very low popularity. Personally, i think it got potential.

Business logic separation

Just like in the previous criteria, all state management also has their own level of separation. They differ in their way in defining unidirectional data flow. You can try to map each of them based on similarity to a more common design pattern like MVVM or MVI.

Provider, Mobx and Getx are similar to MVVM. BLoC and Redux are similar to MVI.

In this criteria, i think there’s no winner since it boils down to preference again.

Easy to learn

Finally, the easiest criteria in easiness of usage, easy to learn. I think there’s only one parameter for it. To be easy to learn, it have to introduced least new things. Both, MVVM and MVI is already pretty common but the latter is a bit new. MVI’s style packages like redux and bloc, introduce new concepts like an action and reducer. Even though Mobx also has actions but it already simplified by using code generator so it looks like any other view model.

So, for this criteria, i think the winner are those with MVVM’s style (+2 Point), Provider, Mobx and Getx. Actually, google themself also promote Provider (Google I/O 2019) over BLoC (Google I/O 2018) because of the simplicity, you can watch the show here.

The fourth filter result

We have inspect all criteria in the fourth filter. The result are as the following:

Getx won twice (4 point),

Provider and Mobx won once (2 point) and

BLoC and Redux never won (0 point).

I guess it’s very clear that we will drop BLoC and Redux. But, i think we need to add one more important criteria.

Which has bigger ecosystem

Big ecosystem means that a given package has many default tools baked or integrated in. A big ecosystem can help us to reduce the time needed to mix and match tools. We don’t need to reinvent the wheel and focused on delivering products. So, let’s see which one of them has the biggest ecosystem. The answer is Getx, but also unsurprisingly Redux. Getx shipped with Dependency Injection, Automated Logging, Http Client, Route Management, and more. The same thing with Redux, as mentioned before, Redux has multiple sub packages, even though none of it is popular. The second place goes to provider and BLoC since it gives us more option in implementation compared to one on the last place. Finally, on the last place Mobx, it offers only state management and gives no additional tools.

So, these are the final verdict

Suddenly, Redux has comeback to the race.

Fifth Filter: Well maintained

No matter how good a package currently is, we can’t use something that got no further maintenance. We need a well maintained package. So, as always let’s define the criteria of well maintained.

Code Coverage

Last time a commit merged to master

Open Pull Request count

Just like previous filter, we will implement ranking system. A winner on a criteria will get 2 point, second place will get 1, and the rest get 0 point.

So, with above data, here are the verdicts

Getx 4 point (2+2+0)

BLoC 4 point (1+1+2)

MobX 0 point (0+0+0)

Provider 1 point (0+0+1)

Redux 0 point (0+0+0)

Lets add with the previous filter point,

Getx 10 point (4+6)

BLoC 5 point (4+1)

MobX 2 point (0+2)

Provider 4 point (1+3)

Redux 2 point (0+2)

By now we can see that the winner state management, that allowed to claim the best possible right now, is Getx. But, it’s a bit concerning when I look at the code coverage, it’s the lowest by far from the others. It makes me wonder, what happen to Getx. So i tried to see the result more closely.

After seeing the image above, i can see that the problem is the get_connect module has 0 coverage also several other modules has low coverage. But, let’s pick the coverage of the core modules like, get_core (100%), get_instance(77%), get_state_manager(51%,33%). The coverage get over 50%, not too bad.

Basically, this result means we need to cancel a winner status from Getx. It’s the win on big ecosystem criteria. So, lets subtract 2 point from the end result (10-2). It got 8 points left, it still won the race. We can safely say it has more pros than cons.

Conclusions

The final result, current best state management is Getx 🎉🎉🎉. Sure, it is not perfect and could be beaten by other state management in the future, but currently it’s the best.

Intro

Saya yakin pembaca artikel ini kemungkinan besar mengenal saya dan pasti mengetahui apa itu Bukalapak. Tapi rasanya tidak ada salahnya, kalau saya memulai artikel ini dengan sedikit perkenalan (lagi). Siapa saya dan apa itu Bukalapak.

Per hari ini, saya merupakan seorang pria berusia 25 tahun dan berprofesi sebagai mobile application developer (app dev). Saya mengawali perjalanan sebagai software developer semenjak masih duduk di bangku kuliah. Dimulai sebagai intern pada masa magang dan berlanjut freelance pada masa diluar magang. Selain bekerja, yang tentu saja merupakan sampingan, saya dapat dibilang cukup berprestasi sebagai mahasiswa. Saya terbiasa mengembangkan produk IT dan mengikuti beberapa perlombaan. Setelah lulus, pekerjaan full time pertama saya adalah sebagai seorang backend developer(BE dev). Saya mulai bekerja di Bukalapak sebagai seorang app dev terhitung sejak tanggal 2 April 2018.

Bukalapak adalah sebuah perusahaan IT yang menyediakan platform jual beli online (online marketplace). Saya yakin orang indonesia tidak asing dengan nama Bukapalak. Terlebih, karena belakangan ini sedang ramai diperbincangkan. Karena berhasil menjadi perusahaan rintisan (startup) dengan status Unicorn yang pertama melakukan penawaran umum publik (IPO) di bursa efek Indonesia. Saya sendiri bekerja di kantor RnD Bukalapak yang ada di Bandung, Jawa Barat.

Hiring Process

Seperti di semua perusahaan lainnya perjalanan dimulai dari hiring process. Saat itu saya berstatus sebagai BE dev di sebuah perusahaan software house yang ada di Bandung. Beberapa bulan berlalu, saya menyadari bahwa saya tidak merasa nyaman bekerja sabagai BE dev. Saya menyadari lebih senang mengerjakan aplikasi mobile. Mungkin karena sebelumnya, selama masih freelance, bisa dibilang saya lebih sering menerima pekerjaan app dev. Produk yang saya kerjakan pun seringkali mobile app. Sehingga saya memutuskan untuk mencari kesempatan baru sebagai mobile dev.

Saya mencoba mengirim lamaran ke beberapa perusahaan dengan Bukalapak sebagai pilihan pertama. Bagi saya, Bukalapak adalah perusahaan yang paling keren saat itu. Paling inovatif dan inspiring. Pucuk dicinta ulam pun tiba. Saya tidak menyangka mendapatkan balasan dari Bukalapak sangat cepat. Hari ini saya mengirim lamaran, 2 hari kemudian telah ada balasan. Kurang lebih hanya 2 minggu semua proses telah selesai (online test, HR interview, user interview, coding on-site, head interview, offering).

Saya sangat salut dengan recruiter yang menangani saya. Beliau, ramah, cekatan, aktif, dan sangat profesional. Yang paling keren ialah, ia membuat “saya merasa dibutuhkan”. Terimakasih mba Ibel (Belinda Rahmadara).

Sebenarnya, selain Bukalapak saya mendapatkan balasan email untuk online test dan atau interview di tempat lain. Namun karena saya sudah menyelesaikan proses di Bukalapak dan memang Bukalapak adalah pilihan utama, saya tidak meneruskan proses di tempat lain.

Interview Process

Interview proses memang adalah bagian dari hiring process. Namun, ada sedikit kisah menarik di step ini yang menurut saya sayang jika tidak diceritakan.

Setelah menyelesaikan online test saya dipanggil untuk melaksanakan user interview di kantor Bukalapak yang berlokasi di Jakarta Selatan. Beberapa hari sebelumnya, recruiter telah membriefing kurang lebih seperti apa tahapan interview ini. Hal ini ditujukan agar saya melakukan persiapan.

Saya berangkat ke Jakarta dengan persiapan seadanya. Hanya menyiapkan IDE dan membaca sekilas dasar pemrograman android. Saya berasumsi bahwa pengetahuan saya sudah cukup dan hanya butuh sedikit “refresh”. Saya besar kepala karena merasa “jago”. Tapi ini ternyata adalah kesalahan besar.

Saya di interview oleh 2 senior developer, mas Stephanus Jeffry dan mas Fikrul Arif. Ketika diinterview oleh mereka, saya kesulitan menjawab banyak pertanyaan. Kondisi yang buruk bagi calon karyawan. Hal ini bertambah parah, ketika sesi coding onsite. Saya gagal menyelesaikan tugas. Karena merasa buruk di fase tanya jawab, saya ingin mendapat poin lebih di coding on-site. Saya mencoba menerapkan semua yg saya ketahui. Namun ternyata keputusan itu malah memperburuk keadaan. Biar bagaimanapun, saya sehari hari bekerja sebagai BE Dev. Sudah berbulan bulan tidak membuat aplikasi mobile. Mendadak harus coding dengan semua best practices, jelas saya kewalahan. Waktu habis terbuang untuk Googling.

Poin di tanya jawab rasanya pas pasan. Sesi coding pun tidak selesai. Rasanya benar-benar hopeless. Tapi saya juga merasa kesal ke diri sendiri. Saya yakin bisa menyelesaikan tugas coding nya. Tugasnya tidaklah begitu sulit. Tapi kenapa tidak selesai. Semua ini karena kurang persiapan. Andai saja saya latihan dulu, pemanasan, persiapan dulu.

Masih di Jakarta, di penginapan saya menunggu kabar dari recruiter. Karena jika hari itu saya lolos. Besoknya saya perlu melanjutkan interview dengan head. Walaupun sudah hopeless, tidak ada salahnya kan berharap. Sore harinya recruiter menghubungi, rupanya saya diberikan kesempatan kedua. Saya diminta untuk mengulang sesi onsite coding. Jelas saya tidak menyia-nyiakan kesempatan. Malamnya saya berlatih terlebih dahulu.

Keesokan harinya saya datang lagi ke kantor. kali ini ditangani oleh mas Jeffry dan mas Andika Pratama. Diberikan tugas yg berbeda dengan jumlah waktu yang sama. Tapi kali ini saya lebih persiapan. Saya tidak peduli dengan best practices. Setidaknya tugas kali itu harus bisa saya selesaikan. Dan saya berhasil menyelesaikannya. Malamnya saya mendapatkan kabar bahwa saya lolos tahap interview user dan perlu melanjutkan ke tahap interview head. Tapi karena saya hanya cuti 2 hari, interview berikutnya dijadwalkan Minggu depan.

Sampai akhirnya saya menyelesaikan semua proses dan mendapatkan offering. Saya masih belum mengerti mengapa saya diberikan kesempatan kedua. Yang pasti saya sangat bersyukur.

First day(s) at office

Sejak hari pertama saya langsung merasakan vibe yang berbeda. “Oh seperti ini rasanya kerja di unicorn” pikir saya saat itu. Pegawai berpakaian kasual, muka penuh semangat, kantor yang nyaman. Disediakan makan pagi, siang dan malam. Ada ruangan rekreasi. Ada ruangan gym. Mungkin memang tidak sebagus kantor Google yang ada di youtube. Tapi jauh lebih nyaman dari sebelumnya.

Sebagai karyawan baru saya perlu mengikuti proses onboarding. Salah satunya adalah dimana saya diperkenalkan ke seluruh tim app (android) dev. Mayoritas karyawan yang hadir masih muda, saya yakin tidak jauh umurnya dari saya. Rasanya sangat rileks karena tau “jokes” kita pasti tidak jauh. Saya memperkenalkan diri, pekerjaan sebelumnya dan hobi. Yang kemudian saya mengetahui, di Bukalapak punya semacam “ekskul” atau “club” untuk karyawan menyalurkan hobi. Tentu saya bergabung dengan salah satunya.

Onboarding berlanjut, seperti mendengar sambutan dari CEO, mas Ahmad Zaky, dibagikan perlengkapan kantor lalu foto bersama. Setelah onboarding semua karyawan baru diarahkan untuk menemui head masing-masing untuk mendapatkan informasi penempatan tim / squad. Rupanya saya ditempatkan ke sebuah squad baru di Bandung. Namun sebelum saya kembali ke Bandung saya perlu “belajar” seminggu di kantor Jakarta.

Setelah menyelesaikan kursus kilat di Jakarta. Saya kembali ke Bandung. Di berikan alamat kantor tempat saya akan bekerja. Sebelumnya, saya tidak mengetahui bahwa Bukalapak memiliki kantor di Bandung. Rasa penasaran ingin melihat kantornya yang di Bandung cukup membuat saya sangat bersemangat untuk berangkat bekerja. Saya mengikuti Gmaps, memasuki sebuah perumahan dan sampai ke alamat yang tertulis. Sebuah rumah.

Melihat sebuah rumah di lokasi alamat kantor membuat saya agak bingung “Ini saya ga salah alamat? Kok sepi”. Untungnya ketika saya di Jakarta saya mengetahui bahwa ada seorang senior kampus yang juga bekerja di Bukalapak Bandung, kak Primawan Satrio. Saya menghubungi dia lalu mendapatkan konfirmasi bahwa benar. Rumah yang saya lihat adalah kantor “sementara” Bukalapak di Bandung.

First Squad, First Product

Hari pertama saya di kantor Bandung. Saya datang sebagai “motor ketiga yang parkir”. Sangking bersemangat nya saya datang ketika kantor baru dibuka dan baru ada 2 orang lain di dalam. Bahkan anggota squad saya pun belum datang. Awalnya saya agak kecewa tapi setelah masuk, rupanya rumah kecil itu not too bad. Peralatan lengkap, bahkan ruang rekreasi dengan karpet rumput ada. Yah mungkin tidak ada gym, tapi yasudah lah toh saya tidak menggunakan fasilitas itu.

Sambil menunggu tim saya datang, saya mencoba mempelajari lebih lanjut mengenai code base Bukalapak. Jika sebelum masuk Bukalapak saya merasa “Jago” setelah masuk saya merasa menjadi orang yang paling “Bodoh”. Banyak hal yang baru pertama kali saya lihat dan perlu saya pelajari. Tidak lama anggota squad pertama saya pun datang. Technically sebenarnya Squad pertama saya ialah yang di Jakarta. Namun disitu saya belum mengerjakan apa apa. Pekerjaan pertama saya diberikan saat saya telah bergabung di Squad yang di Bandung.

Harapan saya untuk bekerja di perusahaan yang inovatif langsung terpenuhi di Squad pertama. Saya rupanya ditempatkan ke tim yang akan mengembangkan produk baru. Produk yang kita riset dari awal, kembangkan, publikasi dan pantau metricnya. Sangat menyenangkan saat hari dimana kami perlu lembur karena persiapan rilis. Atau ketika mendengarkan insight dan membahas hasil user research. Atau mempelajari segi bisnis dari produk yang kita buat seperti menghitung impact GMV, CAC, dsb.

Produk pertama yang tim kami luncurkan bernama “BukaNonton”. Sebuah produk yang memungkinkan pengguna Bukalapak untuk menikmati konten film lokal dan internasional secara gratis di lokasi tertentu. Tentu saja tidak semua produk menghasilkan traffic yang bagus, produk pertama kami ini akhirnya di takedown.

Setelah produk itu tim melanjutkan eksplorasi ke produk produk lain. Ada yg akhirnya di take down ada yang masih bertahan hingga sekarang, seperti sistem pembayaran pajak. Menyedihkan memang ketika harus melihat kerjaan berbulan bulan harus dihapus. Tapi kecepatan inovasi seperti ini ditambah keberanian mengambil keputusan besar adalah nilai utama kenapa Bukalapak masih eksis hingga sekarang. Keberhasilan Bukalapak masuk ke market O2O (mitra) saat yang lain belum terpikirkan dan menjadi market leader adalah salah satu buktinya.

Daily life as Engineer

Bukalapak menerapkan jam kerja dan lokasi kerja yang fleksibel. Itu berarti karyawan bebas datang ke kantor jam berapa dan bebas apakah mau datang ke kantor atau tidak. Tapi seperti hampir semua kebebasan, kebijakan ini pun memiliki syarat dan ketentuan yang berlaku. Namun sepertinya terlalu panjang kalau mau saya jelaskan, diluar kemungkinan hal itu merupakan informasi yang konfidensial.

Karena kebijakan ini, tidak jarang saya melihat orang yang datang sangat pagi agar bisa pulang lebih cepat maupun datang agak siang lalu pulang lebih malam. Tidak jarang pula saya melihat orang yang datang waktu normal tetap berada di kantor sampai agak malam. Entah karena mengejar deadline, solidaritas antar karyawan atau memang sekedar bersantai di kantor yang nyaman. Kalau saya pribadi, termasuk golongan yang ikut main PS setelah jam kantor, hal ini membuat saya cukup jago dalam bermain game FIFA.

Karyawan yang bermarkas di Bandung pada saat itu belum banyak. Tim saya pun awalnya hanya berjumlah 2 orang. Yap, hanya saya dan seorang Product manager, mas Moreno Duvadilon. Karyawan app dev yang bermarkas di Bandung pun baru 4 orang, Esa, Arifin, Fachri dan saya. Karena jumlah karyawan yang masih sedikit ini membuat hampir semua karyawan sangat akrab. Karyawan pria rutin bermain futsal (saya tidak pernah ikut) dan badminton bersama sedangkan yang wanita rutin mengikuti kelas Yoga. Ya, ini salah satu kegiatan club yang di “subsidi” kantor.

Saya sudah sempat sebut bahwa makanan disediakan oleh kantor? Di Bandung pun sama. Mungkin ini salah satu penyebab kenapa orang sangat betah di kantor. Sangat sedikit alasan untuk keluar setelah mencapai kantor. Saya tidak tau apakah semakin lama karyawan berada di kantor berkorelasi dengan meningkatknya produktivitas bekerja. Tapi yang pasti churn rate karyawan sangat rendah. Banyak orang baru bergabung namun sedikit yang keluar.

Mungkin teman teman ada yang bertanya.

Kalau jam kerja dan waktu kerja fleksibel. Bagaimana caranya memastikan pekerjaan selesai?

Di Bukalapak dan mungkin hampir semua startup, diterapkan mekanisme bekerja yang di sebut “Scrum”. Secara simpel ini berarti sebuah tugas besar dipecah menjadi pekerjaan yang lebih kecil yang akan selesai dalam 1 sprint, biasanya 2 minggu. Jadi kurang lebih, “anda bebas bagaimana cara bekerjanya selama pekerjaan anda selesai dalam 2 minggu”. Untuk detail terkait scrum silahkan google sendiri lah ya 😬.

New office, new spirit

Tidak lama berada di kantor sementara, Bukalapak meresmikan kantor baru di Bandung. Berlokasi di jalan Ir. H. Juanda, Dago. Kantornya merupakan upgrade yang jauh dari kantor sementara kami. Bahkan bisa dibilang sama lengkapnya dengan kantor yang ada di Jakarta. Karyawan saat itu sudah mencapai seratus lebih orang. Konsekuensinya tentu kini semua karyawan tidak bisa lagi saling kenal. Tapi karyawan antar tim yang tidak bersinggungan pekerjaan masih bisa saling berinteraksi di acara club.

Ada sebuah hal lucu yang terjadi, ketika awal menempati kantor baru. Kami semua melepaskan alas kaki dan kesana kemari bertelanjang kaki. Beberapa orang ada yang membeli sendal khusus untuk dipake di Kantor. Jadi ala ala rumah di Jepang lah, ketika masuk rumah lepas sepatu diganti sendal dalam rumah. Hal ini terjadi karena hampir semua ruangan lantainya dilapisi karpet dan masih baru. Kami semua “sayang” kalau jadi merusak karpet yang nyaman ini. Karena kebiasaan kami itu kantor akhirnya menyediakan rak sepatu di banyak tempat.

Kebiasaan unik ini membuat kami gampang mengetahui apakah muka baru yang dilihat di kantor adalah karyawan dari Jakarta ataukah karyawan baru. Mereka yang dari Jakarta tidak mengetahui aturan tidak tertulis ini dan kemana mana menggunakan sepatu ataupun sendal mereka. Kami lalu melihat sinis mereka, dalam hati berkata “woy, liat dong, peka, itu disini pada lepas sepatu” 😂🙏🏻.

Sharing session, talks and more talks

Sebagai perusahaan berbasis IT pengetahuan sangat berharga disini. Semua orang haus akan ilmu. Namun tidak mungkin semua orang memiliki waktu untuk belajar hal baru setiap saat. Itulah alasan diadakan banyak sekali sesi sharing internal. Engineer, bahkan non engineer, bergantian mengisi talks membahas berbagai macam topik. Malah terkadang sampai bingung karena terlalu banyak talks yang diadakan. Sehingga saya pribadi hanya mengikuti talks yang topiknya menarik bagi saya.

Sebenarnya tidak hanya talks internal yang ada. Ada juga talks kami yang dibuka untuk publik bahkan rekamannya di upload ke platform YouTube. Selain itu, sering juga auditorium kantor kami dipinjam publik untuk melaksanakan talks. Baik oleh akademisi, dari kampus, hingga komunitas tertentu. Sehingga selama bekerja di Bukalapak benar benar membanjiri saya dengan banyak sekali ilmu.

Belum lagi Wiki internal yang cukup lengkap. Jika ingin mempelajari suatu produk yang ada, cukup mencarinya dan semuanya ada. Saya sempat sekali mencoba nekat melakukan review kepada produk yang saya sama sekali tidak memiliki pengetahuan. Saya melihat data terkait, menulis analisis lalu mempublikasikannya di sebuah thread (semacam grup) pembicaraan yang sedang rame. Diluar ekspektasi saya, mungkin akan ditegur karena asal komentar. Tulisan saya diapresiasi cukup banyak pihak, bahkan dihadiahi voucher belanja 😎. Walaupun pada akhirnya saya tau bahwa data yang saya lihat sudah tidak relevan karena gudang datanya telah dipindah secara bertahap 😂 .

Internal hackathon, Hack a Fun

Banyaknya sesi talks tidak cukup memenuhi rasa haus akan ilmu di Bukalapak. Rasa haus ini menjalur hingga haus akan ide. Setidaknya setahun sekali Bukalapak mengadakan event internal hackathon. Dengan tujuan memunculkan ide baru yang “mungkin” berpotensi. Mayoritas karyawan diberikan kelonggaran untuk tidak melakukan development salama durasi hackthon, namun tetap menjaga metric yang kritikal aman. Jadi kalau ada bug atau sejenisnya, ya tetap harus diselesaikan.

Setiap hackthon mengusul tema dan kategori yang berbeda beda. Misal pernah diadakan “Testathon” yaitu perlombaan mencari bug di dalam aplikasi Bukalapak tapi tidak boleh dari produk yang dia kerjakan. Testathon merupakan salah satu kategori yang pernah dimenangkan oleh tim dari kantor Bandung. Sebuah kebanggan tersendiri bagi kami yang berjumlah sedikit dibandingkan karyawan dari kantor Jakarta.

Saya berulang kali menyebutkan kantor Bandung dan Jakarta seolah olah ada perbedaan kelas atau semacamnya diatara kami. Sebenarnya tidak ada. Secara pekerjaan tidak ada perbedaan dan tidak jarang kami saling berkolaborasi. Secara fasilitas pun tidak ada. Jadi hanya benar benar berbeda lokasi saja dan berbeda rasa keakraban antar karyawan.

Selain lomba lomba yang produktif, bagi karyawan yang telah “kalah” atau sedang menanti jadwal pertandingan, setiap hackthon juga hadir dengan berbagai macam games. Pernah ada perlombaan Counter Strike, Dota dan berbagai mini games lainnya. Saya sendiri belum pernah menang dalam kategori apapun. Jadi yah.. selalu jadi karyawan pemeriah.

Being an interviewer

Beberapa bulan setelah menempati kantor baru, saya diberikan kesempatan menjadi seorang interviewer. Saya memiliki kesempatan untuk “menguji” calon karyawan yang ingin masuk ke Bukalapak. Para interviewer di briefing mengenai mekanisme pengujian, seperti apa saja yang perlu ditanya, bagaimana cara bertanya, dsb. Salah satu pesan yang diberikan head, mas Hasanul Hakim, yang sangat saya ingat ialah:

“Jika kamu bimbang ingin meloloskan seorang kandidat atau tidak, maka coba bayangkan apakah kamu mau dia masuk ke squad kamu? Jika ya, maka loloskan, jika tidak maka tolak.”

Sebagai interviewer saya mendapatkan akes ke database hasil interview. Sudah jelas dong.. hal pertama yang saya lakukan adalah mencari nama saya. Apa sih, pesan dan pertimbangan interviewer saat itu sehingga saya diberikan kesempatan kedua. Akhirnya, setelah membaca catatan yang tertera rasa penasaran saya terpenuhi. Kurang lebih isinya tentang mereka melihat potensi saya dan mereka juga bingung kenapa saya tidak bisa menyelesaikan tugas. Sehingga untuk memastikannya saya diberikan percobaan ulang. Kalau mas jeff baca blog ini, Terimakasih ya mas 😉.

Namun ada satu hal yang menarik perhatian saya, saya diberikan level sebagai Junior Lower. Saya mengetahui dan mengakui bahwa level saya adalah junior. Sebagai interviewer pun saya hanya bisa menginterview kandidat yang di prediksi berlevel Junior, maksimal Medior. Tapi, saya tidak menyangka bahwa saya mendapatkan imbuhan Lower, ketika masuk ke Bukalapak. Imbuhan ini kurang lebih berarti saya barerly pass , hampir tidak lolos. Saya tau banyak programmer lain yang lebih awam daripada saya, sehingga mengetahui bahwa level saya saja pas pasan membuat semakin kagum kepada para karyawan lain di Bukalapak. Bagaimana jauhnya pengetahuan para Senior Engineer.

Saya menginterview banyak orang (ga sampe ratusan tapi cukup banyak sampai saya lupa berapa jumlahnya) tapi hanya meloloskan sedikit sekali kandidat. Disini saya sadar akan benarnya berita yang pernah saya baca sebelumnya, mengenai Indonesia kekurangan programmer. Sebenarnya programmer itu banyak tapi yang kualitasnya sesuai dengan yang dibutuhkan oleh perusahaan itu kurang. Sehingga tidak jarang terjadi perdebatan antara interviewer mengenai apakah harus meloloskan suatu kandidat. Bukannya kami tidak memiliki parameter kuantitatif yang objektif, tapi pada akhirnya penilaian yang dilakukan oleh individu pasti akan subjektif. Tidak disangka pesan yang diberikan sebelumnya ternyata sangat membantu di kemudian hari.

Dining, Outing and Conference

Tidak semua kegiatan di Bukalapak adalah terkait bekerja dan belajar. Ada sebuah event yang ditunggu tunggu oleh semua karyawan, yaitu dining atau makan malam dan outing atau wisata bersama. Kedua event ini pun “disubsidi” oleh kantor, dengan tujuan meningkatkan kebersamaan.

Karena dining ini pula saya mulai mengetahui beberapa tempat makan enak yang ada di Bandung. Tim saya bersepakat untuk berpindah tempat setiap event dining. Sebelumnya bisa dibilang saya adalah orang yang kurang pergaulan. Sangat jarang mengeksplorasi kota, 4 tahun berkuliah di Bandung saya seperti tidak tau apa apa tentang Bandung.

Outing atau jalan jalan ini pun sangat menyenangkan. Event ini seperti hackathon hanya sekali setahun. Outing ini diselenggarakan oleh tribe (sejenis divisi di perusahaan lain), sehingga beberapa squad tergabung menjadi satu ketika berwisata. Biasanya dilakukan pemungutan suara kemana outing berikutnya akan dilaksanakan. Secara total saya 2 kali outing, bersama 2 tribe yang berbeda, yaitu tribe society lalu tribe payment. Outing pertama ke Malacca di Malaysia lalu berikutnya ke Bali.

Kamu bisa bayangkan betapa solid nya tim di Bukalapak. Kami menghabiskan sangat banyak waktu di kantor, di kegiatan club, di sharing session dan kini di luar kantor. Tidak heran solidaritas ini tercermin dan menjadi kultur perusahaan “Gotong Royong”. Bantuan tidak hanya datang ketika diminta, para karyawan saling menawarkan bantuan ketika melihat ada yang kesulitan. Tidak ada yang saling menyalahkan jika terjadi sebuah masalah, semua orang fokus menyelesaikan masalah yang terjadi dan apa pelajaran di baliknya.

Ada satu event lagi yang memungkinkan karyawan “jalan jalan” yaitu conference. Sebenarnya ini adalah pemanfaatan dana yang disebut “Individual Development Program”, program pengembangan pengetahuan bagi karyawan. Setiap karyawan memiliki kesempatan untuk mengembangkan dirinya dan dibiayai oleh perusahaan. Nah, kebanyakan karyawan sengaja “menabung” budget ini dan menggunakan dananya sekaligus untuk mengikuti conference di luar negeri, tentu saja seperti biasa harus “nombok” tapi yah lumayan lah. Dengan budget ini saya berkesempatan mengikuti conference di Singapore, jadi kali ini lebih seperti studi tur jaman SMP-SMA. Saya bisa belajar sambil jalan jalan.

Transfer and Promotion

Saling bantu bukan hal yang asing di lingkungan Bukalapak. Sehingga seringkali jika dibutuhkan seorang karyawan perlu di transfer ke tim lain. Menariknya karena keterbukaan dan kelengkapan wiki yang ada, proses transfer ini tidak lah sulit untuk dilaksanakan. Semua karyawan memiliki base pengetahuan yang hampir sama, sehingga tidak butuh waktu lama untuk melakukan transfer knowledge. Ada transfer yang bersifat permanen ada pula yang hanya sementara. Transfer antar tim ini pun membuat tersebarnya knowledge semakin merata. Saya sendiri beberapa kali “dipinjamkan” dan akhirnya permanen dipindah ke tim payment.

Salah satu transfer yang berkesan adalah ketika saya untuk satu kuarter di transfer ke tim “Gatot Kaca”. Sebuah tim yang berfokus untuk melakukan “migrasi” ataupun “refactor”. Pada kesempatan itu tugasnya adalah “mengecilkan size aplikasi”. Secara tidak langsung tugas itu membuat saya harus membaca code milik tim lain, untuk menjaga tidak terjadi sebuah bug karena saya salah refactor. Dalam durasi yang singkat itu saya belajar banyak hal baru, terlebih karena pengalaman bekerja secara langsung dengan senior developer seperti mas Jeff (yang dulu menginterview saya) dan mas Rizky Habibi.

Selain sering ditransfer saya juga sempat mengalami promosi. Sebuah proses kenaikan jabatan. Saya dipromosi menjadi Medior Engineer (yeay… 🎉). Promosi ini saya dapatkan setelah kurang lebih 2 tahun bekerja di Bukalapak. Momen ini sungguh sangat menyenangkan bagi saya, karena jika melihat saya masuk sebagai Junior Lower kini telah naik menjadi Medior. Oh ya, saya lupa menyebutkan, terdapat 3 leveling tidak tertulis diluar title level (Junior, Medior, Senior) yaitu Lower, Solid dan Upper.

The Mass Layoff

Seperti yang semua orang tau, tidak mungkin kesenangan berlangsung selamanya. Bukalapak sempat masuk ke masa masa suram. Bukalapak melaksanakan pemutusan hubungan kerja (PHK), secara massal. Saat saat itu cukup membuat hampir semua karyawan tegang. Walaupun sepertinya engineering team tidak terlalu kena dampak. Saya pribadi tidak mengetahui apa penyebabnya secara detail ataupun berapa orang yang terkena dampak (kalaupun saya tau, tidak mungkin juga diceritakan disini 😛), yang pasti alasan resminya ialah “efisiensi”.

Selain PHK, terjadi beberapa perombakan kebijakan yang berlaku. Perombakan yang terjadi tidak sepenuhnya menghilangkan “kesenangan” yang ada, hanya lebih dibatasi. Tapi, sejauh yang saya tau tidak ada karyawan yang protes, terkait perubahan kebijakan ini ataupun terkait PHK yang terjadi. Alasannya mungkin karena rasa ownership dan semangat “Gotong Royong” yang tinggi. Kalau tempat lain, seperti yang sering muncul di TV, PHK dapat memancing “reaksi” yang besar.

Lagi lagi saya perlu bersyukur, nama saya tidak masuk ke dalam daftar potong.

Tidak lama setelah peristima PHK massal ini dimulailah transisi kepemimpinan di dalam tubuh Bukalapak. Satu persatu pimpinan berganti, sampai akhirnya CEO unicorn yang paling ikonik di Indonesia, mas Zaky, digantikan. CEO baru, bang Rachmat Kaimuddin melanjutkan kepemimpinan dengan semangat baru. Beliau pula yang mengantarkan Bukalapak mencapai IPO di tahun ini (2021).

Life in the pandemic era

Karena kebijakan bekerja yang fleksibel, sesungguhnya karyawan Bukalapak sudah terbiasa dengan remote working ataupun WFH. Sehingga selama pandemi seperti sakarang, sejauh yang saya tau, tidak ada kesulitan berarti bagi para karyawan untuk menyelesaikan pekerjaan mereka. Bahkan sejauh yang saya tau banyak pencapaian yang melebihi rekor perusahaan terjadi selama kebijakan WFH dijalankan.

Bagi saya yang seorang introvert sebenanrnya kerja remote dan WFH ini sangat nyaman. Saya tidak perlu keluar rumah dan menghabiskan waktu dijalan. Tidak perlu ribet memilih pakaian, dan kalau lagi benar benar malas, bisa mulai bekerja tanpa harus mandi (ayo jangan bohong kalian yg WFH pasti pernah tidak mandi kan 😜 ). Memang ada beberapa hal yang menjadi hilang ataupun berkurang (seperti tidak bisa outing) tapi yah tentu tidak ada yang sempurna.

Jika harus memilih satu hal yang paling di rindukan ialah kesempatan bertemu langsung dan mentoring dengan para senior engineer.

A notion to resign

Mungkin ini bagian yang paling ditunggu oleh kalian yang membaca sejauh ini.

Kayaknya Bukalapak asik banget, lalu kenapa pilih resign?

Jujur saja awal mula kepikiran untuk resign adalah sekitar saat mengetahui akan ada pergantian CEO. Saya terpikir wah Bukalapak tidak akan sama lagi. Tapi kemudian saya terpikir

Emangnya kalau keluar mau kemana? toh mas zaky juga ngga nge-start company baru

Lagian sepertinya CEO baru ini tidak kalah keren, mari lihat dulu apa perubahan yang dibawa.

Lagi lagi jujur saja, yang terjadi diluar ekspektasi saya. Bang Rachmat juga sangat keren. Mas Zaky dan bang Rachmat, memang individu yang berbeda, memiliki gaya yang berbeda tapi jelas, pilihan para stakeholder untuk memilih bang Rachmat tidaklah salah. Terbukti Bukalapak memiliki trajectory yang jelas menuju profitabilitas dan kini menjadi yang pertama melakukan IPO.

Salah satu yang paling saya sukai dari bang Rachmat adalah hampir setiap hari Senin, beliau menuliskan email yang menyapa seluruh karyawan. Email yang berisi sedikit update mengenai kondisi Bukalapak dan arahan singkat kepada kami para karyawan. Email yang terasa sangat personal, yang jelas ia tulis sendiri.

Lalu apa alasannya?

Ada 2 alasan utama kenapa saya memilih mengundurkan diri.

Arah Bukalapak selanjutnya.

Bukalapak yang lebih efisien dan mengejar profit, membuat saya merasa proses inovasi yang ada menjadi berkurang cepat. Saya tekankan bukan hilang, hanya berkurang. Hal inilah yang mendorong saya untuk "coba-coba" melihat ke sekitar.

Jadi jelas, saya tidak mengalami masalah apapun di kantor. Sehingga tidak ada urgensi untuk segera pindah. Selain itu saya mempertimbangkan ingin melanjutkan studi di Bandung. Sehingga bekerja di Bukalapak Bandung jelas adalah sebuah pilihan luar kepala. Tapi ya saat melihat lihat, kalau ada offer yang menarik, tentu akan saya ambil.

Saya terpikat untuk berpindah framework development

Alasan kedua mirip dengan alasan saya ketika berpindah dari BE dev menjadi App Dev. Namun kali ini saya tetap ingin menjadi App Dev hanya saja pindah framework, dari yang sebelumnya Android (Native) Dev menjadi Flutter Dev.

Sekitar setahun lebih ke belakang, saya mulai mengenal sebuah framework baru untuk mengembangkan aplikasi mobile, yaitu flutter. Saya belajar lebih jauh, mencoba membuat beberapa aplikasi dan akhirnya sangat menyukai flutter. Saya berfikir bahwa masa depan app dev adalah flutter. Jadi secara spesifik kini "lihat-lihat" saya berfokus kepada lowongan sebagai flutter dev.

Making Decision to Resign

Saya mulai melihat lihat, sejak awal 2021, sekitar akhir Desember - awal Januari. Ada sebuah tawaran yang menarik, tapi setelah mempertimbangkan lebih jauh tidak jadi saya ambil. Selain itu pemikiran untuk resign di tengah pandemi sedikit menakutkan. Bagaimana jika saya pindah namun tempat yang baru tidak bisa bertahan di tengah pandemi? Mencari pekerjaan berikutnya mungkin tidak akan mudah.

Sampai ketika saya ngobrol dengan teman saya, Esa, yang telah lebih dulu resign dari Bukalapak. Dari Esa saya mengetahui ada sebuah oportunity di perusahaan lain, yang cukup menarik. Saya lalu mencobanya dan Alhamdulillah lolos hingga offering. Dan offer yang diberikan sulit untuk saya tolak. Benefit yang meningkat drastis dengan possibility menggerjakan produk berbasis flutter. Sehingga pada tanggal 31 Mei 2021 saya mengirimkan formal notice kepada bagian human resource. Terhitung per tanggal 31 Juli 2021 saya sudah bukan bagian dari keluarga besar Bukalapak dan mulai tanggal 2 Agustus 2021 saya akan memulai perjalanan beru dengan Grab Indonesia. Doakan saya lulus probation ya teman teman.

My Final Work, and left over.

Selama 3 tahun 4 bulan bersama Bukalapak:

Saya dan tim merilis dan/atau mengembangkan 7 produk yang berbeda. 4 diataranya saya berperan sebagai ASL (App Squad Lead).

Melakukan modularisasi, refactor, optimisasi terhadap ribuan baris kode. Dengan belasan kalau bukan puluhan halaman wiki.

Terlibat dalam 4 squad, 2 tribe.

Mendapatkan 1x promosi.

Mengunjungi 3 negara bersama rekan kerja.

Mengisi beberapa sharing session tim.

Menjadi performer dalam 3 acara internal.

Sebuah perjalanan yang sangat panjang dan menyenangkan.

Ada beberapa hal yang terpaksa harus saya tinggalkan di tengah jalan seperti revamp sebuah halaman dan refactor sebuah SDK. Tapi saya yakin teman teman di tim pasti mampu melanjutkannya, karena semua yang ada di Bukalapak adalah orang orang yang hebat.

1. Karena masalahnya Callback Hell, apakah MVC kembali relevan jika menggunakan aync await?

Callback hell hanya salah satu kelemahan yang ada. Saya memilih menunjukkan hal tersebut karena menurut saya hal itu adalah kelemahan yang paling “terlihat”. MVC sendiri merupakan pattern yang muncul paling awal, dimana pemograman masih bermindset syncronous. Paradigma seperti coroutine, events loop dan sejenisnya belum ada atau belum populer. Async-await sendiri muncul dengan lahirnya paradigma asyncronous programming (selanjutnya saya sebut async progam).

Menurut laman di wikipedia, async progam pertama kali muncul pada tahun 2007 di bahasa F#. Diadopsi C# pada tahun 2012, lalu python dan Typescript pada tahun 2015. Jadi, masih bisa dibilang lumayan baru.

Lalu, kembali ke pertanyaan apakah async prog bisa menghidupkan lagi MVC?

Singkatnya, menurut saya, tidak.

Salah satu tujuan penerapan design pattern arsitektural, seperti MVC, adalah untuk memiliki kode yang menerapkan SRP (Single Responsibility Principle, dari SOLID principle). Kita melakukan SoC (Separation of Concern) kepada kode kita. Hal ini (diharapkan) dapat mempermudah kita untuk memelihara dan mengembangkan kode tersebut dikemudian hari. Salah satu kalimat jargon terkait hal ini ialah “akan lebih mudah di unit-test”.

Tapi, sebenarnya apa yang dipisah?

Controller, Presenter, ViewModel, dan Intent sesungguhnya adalah bagian yang berusaha memisahkan business logic. Perbedaan scope (batasan masalah) yang mana saja disebut business logic itulah yang memunculkan berbagai pattern yang ada. Sebagai contoh silahkan lihat potongan kode dibawah mengenai MVC.

https://gist.github.com/alifgiant/b073e7145254eec89fe631f2b523f096

Kita bisa lihat ada sebuah scheduler (coffeEmptyCheckScheduler) yang dibuat dan running setiap 10 menit. Ketika waktunya tiba akan mengecek apakah kopi kosong, jika iya maka akan melakukan refill. Bagian kode yang ini, bagi sebagian orang, adalah sebuah business logic yang tidak seharusnya berada di dalam sebuah view. Pemisahan akan lebih baik ketika menggunakan MVP. Seperti contoh dibawah.

https://gist.github.com/alifgiant/e7c605d0dacdc8d82798bc4199747a7a

Bisa kita lihat view kini lebih bebas dari business logic. Oleh karena itu menurut saya jika masih ada yang menggunakan MVC sebaiknya segera hijrah.

Kalau kamu masih bingung bedanya MVC dan MVP kalimat sederhananya ialah “Controller tidak memiliki reference ke view sedangkan presenter memiliki reference ke view”.

2. Masalah MVP hanya kalau lupa unregister si presenter? Kalau gitu misal udah yakin sudah unregister aman dong?

Itulah alasan kenapa MVP masih exist di pemograman modern. Selain alasan tersebut (yakin ga akan lupa unregister presenter), masih banyak yang menggunakan MVP dikarenakan ia lebih sederhana dibandingkan MVVM dan MVI. Misalnya saja di MVP kita tidak perlu mengenal beberapa konsep baru seperti Observable dan Observer, Emiter dan Subscriber, Reducer dan Dispatcher. Untuk lebih jelasnya silahkan baca mengenai paradigma Reactive Programming.

Namun muncul lagi sebuah perdebatan bahwa view belum cukup terpisah. Bisa dilihat pada contoh sebelumnya, ada proses di view yang mengubah field coffeRefilloading (sebuah model atau state milik view). Bagi sebagian orang ini adalah business logic. Karena business logic seharusnya berada di presenter maka sering kali terjadi “lupa” atau “miss” mengubah state ataupun menjalankann fungsi di view ketika melakukan perubahan. Tentu saja sebagai programmer yang handal jika sebuah masalah sering terjadi kita ingin mencari solusinya.

Pada pattern yang baru, View dirancang agar otomatis react terhadap perubahan view-state dan me-reflect hasil perubahannya. Untuk sementara mari kita namakan “objek” baru yang mengendalikan semua state sebagai NeoController. Karena semua state dikendalikan oleh NeoController bisa kita katakan hanya ada satu sumber kebenaran (Single Source of Truth, SSoT), yaitu state milik NeoController. Selain itu, karena kini state hanya dapat diubah oleh NeoController maka alur data dari view hanya ada satu arah (Unidirectional Data Flow, UDF). Bisa dilihat di diagram diatas, pada MVP terdapat 2 panah keluar namun di new pattern hanya 1. Kedua konsep baru yaitu "Single Source of Truth" dan "Unidirectional Data Flow" dapat ditemukan baik pada MVVM maupun MVI. NeoController kemudian dinamakan sebagai ViewModel pada MVVM dan Intent-Reducer pada MVI.

Perbedaan utama dari MVP dan MVVM ataupun MVI terletak pada kedua konsep baru ini.

3. Apa bedanya MVVM dan MVI? Kalau dari contoh (di artikel sebelumnya) cuma dari jumlah state?

Sebenarnya di contoh pada artikel sebelumnya saya menyederhanakan MVI sehingga terlihat sama dengan MVVM jika MVVM hanya memiliki 1 state. Ada konsep User dan Reducer yang sengaja saya hilangkan. Secara singkat perbedaan MVVM dengan MVI terletak pada seberapa ketat konsep SSoT dan UDF diterapkan dimana MVI lebih ketat. Perhatikan diagram berikut.

Bisa dilihat MVVM bisa memiliki beberapa state, yaitu view state dan business state. View pada MVVM hanya otomatis reflect kepada view state. Hal inilah yang sempat saya sebutkan diartikel sebelumnya. Bisa saja ada sebuah view state yang sebenarnya depend ke business state tapi miss ketika business state diubah.

Pada MVI diterapkan SSoT yang lebih ketat, semua state digabung menjadi satu dan pasti di-observe oleh view. Walaupun tentu saja akan ada perubahan state yang seharusnya dan tidak perlu render view namun menyebabkan render terjadi. Tentu saja hal ini memunculkan perdebatan mengenai performa aplikasi.

Selain itu, kalau kamu memerhatikan diagram diatas, saya baru menggunakan istilah Almost-MVI. Karena selain SSoT MVI juga lebih ketat mengenai UDF. Di diagram diatas kamu bisa lihat masih adanya panah yang berputar ditempat, Action-State. Hal ini memungkinkan adanya proses yang tiba tiba mengubah state (unpredictable change). Sebagai contoh pada kasus coffeEmptyCheckScheduler sebelumnya. Action memiliki kemungkinan untuk mengubah tanpa adanya aksi dari view.

Lah, kalau emang business logicnya gitu?

Untuk “mengakali” proses yang tiba-tiba ada ini, kita harus membayangkan “sebenarnya apa sih yg berhak untuk memulai sebuah aksi?”. Jawabannya ialah User. “Tapi user kan diluar sistem”. Menariknya, ternyata kita bisa ngemock user 😅. Seperti ketika kita melakukan mock terhadap dependecy lainnya yang kita perlu tau ialah apa output yang diharapkan dari objeck tersebut.

Lalu, apa output dari user? tentu saja, As you can guess, Intent.

Jadi, pada MVI action tidak mengetahui juga apa kondisi terkini dari state, dan tidak bisa tiba melakukan modifikasi tanpa adanya Intent. Imaginary Friend User menghasilkan Intent. Action menerima data yang dia butuhkan dari Intent. Lalu, melakukan aksi dan memberikan hasilnya kepada Reducer. Reducer sendiri adalah objek yang berupa pure function yang menerima input current state, dan new data. Kurang lebih untuk kasus kopi diatas bisa kita tulis menjadi kode berikut.

https://gist.github.com/alifgiant/0946a70fb39ae1b730784c4576af54b5

Menjadi jauh lebih panjang? Ya, setuju. Tapi kini harapannya kodenya lebih predictable.

Kesimpulan

Selain MVC, Semua pattern ada kelebihan dan kekurangan nya. Seringkali dalam real world implementasinya disesuikan dengan kebutuhan. Jadi tidak murni MVP, ataupun tidak murni MVVM ataupun tidak murni MVI. Bahkan bisa berbeda total dari contoh diatas.

Cukup sekian, jika masih bingung, ataupun tidak sependapat boleh DM tanya tanya ataupun komen di instagram. ataupun.. ya dimanapun lah.