## Daftar Isi

- [Pendahuluan](#pendahuluan)
- [Mulai Dari Framework Populer](#mulai-dari-framework-populer)
- [Belajar Langsung Dari Dokumentasi Resmi](#belajar-langsung-dari-dokumentasi-resmi)
- [Belajar Dasarnya Sembari Menggunakan Framework](#belajar-dasarnya-sembari-menggunakan-framework)
- [Penutup](#penutup)

## Pendahuluan

> Beberapa mungkin menyadari saya pernah membuat blog perihal pentingnya fundamental di [https://yehezgun.com/articles/why-fundamental-matters](https://yehezgun.com/articles/why-fundamental-matters). Saya menyadari ternyata saya perlu menambahkan beberapa pon terkait ini. Akan saya jelaskan dari perspektif saya sebagai front-end engineer.
> 

Mungkin kalian sering mendengar pernyataan, “Belajar dari dasar dulu sebelum terjun ke *********framework*********”. Menurut saya, itu benar. Idealnya, memang sebaiknya belajar yang dasar-dasar dulu sebelum masuk ke topik yang lebih dalam, sehingga sudah ada pemahaman yang lebih solid.

Nah sekarang bagaimana kasusnya kalau butuh pekerjaan atau penghasilan? **(urgent)**

Belajar dari 0 pastinya sangat memakan waktu yang cukup lama sementara anda butuh penghasilan segera untuk sehari-hari. Saya pernah menemui kasus di sekitaran teman saya dan melihat-lihat di Twitter, cukup banyak cerita dari mereka yang langsung terjun ke *********framework********* dan belajar dasar-dasarnya sembari menggunakannya. Metode ini biasa dikenal sebagai ******************************************************Top Down Learning Approach.******************************************************

Saya pribadi pernah menerapkan ini sebenarnya ketika ******resign****** dari pekerjaan sebelumnya di software house pada 2021. Saat itu, saya hanya punya sekitar 3 bulan lebih sebelum kontrak saya habis dan tidak ada rencana untuk memperpanjang. Jadi saya putuskan untuk belajar **********tech stack********** baru secara cepat sehingga bisa mendapat pekerjaan baru.

Mungkin ini agak bias, tapi saya harap semoga blog ini bisa memberikan pandangan baru mengenai bagaimana belajar hal baru dengan ****************************************************Top Down Learning Approach****************************************************. Kurang lebih inilah yang saya pelajari.

## Mulai Dari Framework Populer

Kenapa memulai dari framework yang populer itu direkomendasikan?

Sederhananya, semakin banyak penggunanya, semakin besar dukungan komunitasnya. Anda bisa dengan mudah menemukan orang-orang yang berdiskusi dan saling memberikan bantuan terhadap suatu masalah yang dihadapi di forum seperti Twitter atau Stack Overflow. Dengan kata lain, ini adalah kabar baik karena ketika sedang ***************troubleshooting***************, anda lebih mudah dan cepat menemukan solusinya.

Di konteks ini, anda bisa memilih React atau Vue sebagai *********framework********* pertama yang dipelajari. Dari sisi lapangan pekerjaan, terutama di Indonesia, **********tech stack********** ini cukup menjanjikan.

Dalam pengalaman pribadi, saya sempat pelajari baik React dan Vue dalam kurun setahun setelah pulang kerja. Bisa dikatakan, sangat ********worth it.******** Ketika **troubleshooting**, sangat banyak opsi jawaban yang bisa dijadikan referensi untuk menyelesaikan masalah yang dihadapi ketika koding. Dan hal inilah juga yang membantu saya akhirnya bisa mendapatkan pekerjaan baru di awal 2022 lalu.

## Belajar Langsung Dari Dokumentasi Resmi

Kenapa bukan tutorial?

Saya tidak berkata tutorial itu jelek. Justru tutorial dari blog dan video sangat membantu saya juga dalam proses belajar. Tapi kalau disadari, si pembuat tutorial sebenarnya juga menggunakan dokumentasi resmi ketika membuat tutorial. Ini cukup memvalidasi bahwa dokumentasi sepatutnya dijadikan referensi utama.

Membaca dokumentasi resmi, itu berarti anda belajar langsung dari pembuat atau kontributor *********framework********* terkait. Anda bisa juga belajar penggunaan *********framework********* yang digunakan berdasarkan perspektif mereka. Inilah yang membantu anda dalam menggunakan *********framework********* pilihan anda secara benar.

Contohnya, kalau anda menggunakan React, sangat direkomendasikan untuk belajar langsung dari dokumentasi resminya di [https://react.dev/learn](https://react.dev/learn). Penjelasannya sangat lengkap terkait konsep-konsep yang ada di React. Saya jamin anda belajar banyak dari sini.

Jika anda masih pemula, saya mengerti ketika baca dokumentasi resmi terasa membingungkan karena banyak penjelasan yang menggunakan bahasa yang teknis. Saya juga pernah mengalami itu. Untuk kasus ini, saya belajar dari tutorial seperti [Web Programming UNPAS](https://www.youtube.com/@sandhikagalihWPU) untuk membantu saya memahami topik-topik dasar seperti CSS, JS, dan HTML. Ini sangat membantu karena pak Sandhika Galih menjelaskannya dalam bahasa Indonesia dan penjelasannya mudah dimengerti 😄.

Satu hal juga yang saya pelajari, pak Sandhika Galih yang membuat channel Youtube Web Programming UNPAS juga menggunakan dokumentasi resmis seperti [MDN Web Docs](https://developer.mozilla.org/en-US/) and [Tailwind CSS official site](https://tailwindcss.com/) sebagai referensi utama. Inilah yang juga membuat saya terdorong untuk belajar lebih detail lewat dokumentasi terkait karena banyak informasi yang lebih detail di sana.

## Belajar Dasarnya Sembari Menggunakan Framework

Izinkan saya membagikan pengalaman saya terkait ini.

Pada November 2021, kontrak kerja saya di tempat kerja sebelumnya berakhir. Sekitar hampir 4 bulan sebelumnya saya sudah menyadari itu. Awalnya, saya pikir harus belajar ulang dari nol untuk mendapatkan pekerjaan baru. Tetapi saya sadar saya hanya punya 4 bulan kurang sebelum kontrak saya habis dan tidak ada rencana untuk perpanjang.

Beruntungnya ada seorang teman lama, teman kuliah sewaktu S1 dulu menawarkan proyek *********freelance********* kepada saya. Proyeknya itu menggunakan React JS dan saat itu saya belum ada pengalaman sama sekali dengan React. Jadi sebelum proyek dimulai, saya memfamiliarkan diri saya dengan konsep-konsep React dan mencoba tutorial dari Youtube.

Ketika mengerjakan proyek tersebut, saya menyadari bahwa untuk mengerti React, mau tidak mau harus belajar dasar-dasar Javascript lagi. Cukup menantang bagi saya karena saya terbiasa menggunakan Angular di tempat sebelumnya dan harus berganti ke React yang memiliki ********approach******** sangat berbeda.

Syukurlah teman saya ini sangat suportif ketika melakukan ***********code review***********. Jadi saya bisa pelajari hasil evaluasi kodingan saya dan belajar dari referensi yang ia kutip. Setiap harinya saya mencoba dan mendorong diri saya untuk belajar lagi konsep-konsep JS.

Pengalaman ini merupakan yang berkesan dalam hidup saya karena banyak hal yang saya pelajari dari proyek ini. Dari domain proyek baru, framework baru, dan belajar kembali dasar-dasar CSS dan JS yang sebenarnya saya cukup bergumul juga mengenai ini. Dan inilah saya sekarang, bekerja di ************************tech hospitality startup************************ dan menggunakan React & Vue berkat proyek ini.

Jadi singkatnya mengenai poin ini, saya langsung terjun ke React sekalipun kemampuan Javascript saya masih kurang. Tapi sambil jalan, saya juga belajar dasar-dasar JS sembari menggunakan React dan mengerjakan proyek ****real****. Beruntungnya, saya punya seorang teman yang suportif dan membantu saya dalam proses pengerjaannya. Anda bisa mengunjungi profil website-nya di [sznm.dev](http://sznm.dev), saya belajar banyak dari dia sampai sekarang. 

## Penutup

> Benar fundamental itu penting, tapi tidak selamanya kita harus memulai dari sana. Kita juga bisa langsung terjun ke framework atau tool dan pelajari dasar-dasarnya sembari berjalan. Dengan kata lain, kita bisa memulai atau kembali ke dasar ketika membutuhkannya.
> 

Kesimpulannya, dengan Top Down Learning Approach, ini bisa jadi metode belajar alternatif ketika harus belajar **********tech stack********** baru dengan cepat. Mulai dari framework populer dan pelajari dari dokumentasi resminya, itu akan sangat membantu anda belajar lebih efisien. Belajar fundamental sembari menggunakan framework dapat membantu anda mendapatkan pengalaman praktis secara cepat. Tapi perlu diingat, setiap orang bisa mendapatkan pengalaman berbeda, jadi tidak perlu khawatir dan terburu-buru. Bereksperimenlah sebanyak mungkin sampai anda menemukan metode yang paling cocok.

Terima kasih telah menyempatkan membaca.

Top Down Learning Approach

## Table of contents

- [Introduction](#introduction)
- [You Can Start With The Popular Framework](#you-can-start-with-the-popular-framework)
- [Learn Deeper From The Official Doc](#learn-deeper-from-the-official-doc)
- [Learn The Basics While You’re Using That Framework](#learn-the-basics-while-youre-using-that-framework)
- [Closing](#closing)

## Introduction

> You might be recognized that I’ve written a blog about how important the fundamental is. You can access it at [https://yehezgun.com/articles/why-fundamental-matters](https://yehezgun.com/articles/why-fundamental-matters). Things changes and now I need to add some points regarding this. I’ll explain based on my perspective as a front-end engineer.

You might hear a lot of people say, “You need to start from the basics first before jumping into libraries or frameworks”. I can say it’s right. But you need to realize that it also needs the ideal condition to learn. Ideally, you learn from the basics then continue to the advanced ones, and finally, you can go through the frameworks that you prefer.

Now, how if you need a job immediately?

Starting learning from basic may feel quite painful and takes too long while you need a job immediately for a living. I’ve met some friends and taken a look at some stories on Twitter, so many testimonials that prove you can jump directly into a framework and learn the basics while you’re using it. This learning method is usually called ******************************************************Top Down Learning Approach.******************************************************

I actually have implemented this method since I resigned from my previous job at a software house in 2021. At that time, I only have around 3 months before my contract expired and I didn’t want to extend it. So I have to learn other newest tech stacks quickly so I can hop into the new job opportunities.

This can be very opinionated, but hopefully, it can give you some insights about how to learn new tech stacks using Top Down Learning Approach. Here are my takeaways.

## You Can Start With The Popular Framework

Why start with the popular framework?

Simply, the more people use that framework, the bigger and wider the community support is. You can easily find so many people discussing and giving suggestions based on the problem that they had on Twitter or Stack Overflow. In other words, this thing can be good news when you’re doing troubleshooting. You can find the solution faster.

In this context, you can choose React or Vue as your first framework (or library) to learn. The job market, especially in Indonesia is quite promising if you can master this framework.

In my experience, I learn both React and Vue in a year after work. I can say that it’s worth it😄. When I did troubleshooting, so many answers and options that I can use as the solution to the problem because a lot of people use them and discuss them in the programming forum. And of course, I finally got a new job in 2022 because of this.

## Learn Deeper From The Official Doc

Why not tutorials?

I didn’t say learning through tutorials is bad. A blog or video tutorial is also very helpful as a learning resource. But if you notice, the person that made the tutorial also learn from the official docs while they demonstrate the walkthrough. It validates that the official doc is the main reference.

Reading the official doc, it means you learn from its maker or contributors. You can directly figure out the concept of the tool or framework that you’re using based on their perspective. It also means you can learn how to use it in the right way by reading through the main official doc.

For example, if you’re using React, it’s very recommended to learn from React Official Docs at [https://react.dev/learn](https://react.dev/learn). There are so many explanations about the concept that exists in React. I guarantee you that you can learn more through this.

If you’re a newbie, maybe reading the official docs feels so confusing because the explanation usually uses very technical terms. I’ve experienced it before. For this case, I learn through Youtube tutorials like [Web Programming UNPAS](https://www.youtube.com/@sandhikagalihWPU) to help me to understand the subject that I want to learn like CSS, JS, and HTML concepts. This is very helpful to know the basic concepts because it uses Bahasa Indonesia and Mr. Sandhika Galih’s explanation is easy to understand for me😆.  

One thing that I figured out is that Mr. Sandhika Galih who created and developed Web Programming UNPAS Youtube Channel also learn and often cited references from official docs like [MDN Web Docs](https://developer.mozilla.org/en-US/) and [Tailwind CSS official site](https://tailwindcss.com/). This thing encourages me to read more through it when I need to solve my case because there are more information details in there.

## Learn The Basics While You’re Using That Framework

Let me share this point based on my experience.

On November 2021, my work contract at my previous workplace expired. Four months before, I actually realized it. At first, I think I have to learn again from scratch to land my new job. But I only have four months left before the contract ends and I didn’t want to extend it.

Luckily there’s an old friend, he was my college friend before asked me to join his freelance project as a frontend developer. The project use React JS and at that time I didn’t have any experience with it. So what I do before the project begun is familiarize myself with the React concept by watching and trying the tutorial through several Youtube videos.

When I was working on the project, I realized that to understand React, I need to learn the fundamental of Javascript. This was very challenging for me because I usually use Angular at my previous workplace then I have to switch to using React which has a very different approach to work on this project.

Luckily my friend was very supportive when doing the code review. So I can learn based on his feedback and figure it out by myself by reading the references that he’s given. Day by day I tried and forced myself to revisit the JS concept to help me while working on this project.

This experience enlightened me because I learn a lot through that project. I learn new project domains, and new frameworks, and revisit the basic knowledge related to CSS and JS that I struggled with before😄. And here I am now, I work at a tech hospitality startup and use React & Vue as the main tech stack.

So in summary for this point, I directly jump into React even though I still lack Javascript fundamental skills. But along the way, I also learn the JS basics while I’m using React and working on a real project. Luckily I have a very supportive friend that can guide me through this. You can see his profile at [sznm.dev](http://sznm.dev), I learn a lot from him until now.

## Closing

> Yes fundamental is very important, but it doesn’t mean you have to start with it. You can also directly jump into a framework or tool and then learn the fundamental along the way with it. In other words, you can start or back to basic when you need it.
> 

In conclusion, the Top Down Learning Approach can be a viable option for those who need to learn a new tech stack quickly. Starting with a popular framework and learning from the official doc can help you learn faster and more efficiently. Additionally, learning the basics while you're using the framework can help you gain practical experience and build your skills. Remember, everyone's learning journey is different, so don't be afraid to experiment and find what works best for you.

Thank you for reading!

## Daftar Isi

- [Pendahuluan](#pendahuluan)
- [Struggling Dengan Customized UI](#struggling-dengan-customized-ui)
- [Struggling Dengan UI Yang Berbeda di Tiap Device](#struggling-dengan-ui-yang-berbeda-di-tiap-device)
- [Struggling Dengan UI Audit dan Pixel Perfect](#struggling-dengan-ui-audit-dan-pixel-perfect)
- [Clean Code](#clean-code)
- [Penutup](#penutup)

## Pendahuluan

Akhirnya setelah sekian lama, saya bisa menulis artikel di website pribadi saya lagi. Terlalu banyak hal yang perlu dikerjakan tahun ini, apalagi saat ini sudah masuk ke tahap pengerjaan tesis di S2 sembari bekerja full-time.

Wow, tak terasa saya sendiri sudah bekerja sebagai frontend engineer selama 2 tahun lebih🤣. Mungkin beberapa dari kalian, sudah membaca artikel retrospective saya sebelumnya di sini [sini](https://yehezgun.com/articles/one-year-retrospective). Banyak hal yang telah dijalani dan dilewati.

Sekarang, saya akan menceritakan apa saja yang menjadi *struggle* saya selama ini, terutama dari tahun 2022 sejak bekerja di *product-based company*. Kurang lebih inilah yang saya jalani dari saya *onboarding* pada Januari 2022 lalu sampai sekarang. Saya akan bercerita dari perspektif sebagai frontend engineer.

## Struggling Dengan Customized UI

Hal yang sebenarnya biasa sebagai frontend engineer harus berhadapan dengan hal-hal yang berbau UI. Tapi bagaimana kalau harus slicing banyak UI Component tanpa *design system* dan bantuan dari UX Engineer? Dengan kata lain, semuanya di-*handle* oleh si frontend engineer itu sendiri. Mulai dari slicing UI sampai pada integrasi dan fungsionalitas aplikasi web-nya🙃.

Ya, kurang lebih itulah yang saya hadapi. Di tempat sebelumnya, saya terbiasa menggunakan UI framework (Ionic) untuk membuat *hybrid mobile app*. Sekarang saya harus membuat UI component sendiri tanpa bantuan UI Compoent Library karena memang kebutuhannya *custom*. Beruntung masih bisa diatasi dengan penggunaan Tailwind CSS sebagai CSS utility untuk membantu proses slicing UI.

Masalah lainnya, yaitu belum adanya *design system*. Ini tentu akan membutuhkan *effort extra* ketika membangun komponen UI yang belum pernah dibuat sebelumnya dari 0. Untungnya, ini masih bisa diakali dengan cara membuat komponen yang *reusable*, sehingga ketika dibutuhkan kembali, cukup memanggil komponen tersebut di halaman terkait dan modifikasi props-nya sesuai kebutuhan.

Seperti yang kalian ketahui, *struggle* terbesar saya adalah ketika harus menghadapi *task* yang berkaitan dengan UI ini. Saya akui, memang ini kelemahan saya walau bekerja sebagai frontend engineer. Syukurnya, saya mendapat kolega yang suportif dan membantu saya bisa melewati ini semua sampai sekarang 😁.

## Struggling Dengan UI Yang Berbeda di Tiap Device

Menjadi seorang frontend engineer berarti harus bisa membuat web-nya bisa diakses dari perangkat manapun. Itu berarti, UI-nya harus *responsive* atau adaptif tergantung *device*-nya, entah itu *mobile*, tablet, atau desktop.

Bagi saya, sebenarnya kalau *responsive UI*, masih tergolong mudah. Tapi bagaimana kalau ternyata, UI-nya sangat berbeda jauh antar device (adaptive UI)? Nah ini yang membutuhkan waktu lebih untuk pengembangannya😄. Jadi bisa dibilang, saya harus koding paling tidak 3 kali untuk membuat UI Components-nya untuk *mobile*, tablet, dan desktop😂.

Saya bahkan harus konsultasi dengan mas [Irfan Maulana](https://twitter.com/Maz_Ipan) terkait ini, sehingga saya bisa tahu pendekatan apa saja yang dirasa cocok ketika harus berhadapan dengan ini🤣.

Kurang lebih, ini sedikit penjelasan mengenai desain UI yang adaptif, bisa diakses di [https://kinsta.com/blog/responsive-vs-adaptive/](https://kinsta.com/blog/responsive-vs-adaptive/).

![image](https://cdn.sanity.io/images/xyi8gzmb/production/06d13fd70e133a8f5521dc1ab0f31fa692d3088c-897x576.png?w=450)

## Struggling Dengan UI Audit dan Pixel Perfect

Seperti yang telah saya katakan sebelumnya, UI slicing adalah pergumulan terbesar saya sepanjang bekerja sebagai frontend engineer. Masalahnya tidak di situ saja. Setelah saya berhadapan dengan slicing Ui tersebut dan membuatnya untuk masing-masing device, masih harus berhadapan dengan UI audit sebelum dirilis ke production 😆.

Bisa dikatakan, proses ini bahkan butuh waktu lebih penjang dibanding slicing UI-nya itu sendiri karena banyak detail yang perlu diperhatikan. Dan sejauh ini belum ada UX Engineer di tempat sekarang. Jadi, frontend engineer lah yang menjadi *pioneer* penting dalam proses ini sendiri.

Masih lebih mudah untuk membuat *logic* dan integrasi karena satu fungsi bisa digunakan lintas *device*. Tapi kalau urusan UI, seringkali walau hanya mengganti margin atau padding, efeknya bisa mengacaukan keseluruhan tampilan dalam halaman tersebut 🤣. Saya bisa dengan mudah membuat *unit test* untuk kodingan logic-nya. Tapi kalau untuk UI ini, harus divalidasi kembali oleh *designer* terkait supaya akurat dan sesuai dengan *mockup design* yang telah disediakan.

Inilah yang disebut *pixel perfect*, yang berbarti UI-nya harus seakurat mungkin sama dengan *design* yang diberikan. Inilah yang menjadi pergumulan cukup berat bagi saya sendiri sampai sekarang karena telah terbiasa menggunakan UI Framework di tempat sebelumnya. Sementara, sekarang saya harus membiasakan diri untuk membuat UI Component sendiri, cukup *struggle* walau sudah menggunakan Tailwind CSS.


## Clean Code

Sekalipun saya sempat katakan bahwa lebih mudah membuat kodingan logic-nya dibanding slicing UI, bukan berarti saya tidak *struggle* dengan itu juga. Terkadang saya bahkan butuh waktu lebih untuk menentukan cara membuat logic yang bisa *reusable* dan *maintainable* dalam jangka panjang. Sehingga, ketika saya membutuhkannya kembali, saya bisa tinggal memanggilnya saya dan mengubah parameter, props, atau arguments sesuai kebutuhan.

Sebenarnya bukannya malas membuat *clean code*. Tapi seringkali banyak faktor yang perlu diperhatikan seperti *deadline* atau melewatkan *code review*. Untungnya sekarang ini, kultur kerjanya sudah mengarah menjadi lebih baik. *Code review* sudah menjadi kewajiban sebelum deploy ke *staging* dan *production*. Ini sangat bermanfaat bagi saya pribadi, sehingga saya sendiri bisa tahu apa yang menjadi *blindspot* saya ketika koding.

## Penutup

Ya, inilah evaluasi karir saya sepanjang dua tahun bekerja sebagai frontend engineer. Banyak hal yang masih harus ditingkatkan, terutama perihal slicing UI😅. Saya bahkan masih bergumul dengan ini sekalipun telah bekerja di sini selama setahun 😆.

Sekalipun memang menyebalkan bahkan melelahkan, tapi inilah proses yang harus dihadapi. Saya belajar banyak terutama untuk menghadapi ketakutan saya sendiri ketika harus berhadapan dengan *task* terkait UI. Perjalanan masih panjang, dan banyak hal yang harus dipelajari lagi.

Terima kasih telah menyempatkan membaca ini. Boleh sekali jika ingin membagikan cerita kalian, bisa tulis di kolom komentar di bawah.

Retrospective Setelah Dua Tahun Bekerja Sebagai Frontend Engineer

## Table of contents

- [Introduction](#introduction)
- [Struggling with Customized UI](#struggling-with-customized-ui)
- [Struggling with Totally Different UI on Each Device](#struggling-with-totally-different-ui-on-each-device)
- [Struggling with UI Audit and Pixel Perfect Thing](#struggling-with-ui-audit-and-pixel-perfect-thing)
- [Clean Code Struggles](#clean-code-struggles)
- [Closing](#closing)

## Introduction

Finally, I got time to write this first blog in 2023. Too many things to do especially since I have to deal with my thesis while working full-time.

Wow, I’ve been working as a full-time front-end engineer for 2 years🤣. For you that has read my previous retrospective [here](https://yehezgun.com/articles/one-year-retrospective), you might notice that so many things that I’ve been through. 

Now I’ll tell you the underrated story based on what I’ve gone through in a year since 2022 since I work at a product-based company. These are the things that I’ve gone through since I’ve been onboarded on January 2022 until now and how I cope with each of them. I’ll tell the story from my perspective as a front-end engineer.

## Struggling with Customized UI

Seems normal and usual with this customized UI thing. But what about when you have to work on it without a design system and the help of a UX Engineer? In other words, the frontend engineer is the main pioneer to produce a user-friendly web app while having to work on the main functionality of the web app itself🙃.

Yes, this is what I’ve struggled with. At my previous workplace, I used Ionic as a UI framework to build a hybrid mobile app. Now I have to create the customized UI from scratch without any help from UI Component Library. Luckily, I still can use Tailwind CSS as the CSS utility to help me in the development process.

The other problem is there’s no proper design system yet for the development process. So it needs extra effort when building UI components that have never been made before from scratch. Luckily, I still can manage this by creating reusable UI components so that when I need it more than once, I can only change the props based on my needs.

As some of you know, my main struggle is when I have to deal with this kind of UI thing. I admit that this is my biggest weakness even though I work as a frontend engineer. Thank God, I got very supportive teammates and seniors who understand my struggles and I can overcome them day by day until now😁.

## Struggling with Totally Different UI on Each Device

Being a frontend engineer or web developer means you have to make your web app to be accessible through cross-devices. It includes you have to make the UI to be responsive or adaptive on every device like mobile, tablet, and desktop.

For me, it’s not a big struggle when I have to deal with responsive UI things. But what about when I have to face a web design that has totally different UI in each device (adaptive UI)? Ah, I need more time to finish the task related to this thing😄. It means I have to code at least three times to create the UI components for each device (mobile, tablet, and desktop). Feels like I code the whole app😂.

I even have to consult with mas [Irfan Maulana](https://twitter.com/Maz_Ipan) regarding this, so I can learn what approaches that can be the best option when I have to deal with this🤣.

Here’s the resource to know more about adaptive UI design, you can open [https://kinsta.com/blog/responsive-vs-adaptive/](https://kinsta.com/blog/responsive-vs-adaptive/) to read about it.

![image](https://cdn.sanity.io/images/xyi8gzmb/production/06d13fd70e133a8f5521dc1ab0f31fa692d3088c-897x576.png?w=450)

## Struggling with UI Audit and Pixel Perfect Thing

As some of you know, my biggest vulnerability is UI slicing even though I work as a frontend engineer now. The problem is not over yet. After I have to deal with that customized and totally different UI in each device, I still have to deal with the UI audit before it is released to production😆.

I can say, this process can even need longer time than the UI slicing process itself because too many details that I need to be aware of. And there’s no UX Engineer yet that can assist with this process. So in other words, the frontend engineer must do this whole process alone.

It’s easier to fix the logic parts because it works the same way on every device. But when I have to revise the UI details, oftentimes it will affect the whole UI in the related pages, even just adjusting the margin or padding🤣. I can use a unit test to validate the logic parts, but the UI components need to be validated by the designer itself and have to be accurately displayed like the mockup design.

This thing is usually called pixel perfect, which means you must develop the UI precisely or even exactly like the mockup design that has been provided. This is still my biggest struggle until now because I’ve worked with the UI Component Library for more than a year. So it’s hard when I have to adapt to this case when I have to develop the UI by myself, even if I’ve used CSS utilities like Tailwind CSS.

## Clean Code Struggles

Even though I’ve said that when I code the logic parts, it’s easier than slicing the UI, it doesn’t mean I don’t struggle with this too. Sometimes I even need time to think about how to create codes that can be reusable and maintainable for the long term. So when I need it again, I can recall it again and only adjust the parameters, props, or arguments based on my need.

Actually, it doesn’t mean I’m too lazy to produce clean codes. There are many factors that need to be considered like tight deadlines or skipping the code reviews. But luckily, the environment gets better these days. Code reviews now are mandatory before deploying the codes both to staging and production, so I can know my blind spot when writing the codes and can improve the code quality.

## Closing

So yeah, this is my career retrospective after two years of working as a full-time front-end engineer. So many things that I need to improve, especially the UI slicing process😅. I even still struggle with this even though I’ve worked on this for around a year😄.

My takeaway from this is even if it’s annoying and exhausting, this is the process that I need to embrace. I learn a lot to face my fear when I have to deal with the hardest thing that I actually afraid of. There’s still more journey ahead, and so many things to be learned.

Thanks for reading this. You can share your stories also in the comment section below if you want.

Retrospective: After Two Years Working as a Frontend Engineer

## Table of contents

- [Introduction](#introduction)
- [Enjoying Current Job](#enjoying-current-job)
- [Start to Pursue a Master's Degree](#start-to-pursue-a-masters-degree)
- [Start to Live Healthily](#start-to-live-healthily)
- [Join Offline Dev Community Events](#join-offline-dev-community-events)
- [Projects that I’ve worked on in 2022](#projects-that-ive-worked-on-in-2022)
  - [WA Helper](#wa-helper)
  - [QR Generator](#qr-generator)
- [Hope for 2023](#hope-for-2023)
  - [Learn Backend](#learn-backend)
  - [Finish my final thesis](#finish-my-final-thesis)
  - [Keep Joining or even Contribute to Tech Community](#keep-joining-or-even-contribute-to-tech-community)
- [Closing](#closing)

## Introduction

Well, time flies so fast, now we’re getting closer to 2023. Like I’ve done before, I’d like to write my yearly recap and hope for the next year. I can say, this article will seem like a yearly retrospective. This is also a self-reminder for me when I read it again.

## Enjoying Current Job

I was officially onboarded on 3rd January 2022 as a frontend engineer and since then, I have been enjoying my job. Being able to work from home and only needing to visit the office once a month for meetings and retrospectives is great. I also like the work culture here.

This is the first time I use React JS (and Next.js) in my full-time job. Along the way, I sharpen my Typescript and CSS skills through the tasks that have given. Very challenging, but here I am, I have to face and overcome my fear.

I also got to know a lot of people, and they were always willing to help and answer my questions even though we were working remotely. I'm grateful to be part of this team and I'm looking forward to the future.

## Start to Pursue a Master's Degree

The year has been a whirlwind of changes and growth for me. After working full-time as a frontend engineer, I finally decided to take the plunge and pursue a Master's degree in Management Information Systems. The privilege of working remotely and continuing to work full-time while studying was a huge benefit for me and I registered at Binus Online Learning in June 2022.

The first few weeks of my course were challenging. I had to juggle my work, my coursework, and my personal life all at once. I soon found my rhythm, however, and started to enjoy the challenge of the course. I was learning new concepts and ideas, and I had an amazing group of people to work with.

The course was not without its difficulties. I had to learn how to use multiple software programs and systems to complete my assignments. This was not something I was used to and I found myself struggling at first. However, with a lot of practice and help from my instructors and peers, I eventually got the hang of it and was able to work with amazing efficiency.

I also had to learn how to manage my time effectively. I had to make sure that I gave enough time to my work and studies, while still finding time for my friends and family. I quickly developed a system that worked for me, and I was able to make the most of my time.

Despite the difficulties, I thoroughly enjoyed the course. I was learning new things and growing as a person. I had grown to love the challenge of the study and was feeling more confident in my abilities. I was so proud of the progress I had made and was looking forward to the future.

## Start to Live Healthily

Since October 2022, I started to push myself to do morning walks and jogging at least 4 times a week. I do a morning walk and jog for 30 minutes each day. The first month is the hardest part and caused my leg so painful, even now😂.

But fast forward 3 months, I can feel changes in my body. I feel more energized after I do this kind of sport. I am also rarely sick, only little flu without a fever sometimes. Before doing this, I often feel fatigued when working for a whole day, even I work remotely.

I’ll keep this new habit as my new lifestyle. Working remotely is a huge benefit for me, so I can still do some physical activities before start working in the morning.

## Join Offline Dev Community Events

I had the privilege of being invited to speak at the Jakarta JS meetup on the 30th of August. I was very excited to attend as it was my first time speaking at an offline meetup.

I prepared my talk weeks in advance, and I was so relieved when I finally finished my speech. I was nervous but also excited to be part of the tech community.

The night of the event was filled with energy and excitement. Everyone was so welcoming and friendly, and I felt like I was part of something bigger. I was able to connect with so many amazing people in the tech industry and learn from them. It was a night I will never forget and I'm thankful to have been part of it.

![image](https://cdn.sanity.io/images/xyi8gzmb/production/75124b2e29ae619611197b5f6f5ed55ebb68ece4-2000x3000.jpg?w=450)

I am also thrilled to attend the GDG Bogor meetup on 3rd December. It was the first local event in my hometown and I was so happy to meet some friends, especially those who I knew from Twitter.

The atmosphere was electric, and I could feel the excitement in the air. I was able to meet so many amazing people in the tech industry and learn from them. It was an incredible experience and I'm so glad I was able to attend.

![image](https://cdn.sanity.io/images/xyi8gzmb/production/0368f9bca1f36dda4152a8383c85a8c2c0adcda2-4160x3120.jpg?w=450)

## Projects that I’ve worked on in 2022

### WA Helper

I made a simple web app to help me when I want to chat with someone through WhatsApp without saving the phone number first. I made it for myself, but I set it up as a public project so everyone can use it too. It can be accessed at [https://wa.yehezgun.com/](https://wa.yehezgun.com/).

### QR Generator

This is a simple QR Code generator made using Next.js, Tailwind CSS, and React QR Logo library. Like the previous projects, I made it for myself at first. But I set it as an open-source project so everyone can use it or even contribute to it. The live demo can be accessed at [https://qr.yehezgun.com/](https://qr.yehezgun.com/)

## Hope for 2023

### Learn Backend

I am determined to learn backend development with Golang in 2023. I will continue to work as a front-end engineer, but having an understanding of back-end development will be a valuable skill to have.

I don’t want to be an apathetic front-end engineer. If I can develop the backend side by myself, I’ll do it. Of course in my workplace, I’ll do it with review and approval from the related backend engineer.

### Finish my final thesis

I’ve started to pursue my master’s degree in Management Information Systems, so I have to finish it on time. I have to say, I hate learning through academic papers. Too many theories and procedures🤮.

I’ve promised myself that I’ll finish the thesis in 2023 and get graduated in 2024, so I don’t have to deal with this kind of research paper anymore and will focus on coding-related jobs as a frontend engineer.

Of course, after I get my new degree, I’ll have a new side job as a part-time or freelance lecturer as my second income stream. This is great and I will finish what I’ve started.

### Keep Joining or even Contribute to Tech Community

Since I joined Jakarta JS and GDG Bogor, I was so thrilled to participate in the next events. Maybe as a participant first, but if I’m invited as a contributor, I’ll be happy to help.

This kind of event can be momentum to create networking with new friends. Working remotely has a side effect, yep which is a lack of social life🤣. This is why I realized I need to socialize through this community.

## Closing

So yeah, this is my 2022 recap. I hope 2023 will be a better year for us even though there are a lot of negative speculations out there. What’s yours?

My 2022 Recap

## Table of contents

- [Disclaimer](#disclaimer)
- [Introduction](#introduction)
- [Strengthen Your Fundamental Skills](#strengthen-your-fundamental-skills)
- [Develop Your Own Online Presence](#develop-your-own-online-presence)
- [Don't Take It For Granted](#dont-take-it-for-granted)
- [Don’t Stop Learning and Improving](#dont-stop-learning-and-improving)
- [Closing](#closing)

## Disclaimer

> Actually, this is spontaneous advice that I usually gave to my former students when I was a laboratory assistant in 2018-2020. I often gave these messages to them at the end of the semester. Hope this also helps you to decide where you’ll develop your career.


## Introduction

I think 2022 will be better than 2020 and 2021. Then I realized it’s just the beginning of the worse case (hopefully not) when there are so many sudden layoffs around the world, especially in tech startup industries. It also affects our country, Indonesia, when several big startups lay off hundreds or even thousands of employees (including software engineers). So sorry to hear that, hope those who all impacted can get a better workplace.

Some of my former students got a job at a unicorn startup company. In the beginning, I saw them happy and enjoying their workplace. But suddenly, several days ago their Instagram Story turns out into sad or worrying things. I even figured out that some of them got stressed and have to be treated in a hospital😥 because it affected their physical health. Their dream job and company don’t make them happy anymore, it’s even terrifying for them. Thank God, they didn’t affect by the layoff, but because their teammates and leaders got laid off, it caused them to be stressed and overthinking during these days.

This case is not only causing panic for the experienced employees but also confusing the fresh grads or final-year college students who will get into the real world after their college. Some of my former students who will be graduating this year approached me several weeks ago and I wanted to help them, but during this hard time, there’s a lot of hiring freeze. Even if there’s a job vacancy (even for a tech-related job), it requires experience minimum of 1-2 years of work in the related industry. It’s difficult to find a suitable job for them.

This huge event makes me remember again the words that I usually sent to them at the end of the semester after the exam week. Hopefully, this can recall what to do next. This message is actually given when they reached the 7th semester, but I think it is still relevant during these difficult times.

## Strengthen Your Fundamental Skills

Again I have to say, technology updates are very fast, especially related to the software engineering field. For example, in the frontend field, there are a lot of frameworks out there. Even there’s a myth that there’s a new JS framework every week. You might feel tired when you are still not finished yet to learn a framework, then another new framework appears and disrupts the community.

I also often received stories from those who got interviewed at some companies for internships in 2020. Most of them said that the questions are dominated by the basics of programming things like Object Oriented Programming, Web fundamentals, basic CSS layouts, and Data Structures. They also stated that they regret cheating in the exam. The score may be 100, but they have no actual skill.

I always said this thing to my former students when I was their laboratory assistant.

> Instead of directly jumping into “fancy frameworks”, why don’t you start learning the basics first? It’s okay if this thing seems to cause you to be slow, but when you have developed the basics, it’s easier to get into the frameworks. Don’t be trapped by FOMO. Do your best for your exam, and don’t cheat or you’ll regret it soon. Your score may be perfect, but I can guarantee you will realize it’s useless when you apply for an internship or full-time job.
> 

You can read my previous article to see why fundamental matters [here](https://yehezgun.com/articles/why-fundamental-matters).

## Develop Your Own Online Presence

Instead of trying to apply for jobs by yourself, why don't you try to make the recruiter interested in you first so you don’t have to apply for the job by yourself?

In this case, I experienced it by myself. In 2021, before I resigned from my previous job, I developed my online presence by creating some mini-projects and publishing them on my LinkedIn. I started by creating my own personal web and also created some articles on it. It took about 4 months until I got a new job at my current workplace. I even didn’t apply to my current workplace by myself. A recruiter approached me through LinkedIn and I proceed with the recruitment process until I finally got the offer letter.

By doing this, I trained myself to create a mini-project and then expose it. This can cause me to create a proper web app that can be used not only by myself but also by other people who want to use it.

But I have to tell you that this tip may work differently for you. In my case, I can get a new job in 4 months because I expose my projects and articles to the public through LinkedIn. But I cannot guarantee you can get the same result as mine. But as long you consistently do it, you’ll gain the result soon or later.

You can read my story in my previous article [here](https://yehezgun.com/articles/how-to-get-hired-without-applying).

## Don't Take It For Granted

I don’t say that being an idealist is bad. But see the current situation. In 2020 when the Covid pandemic began, it was so difficult to find a job. I also figured out that so many of my juniors struggled to find the internship job and end up extending their college time because so many companies do hiring freeze and just a few job vacancies out there.

The only advice that I can give to them is this.

> As long it suits your role preference (for example frontend engineer) and it’s not a red flag company, go ahead.
> 

If it’s the first time for you to get an internship or even a full-time job, don't take it for granted. It’s okay to join the local software house in your place. At least, it’s not a red flag company and gives you proper wage, it doesn't matter, go ahead. Develop your skills there, stay there for at least a year, and finish every project that has been assigned to you. It can be your portfolio for your next career journey.

You can read my story related to this point [here](https://yehezgun.com/articles/2021-recap#what-ive-learned-throughout-the-year). There’s some explanation of how I finally can get a new job after I struggled to finish the job at my previous company for a year.

## Don’t Stop Learning and Improving

Last but not least, don’t stop learning and improving. After you got your first internship or full-time job, don’t forget to keep learning. Don’t stop there.

I have seen several of my friends achieve their dream job because of their consistency. I remember there was a friend who worked at a small software house company at Gading Serpong as a backend engineer for about 10 months, then he got a job at an insurance company. In around a year, he trained himself to do some Hackerrank code challenges every day and finally got a job at a unicorn startup company this year. I can say, he not only upgrade his skills, but also his value (and also salary💵) for the long run.

## Closing

Oh before I close this story, I just want to tell a simple tip based on [Gergely Orosz's tweet](https://twitter.com/GergelyOrosz/status/1594612869085233153). **Treat your career choices like you would invest your money**. Don’t just focus on the high salary, but please understand the business model of the company to that you’re applying. Remember, these are the difficult times when there are a lot of uncertainties. It’s better to choose the company which has a clear model business and of course a profitable one, even the salary & benefit offer is lower than the others (at least it’s not underpaid and red flag company). This kind of company will survive or even keep growing during this time of crisis.

![https://res.cloudinary.com/yehez/image/upload/v1669527509/Articles/Letter%20for%20FreshGrad/gergely_tweet_wttrj7.png](https://res.cloudinary.com/yehez/image/upload/v1669527509/Articles/Letter%20for%20FreshGrad/gergely_tweet_wttrj7.png)

![https://res.cloudinary.com/yehez/image/upload/v1669527864/Articles/Letter%20for%20FreshGrad/gergely_tweet2_px3erd.png](https://res.cloudinary.com/yehez/image/upload/v1669527864/Articles/Letter%20for%20FreshGrad/gergely_tweet2_px3erd.png)

I hope this story can give you hope and new insights. Keep moving forward, as long you work persistently, it will be worth it. Let me know if there’s something that wants to be discussed, you can write it in the comment section below. You can also tell your own story if you want, so we can encourage other people who read this article.

A Letter For Fresh Grads & Final Year Students During This Difficult Time

## Daftar Isi

- [Introduction](#introduction)
- [Task Management](#task-management)
- [Struktur Tim](#struktur-tim)
- [Kultur Kerja](#kultur-kerja)
- [Penutup](#penutup)

## Introduction

> Ini sekedar testimoni saya selama bekerja di software-house company selama setahun lebih kemudian pindah ke company product-based sejak awal 2022. Mungkin tidak 100% valid dan terlihat “opiniated”, ini sekedar cerita pengalaman saja.
> 

Seperti yang beberapa teman-teman tahu, saya pernah bekerja di sebuah software house, kemudian pindah ke company sekarang yang tergolong sebagai product-based company. Seperti yang saya tweet di Twitter saya sebelumnya, saya akan coba jelaskan perbedaan bekerja di software house company vs product-based company dari perspektif pengalaman pribadi.

## Task Management

Seperti yang kita sama-sama tahu, software house company ini secara umum adalah perusahaan yang menyediakan layanan atau membuatkan project untuk client yang ingin menggunakan jasanya. Dengan kata lain, ini seperti *third party* yang membuatkan atau men-deliver *request* client. Sementara product-based company ini adalah perusahaan yang punya produknya sendiri yang dijual kepada user. Biasanya mereka sudah punya tim sendiri untuk mengembangkan produknya.

Nah, *notice*sesuatu di sini?

Saya sempat bekerja di sebuah software house sejak September 2020 - November 2021. Cukup banyak project dari client yang telah didevelop di perusahaan tersebut. Seperti yang beberapa teman tahu, saat itu saya di-assign kepada satu client BUMN untuk mengembangkan aplikasi perkeretaapian, yaitu KAI. Saat itu saya bersama seorang senior mengembangkan aplikasi mobile [KAI Access](https://play.google.com/store/apps/details?id=com.kai.kaiticketing).

Singkatnya, dari KAI sendiri telah menyediakan semua dokumentasi dan requirement yang diperlukan, lalu kami tinggal mengerjakannya saja. Ketika dari mereka berkata A, maka kami pun harus men-deliver itu sesuai permintaan mereka. Mustahil untuk menginterfensi. Dengan kata lain, saya hanya boleh deliver project-nya sesuai dengan request. Sebenarnya bisa saja menyampaikan *concern* tertentu bila ada, tetapi birokrasinya sangat rumit dan memakan waktu, bahkan bisa berpotensi membuat sang client kehilangan kepercayaan, apalagi software house ini sangat bergantung kepada client untuk menghasilkan profit.

Sulit untuk menerapkan Agile di sini. Seringnya, kami bekerja secara Waterfall yang mana request datang dari client dan kami harus men-delivernya. Saya sempat mencoba mengimplementasikan metode Agile seperti Scrum atau Kanban, tetapi ujungnya gagal karena project harus di-deliver dengan tepat, bukan dengan iterasi. Dengan kata lain, saya bekerja berdasarkan request dan harus deliver itu secara akurat.

Singkat cerita saya resign dari tempat tersebut lalu mendapatkan pekerjaan di tempat yang sekarang sejak Januari 2022. Kali ini saya bekerja di sebuah tech hospitality company yang menyediakan layanan booking hotel kapsul atau cabin. User juga bisa menggunakan smartphone mereka sebagai kunci untuk masuk ke kamar hotel mereka menggunakan QR Code.

Kali ini, saya di-assign untuk mengerjakan product utamanya di bagian website. Sebenarnya sih tugas utama saya sekarang ini *rewrite* semua code base yang ada di website sekarang dari Nuxt.js ke Next.js🤣.

Fokus utama sekarang adalah mengambangkan website utama dari perusahaan tempat saya bekerja saat ini. Request atau inisiatif biasanya datang dari Product Manager/Owner kemudian design mockupnya akan dibuatkan oleh Product Designer hingga akhirnya diserahkan kepada saya untuk dikerjakan. Tapi sebelum handover, kami biasanya mendiskusikan hal tersebut dahulu dan membicarakan *concern* bila ada sehingga semua saling tahu apa yang jadi *blocker* dan pengaruhnya terhadap timeline produk. Terkadang, kalau saya ada *concern*tertentu terhadap design web-nya, Product Designer akan mengubahnya sesuai feedback yang diberikan, sehingga proses *development*bisa lebih dipermudah dan cepat. Terasa lebih demokratis ya🤣.

Kali ini, tempat yang sekarang lebih Agile terutama untuk development cycle-nya. Kebanyakan kita menggunakan Kanban untuk setiap *task,* tetapi kami selalu rutin mengadakan *sprint planning*tiap minggunya di hari Senin untuk menentukan *task*apa saja yang akan dikerjakan selama seminggu. Sisa *task* minggu lalu akan di-assign kembali di *sprint* berikutnya (minggu berikutnya).

Berdasarkan teori Agile, kami biasa mengembangkan sebuah fitur atau *request* menggunakan teknik iterasi di setiap sprint-nya. Tim product akan mengerjakan riset terhadap behavior user atau complain dari user, kemudian hasilnya akan dipertimbangkan menjadi *task* di sesi *sprint planning* Dengan kata lain, akan ada update secara konstan setiap minggunya (setiap *sprint cycle).* Tetapi tenang saja, sang manager telah menentukan batas maksimal *sprint point* yang bisa diambil oleh tiap engineer agar menghindari *overwork*.

## Struktur Tim

Untuk struktur tim, saya bisa katakan bahwa software house memiliki tim yang lebih beragam atau *diverse*. Setiap timnya akan dikelompokan berdasarkan client yang di-assign yang pastinya punya konteks tersendiri sesuai requirement-nya. Contohnya, saat itu saya tergabung dalam tim yang mengembangkan aplikasi perkeretaapian dari client BUMN. Simpelnya, saya bersama senior saya fokus untuk deliver project dari client BUMN tersebut (walaupun terkadang kami juga berpindah ke tim lain untuk membantu menyelesaikan project-nya). Berganti tim di sini seperti berganti perusahaan tetapi dengan gaji dan benefit yang sama🤣.

Di tempat yang sekarang, sama sih ada squad-nya juga. Tetapi kali ini, karena product-based, setiap squad sebenarnya punya kemiripan topik, karena perusahaan memiliki product-nya sendiri, yaitu capsule/cabin hotel booking app. Timnya akan di-assign berdasarkan fokus utama dari sub-product atau fitur yang dikembangkan. Misalnya, sekarang squad saya fokus untuk mengembangkan service yang berkaitan dengan *customer-facing,* seperti website utama yang dipakai oleh user. Ada juga tim lain yang fokusnya mengembangkan *internal-tools* atau *internal platform.*

## Kultur Kerja

Sepanjang saya bekerja di software house, saya bisa katakan bahwa deliver project itu adalah fokus utama. Yang berarti, setiap project harus di-deliver tepat waktu dan sesuai dengan keinginan client. Dengan kata lain, biasanya ketika ada request tertentu, itulah saat-saat di mana para programmer jadi *hectic.* Tapi sekalinya request sedang sedikit atau bahkan tidak ada, kami pun seperti pengangguran yang datang ke kantor🤣. Seperti yang sempat saya singgung di section pertama, sangat sulit untuk menerapkan Agile di sini, karena kebanyakan Waterfall based.

Ada juga beberapa waktu yang mana saya dan senior saya harus bertemu dengan client untuk diskusi requirement, timeline project, dan kontrak dokumentasi lainnya. Jujur, di sinilah kemampuan komunikasi saya tertantang. Dan ya, omong-omong saya WFO saat itu setiap hari bahkan saat Covid-19 masih ramai-ramainya, jadi cukup terasa lelahnya karena ada waktu commuting dan sulit menemukan waktu senggang, apalagi ketika sedang hectic-nya.

Di tempat sekarang gimana?

Jujur, ketika pindah ke yang sekarang, agak *culture shock*😅. Kali ini saya malah harus Agile di sini. Seperti yang sempat saya singgung di section pertama, kulturnya lebih demokratis. Setiap engineer bahkan punya hak berkata “tidak” pada suatu *task* atau inisiatif yang tidak memiliki korelasi dengan role utama mereka, atau kadang bisa meminta *adjustment* terhadap request atau inisiatif yang diberikan apabila ada *concern* tertentu. Dengan kata lain, untuk mengubah suatu *product initiative* menjadi sebuah *task*, itu harus melewati tahap riset yang cukup panjang dan kemudian harus didiskusikan dahulu dengan anggota tim terkait, sehingga sama-sama saling tahu konteksnya.

Kalau kultur meeting? Sebenarnya itu tergantung squad. Di kasus saya, karena saya mengerjakan service yang berkaitan dengan *customer-facing*, itu berarti saya kebanyakan harus align dengan tim product dan marketing karena itu merupakan platform utama yang dipakai user dan merupakan platform operasional utama. Jadi, tetap skill komunikasi dan negosiasi saya harus diasah lagi di sini😀.

Tetapi perbedaan utamanya, saya lebih fokus mengembangkan product-nya, sekalipun terkadang masih harus *switching context* karena ada saja *alignment* yang harus saya ikuti karena terkait web yang saya kembangkan😅. Dan yang paling saya sukai di sini adalah *previledge* bisa WFH atau WFA. Saya hanya perlu ke kantor sebulan sekali untuk meetup bulanan bersama para kolega setelah sebulan bekerja jarak jauh.

Kalau kultur coding-nya gimana?

Nah ini mungkin agak “opiniated”, tapi saya coba jelaskan secara umum ya. Waktu di software house, mentalnya adalah ***mental proyek*** yang berarti harus deliver project tepat waktu dan akurat sesuai request client. Jujur, sangat dilematis ketika ingin menerapkan *clean code pattern* di sini, karena deadline yang mepet dan *request* yang “ngadi-ngadi”. Fokusnya di sini adalah menyelesaikan dan deliver project-nya.

Di tempat sekarang, saya menyadari bahwa ***develop suatu product*** sangat berbeda dari sekedar mengerjakan project. Product punya lifetime yang lebih panjang, dan tidak bisa dikembangkan secara *bar bar*. Setiap inisiatif produk harus diriset dahulu oleh tim product, untuk kemudian diserahkan kepada engineer terkait untuk dikerjakan. Saya bisa katakan, saya pun juga harus membuat kodingan yang lebih *clean* sehingga product-nya bisa lebih sustain dan *maintainable* dalam jangka panjang. Code review di sini adalah kewajiban dan pastinya untuk memastikan kodingan saya sudah efektif atau belum🤣.

## Penutup

Nah itulah cerita saya sepanjang bekerja di software house kemudian pindah ke company yang product-based. Saya tidak bermaksud memojokan pihak manapun, hanya menceritakan pengalaman saja😁. Semuanya bagus kok, hanya tergantung preferensi masing-masing mau kerja di mana.

Kalau ada yang tanya, lebih baik kerja di mana, software house atau product-based company? Tergantung. Kalau menurut saya pribadi, apalagi jika masih fresh graduate, lebih baik mulai bekerja di software house dulu sebagai batu pijakan karir. Kenapa? Karena kamu bisa dapat banyak pengalaman dari project-project yang di-handle. Bahkan kamu juga bisa belajar banyak dari client-client di perusahaanmu.

Tapi di kasus saya sih, setelah bekerja setahunan di software house, agak burnout karena terlalu banyak project dan client yang harus dihandle. Itulah yang membuat saya memutuskan untuk pindah ke company yang product-based untuk bisa fokus mengembangkan satu product dalam jangka panjang, sekaligus melatih diri untuk bisa membuat kodingan yang lebih *clean*. Juga, bekerja di product-based company ini sangat melatih saya untuk menjadi *product-minded software engineer*, sehingga saya pun harus memastikan setiap kodingan saya harus *align* dengan kebutuhan *user* dalam jangka panjang.

Sulit untuk bercerita panjang lebar di sini sebanarnya🤣. Tak apa apabila mau berdiskusi lebih lanjut di kolom komentar atau DM Twitter saya. Saya akan mencoba balas di kala senggang. Semoga membantu, terima kasih.

Kerja di Software House vs Product-Based Company

## Table of contents

- [Introduction](#introduction)
- [The Task Management](#the-task-management)
- [Team or Squad Structure](#team-or-squad-structure)
- [Work Culture](#work-culture)
- [Closing](#closing)

## Introduction

> This is based on my experience working at a software house-based company for about a year, then switching to a product-based company at the beginning of 2022. Maybe not 100% valid and seems opinionated, this is just my testimony.
> 

As some of you know, I ever worked at a software house-based company, but then I switched to my current workplace, which is a product-based company. Like I mentioned on Twitter several days ago, I’ll make an explanation based on my experience of the differences between working at a software house company vs a product-based company.

## The Task Management

As you know, a software house company in general is a company that creates a service or app for clients. It means they are the third party that creates and fulfills the clients’ requests. Meanwhile, a product-based company is a company that has its own product or services that are offered to the users. A Product-based company usually has its own team to develop its own products.

Notices something here?

I worked at a software house company from September 2020 - November 2021. There are a lot of projects that have been developed based on the client's request. As you know, during my work period there, I was assigned to a BUMN client that provides train services, yes KAI. At that time, my senior and I developed [KAI Access](https://play.google.com/store/apps/details?id=com.kai.kaiticketing) mobile app.

In short, KAI provides all the docs and requirements and we developed the app based on it. When the client says A, we have to fulfill it accurately. There’s no way to interfere with the request. In other words, I can only deliver the app or feature based on their exact requests. Actually, if there’s any concern regarding the requests, we can tell the client. But it will take more time and potentially the client will lose their trust if we cannot fulfill their requests, meanwhile, the software house company relies on clients to gain profit.

It’s hard to be Agile here. Mostly we work using the Waterfall method which a request comes from the client then we have to deliver it on time. I’ve tried to implement Agile Methodologies like Scrum or Kanban, but it’s quite hard because we have to deliver it accurately, not by iteration. In other words, I worked based on the request (sometimes spontaneously).

Long story short, I resigned from that company and then got my current job in January 2022. This time, my current workplace is a tech hospitality company.

My current workplace provides its own capsule or cabin hotel mobile and web app booking. The user also can use their smartphone as a key to enter their room (using QR Code).

Now, I’ve been assigned to the main product on the website. In other words, I developed the web app for my current workplace until now. Actually, I’ve been given the task to rewrite the whole website using Next.js (from Nuxt.js)🤣. But this time is different.

My main focus is on developing the main website of my current workplace. The request usually comes from the Product Manager/Owner then the mockup design will be made by the Product Designer until it’s handover to me. Before the handover, we usually discuss it and speak out if there’s any concern regarding the task so everyone can know what is the blocker and the general timeline. Sometimes, if I have some concerns about the web design, the Product Designer will adjust the design so it can make the development process easier. Feels more democratic here🤣.

This time the company uses Agile methodology for its development cycle. Mostly we use Kanban for every task, but we always do a weekly sprint planning and alignment on Monday to determine which tasks will be done that week. The recurring tasks from the previous week will be added to the next week.

Based on the Agile methodology, we developed the feature or request using iteration on each sprint. The product team will do the rest of the research on the customer behavior or even complaints, then the research result will be considered to be executed as a task in the sprint planning session. In other words, there will be constant updates every week/sprint cycle. Don't worry the manager has set up the max sprint point that can be assigned in a week, so it will make sure every engineer works ideally (minimize the overwork).

## Team or Squad Structure

For the team structure, I can say that a software house-based company has the most diverse team or squad. Each team will be grouped based on the clients which have a very different context for each project request. For example, my former squad at my previous workplace is dedicated to the BUMN client. Simply, my senior and I work based on that BUMN client’s request (even sometimes I switched to another squad to solve the other client’s problem or issue reports). Changing squad here feels like you’re switching to another company but with the same benefit and salary🤣.

In my current workplace, there are also some squads. But this time, because the company is product-based, every squad actually has a similar topic because the company has its own product, capsule, or cabin hotel booking app. The team is assigned based on the main focus of the sub-product or feature that be developed. For example, my current squad is focused on customer-facing related like the main web app that is used by a lot of external users. Meanwhile, there’s also a squad that focused on internal tools or platform related.

## Work Culture

When I was working at a software house company, I can say that the project deliverable is the main focus. It means, the project must be delivered on time and accurately based on the client’s requirements. There are some times that when the request comes, the software engineers will be hectic for a while. Meanwhile, there are also some times that there are no requests or bug reports so sometimes we didn’t know what to do🤣. Like I was saying in the first section, it’s hard to implement Agile methodology here because mostly the culture is Waterfall based.

There’s also some time that my former senior frontend engineer and I have to meet the related clients to discuss the requirements, the project timeline, and the contract documentation. To be honest, my communication skill is challenged here. And oh, by the way, that time I work from the office (WFO) every day even during the Covid-19 pandemic, so it’s quite tiring because there’s a gap time for commuting, and quite hard to find free time, especially during the hectic times😥.

How about the current workplace?

To be honest, when I switched to my current workplace, I feel quite a culture shock😅. This time, I have to be more Agile here. Like I said in the first section, it’s more to be democratic here. Every engineer can say “no” to a task or invitation that doesn’t have a correlation or related priority to their main task or role, or they can request the adjustment for the request/initiatives based on their concern. In other words, to convert the product initiative to a task, it has to pass the research step and have to be discussed with the related team, so everyone can know the context of the initiative.

For the meeting/alignment culture? Actually, it’s based on the squad. In my case, I work on the customer-facing related squad which means I developed the web app for the company’s users. This also means I have to align with the product and marketing team more because it’s the main product that the users use and affect the main company's operations. In other words, I still have to train my communication and negotiation skills here🙂.

But the main difference is I can focus on the product that I’ve developed here, even though sometimes I have to context switch because there’s some alignment meeting that I have to attend related to the web that I developed😅. And the main thing that I like here, I can work from home (WFH/WFA). I only need to come to the office once a month to attend a monthly meetup with my colleagues.

How about the coding behavior?

Hmm…. it’s quite opinionated I think. But I’ll try to tell the general story. When I was a frontend engineer at a software house company, I must have a ***project mentality*** which means I have to deliver the project on time and precisely based on the client’s request. To be honest, it’s very dilemmatic to implement a clean code pattern here, because of the tight deadline and some “magical” requests from the clients. The main focus is to finish and delivers the project.

Now in my current workplace, I realized that ***developing a product*** is very different than just delivering the project. The product has a longer life and it cannot be developed barbarically. Every product initiative has been researched by the product team, then it will be handover to the related engineer. I can say that I also have to develop a clean code for the product that I developed, so it can be more maintainable and sustainable in the long term. It’s mandatory to request a code review from the senior front-end engineer to make sure that my code is effective and has fewer code smells (actually zero code smells😂).

## Closing

So yeah this is my testimony after working at a software house company and then switching to a product-based company. I didn’t mean to give negative reviews actually, just the story that I’ve experienced before😁. Both are good and it’s based on your preferences to work there.

So if you ask me, which one that I have to choose to work for, a software house or a product-based company? It depends. I think for a fresh graduate, it’s better to start your career at a software house company. Why? Because you’ll learn a lot from every project that you’ll handle. You also can learn from every client’s perspective.

In my case, after I work about a year at a software house, I felt overwhelmed with so many projects and clients. So that’s why I finally switched to a product-based company so I can focus to develop the product for the long term and also can train my coding skill to produce clean code. Also working at a product-based company trains me to be a product-minded software engineer, so every code that I produced must be aligned with the user’s needs for the long term.

It’s kinda hard to tell everything in this short article actually🤣. Feel free to discuss more in the comment section, or you can DM me through Twitter, I’ll try my best to answer during my free time. Hope it helps, thanks.

Working at Software-House vs Product Based Company

## Table of contents


 - [Disclaimer](#disclaimer)
 - [Introduction](#introduction)
 - [Breakdown Your Question](#breakdown-your-question)
 - [Re-check Before Asking](#re-check-before-asking)
 - [Recap The Answer](#recap-the-answer)
 - [Closing](#closing)

## Disclaimer

> This is based on my experience. I’m not prohibiting anyone from asking questions but encouraging you all to be well prepared before asking questions, especially in the programming world. The clearer you describe your problem, the easier the solution will be provided.

## Introduction

When I was a laboratory assistant in my college, I often received so many questions from my juniors. During the class session, when they were doing their laboratory module, there were some parts that they didn’t understand and asked me or my laboratory assistant partner. I actually didn’t have any problem when they ask, it means they are thinking and trying to solve the problem that has given in the module.

But there’s something that bothers me much. Some of them asked questions that actually can be solved if they tried and follow the guide from the laboratory module. Even if the answer does not exist in the module, they can google it and figure out how to solve it. Not only that, sometimes I have to deal with some questions which are not clear enough, so I often waste my time just to figure out what is the root cause or its meaning.

That experience occurs until 2020, the last year of my laboratory assistant  This is actually a bad habit. So I think I need to tell you this, so hopefully, we can reduce this kind of habit in the future. Here are some tips from me to be well prepared before asking something.

## Breakdown Your Question

Before asking, you should know what you’re asking for. I have an exhausting experience regarding this when I was a laboratory assistant. In Almost every session that I taught, so many students or juniors asked unclear questions so I even need more time just to understand what their questions mean.

Most of them just asked, `Kak (in Indonesia we called an older person with the term 'Kak'), I can't run the program on my computer here`. It causes me to waste around 5-10 minutes standing near his/her computer to figure out what is the root cause of the issue until I finally answer the question🤣.

Remember that when you break down your question before asking it will help want people who want to answer the question without wasting more time. At least, figure out what’s the possible root cause of the problem and describe it clearly when asking. When the root cause has been figured out, it will be easier to be solved together.

For example, I have some trainees who break down their questions before asking. They had some issues when they want to fetch data using Angular HTTP. They show a quick demo to me which shows the syntax of the codes and the web UI. They even explain it step by step. In around a minute, I figured out that the code snippets is wrong and caused web breaks. This case is effective if you’re in an offline class session😂.

## Re-check Before Asking

I often receive redundant questions when I was a laboratory assistant. When I solved a student's technical issue, then the other student asked the exact same question and it happened almost every session that I held😅. I have to re-explain the solution for each student. This is very ineffective.

In another case, when I was trying to solve a student's technical issue in a class session, I just googled it and found a suitable solution for the case. Sometimes, I figured out that they skip some steps from the laboratory module or the official docs.

Based on that experience, here are two criteria that have to be fulfilled before asking the technical question (assumed you have breakdown the question before asking):

- Has anyone asked this question and has been answered before?
- Do your own research or trial & error before asking

If the question has been asked before, you can access a forum like [Stack Overflow](https://stackoverflow.com/) and if the question has been answered you also can find the solution for your problem. Or if you’re in an offline class session, make sure that if the question has been asked and answered before, you can ask your friend who asked and receive the answer.

If you’re asking a very technical question related to coding, please try it by yourself first before asking. Figure out what’s wrong with your code through self-debugging. Or, do your own googling, who knows you can find the answer through the internet.

When you have done those things above and cannot find a suitable solution, then come to ask. Don’t forget to describe the problem clearly so it can help anyone who wants to answer to figure out what’s the problem and the suitable solution. This method can reduce the redundant questions or questions that even doesn’t need to be asked because it has already been documented or are available through “googling”.

## Recap The Answer

When you finally got the answer, don’t forget to recap it. For example, if you finally figure out how to fetch the data from the API with Axios, take note of that. If you have a personal blog, write articles about it and publish them so everyone who has a similar problem like you before can also be helped. I usually called it giving back.

Not only about giving back, you even can read again what you’ve written before if you’re facing a similar issue. It will reduce the exhausting “trial & error” because you have experienced a similar issue before and just re-implement the solution.

## Closing

Again, I’m not prohibiting anyone to ask. I just want to tell you guys to be prepared before asking. The more detailed the description of the problem, the easier it is to be solved.

> Finding the root cause of a problem means 50% of the solution
>

Things To Do Before Asking Technical Question

## Table of contents

- [Disclaimer](#disclaimer)
- [Introduction](#introduction)
- [Brilliant Ideas Can Be Produced from A Casual Talk](#brilliant-ideas-can-be-produced-from-a-casual-talk)
- [It is Like Counseling Session](#it-is-like-counseling-session)
- [Closing](#closing)

## Disclaimer

> This article is made from my perspective and experience of making coffee talk sessions. Maybe not 100% valid but I hope this can enlarge your perspective about 1 on 1 sessions.
> 

## Introduction

On the second week of July 2022, I made a free 1 on 1 session called “Ngupi”. It actually a slank word from “kopi” in Indonesian which means coffee. That time, I only created 3 slots for those who want to have an online coffee talk with me.

![https://res.cloudinary.com/yehez/image/upload/v1658824884/Articles/Coffee%20Talk/tweet_mvjcct.png](https://res.cloudinary.com/yehez/image/upload/v1658824884/Articles/Coffee%20Talk/tweet_mvjcct.png)

Some of you may be wondering what is “coffee talk” actually? Actually, regarding the term itself, it’s like you’re going to a cafe with someone and talking about a topic while you’re enjoying the coffee at that place. But due to covid pandemic and restrictions, I made it online through G-Meet.

By the way, thank you [Dian Yehezkiel](https://twitter.com/dianyehezkiel_), [Fathan](https://twitter.com/fmgono), and Bryan who attended my first 1 on 1 session. Actually, your knowledge and daily skill as a frontend engineer surpass mine🤣. As I’ve stated on Twitter that I even need to learn from you guys 😁.

Based on my conversation with those three, here are two important points that I got through it.

## Brilliant Ideas Can Be Produced from A Casual Talk

In Indonesia, we are usually familiar with the term “nongkrong” which means hanging out with some friends. I’ve experienced how casual talk can even influence my life until now. That moment happened in early 2020 before covid restriction began when I was working on my bachelor thesis. 

At that time, my friends and I got stuck with our thesis progress. I still remember almost every day I hang out with them just to go to a minimarket and buy some snacks. Then we just sit on the roadside in front of the campus. Some of them are smokers so they usually smoke while snacking, but non-smokers like me and some of my friends, generally just sit and snack together. Even we often did it with our lecturer regularly😂.

There was an interesting thing for me at that time. When we were stuck on our bachelor thesis project, we just share our progress and even ask for informal counseling sessions with our lecturer that usually join us in snacking. After around an hour and we back to the lab to work on our thesis, we got a new idea to solve the problem that exists in our thesis, and it works🤯.

I can tell you guys, that this casual counseling session with our lecture advisor is more useful than the formal one🤣. Why? Because when we’re in a casual talk, we become more authentic and just tell what we’ve faced and asked for help. It’s very different in a formal counseling session, we generally awkward.

Same as this casual 1 on 1 session. It’s not a mockup interview session. Just casual talk. We can talk about random things like career, study, or even technical things like front-end development. Sometimes, this coffee talk session will have brilliant ideas or insights through this spontaneous session.

## It is Like Counseling Session

This 1 on 1 session is not like mockup interview. Mockup interview’s purpose is to prepare the attendee on how to get ready for the interview session when finding a job. Usually if the attendee wants to prepare himself for a technical interview (for a programming-related job), the mockup interview session will contain live coding and technical questions. In other words, it has technical and specific purposes.

I actually want to help other people who want to work as a front-end engineer through the mockup interview session. But, I think I can’t for now because I still need to learn and my work experience is less than 2 years🤣. So this is why I create a casual 1 on 1 session where everyone who joins this can discuss everything (mostly technical).

Through [Cal.com](http://Cal.com) the attendee must explain what topic they want to be discussed, so we can make sure that it is not losing its essence. For example, the topic is sharing both of our experiences in frontend engineering to gain new insights. So during the session, we discuss our experience, what issues may be faced, and how to tackle them like a counseling session.

Note that this “counseling” is actually not only for the attendee, but it also works for me. I also can learn and find out something new from the attendee’s perspective and experience. In other words, this is like two ways counseling session. Both attendee and the event creator learn and discuss a topic together to gain new insights.

## Closing

So yeah, this is my experience and story about casual 1 on 1 sessions. Don’t get me wrong, who knows if this small thing can change a person’s life through casual discussion? I think if the experienced developers in Indonesia also make this similar open session, we can contribute to generating the new excellent software engineers generation for this nation.

Hope this article gives you another perspective. Let me know if you have some feedback or similar experience, you can share it in the comment section below.

Coffee Talk

## Table of contents

- [Disclaimer](#disclaimer)
- [Introduction](#introduction)
- [Degree vs Just Certificate](#degree-vs-just-certificate)
- [I Can Learn Beyond My Specialization](#i-can-learn-beyond-my-specialization)
- [Networking at University Feels Different](#networking-at-university-feels-different)
- [Closing](#closing)

## Disclaimer

> This is pure my recent experience. All things in this article are purely my opinion. Maybe there are some of you who don’t relate to my story and maybe it cannot be 100% valid, but I hope this can help you to determine your future life path😁.


## Introduction

The story started when I was about 2th semester college student in 2017. I still remember there’s a college subject named Computer & Society. On that subject, I learn a lot of theories about tech ethics and law in Indonesia. That subject is interesting because the lecturer is actually about an insurance company IT manager.

One time, my friends and I have a casual talk with him after class and he shares why he wants to be a lecturer while working full-time as an IT manager. Here’s his answer:

> I actually didn't want to be a lecturer at first. I just took a master's degree then I got a lifetime benefit, being a lecturer for undergraduate students. Don’t worry, I can still work on my full-time job as usual. But I also can be a lecturer on the weekend like this. When I teach you all, actually it’s a giving back from me.
> 

His statement made me consider continuing my graduate study after I graduated from the future that time. 

After I graduated in 2020, I worked at a software house at Gading Serpong. At that place, I know a senior from college who has to own a graduate degree. He was a backend engineer at that time. His name is ko [Vincentius Kurniawan](https://www.linkedin.com/in/vincentius-kurniawan-88759b146/).

One day, I have a deep talk with him, asking him why he took a graduate study and become a lecturer too. He answered like this:

> Having a master’s degree doesn’t make your dream smaller. Most people think that a person who has a master’s degree mostly just becomes a lecturer. But they forget, that being a lecturer is actually not a final dream. It’s a lifetime privilege, you can use it as a side hustle, for your hobby to teach, or just give back. You can still work on your full-time job while being a part-time or freelance lecturer.
> 

I know he also teaches as a part-time lecturer at my former campus. In other words, he has a double job as a backend engineer on the weekdays and as a lecturer on the weekend.

His statement made me more confident to take graduate study. And yeah, after working as a frontend engineer for around a year, I finally decided to pursue a master’s degree.

Luckily, I got very supportive colleagues, a manager, and even my CTO who has signed a recommendation letter for me🤣. For your information, I still work as a frontend engineer as usual at my current workplace. I take a graduate study online program at [Binus](https://mmsi.binus.ac.id/) (Information System), so I can learn outside of working hours online. And of course, remote working is also a benefit for me, so I don’t have to worry about commuting. The only things I need to worry about are electricity and internet connection🤣.

So, here is the explanation of my reasons why I am finally pursuing a master’s degree in Information systems.

## Degree vs Just Certificate

There’s an old friend asking me why I should pursue the master’s degree while there’s a lot of Bootcamp and I can get a certificate from there too? Here’s my answer. 

A BootCamp usually last for about 3-6 months. At the end of the program, the participant can claim the certificate as a prove that he or she has completed all the courses and finished the final project. I can say this is a very good thing. You can use it to apply for a job and improve your first impression in front of recruiters.

Now let’s compare this with the official master’s degree (and its certificate). Usually a master’s study take 1,5 - 2 years to be completed. I can get the master’s degree certificate after I finish the final thesis and publish it as a research paper. This also can prove that I’ve finished my master’s study and officially get a new degree behind my name🤣.

Now, what’s the difference? Someone who has a master’s degree has more powerful benefits. After I get my master’s degree soon, I can have the authority to give a recommendation letter to another person who wants to pursue their graduate study. I also can be a lecturer if I want. And mostly someone who has completed his or her graduate study will get a promotion on their full-time job because there’s some rescaling on the salary and benefit at their workplace (depends on the workplace).

Remember that,  people who pursue their graduate study doesn’t mean they just want to be a lecturer. That’s the wrong assumption. Being a lecturer is not a final dream, it’s a lifetime privilege to all those who has completed their graduate degree. I can be a part-time lecturer without leaving my full-time job as a front-end engineer. When I retired in the future, I can switch careers as a full-time lecturer if I want. It means I have an alternative income as a lecturer.

## I Can Learn Beyond My Specialization

At a Bootcamp, the participant usually just takes one subject that wants to be completed until the end of the program. For example, the participant takes Frontend Engineering BootCamp for 6 months. It means, in 6 months, he/she mainly or even only learns the frontend development. It means, the participant mainly just learns things that his or her preferences.

I take an Information System major for my master's study. There are a lot of subjects that need to be completed for about 1,5 years. Even though I have a bachelor's degree in Informatics and work as a frontend engineer, I have to learn the subjects related to project management and software architecture which are beyond my current specialization. Got the point? I have to face subjects that maybe not be “my preferences”. But don’t get me wrong, things like this can enlarge my capacity to learn and break my mental block to understanding other fields.

A friend of mine also asks me, “You have an informatics or computer science background. Why do you take an Information System major, not Informatics?”. My answer is simply because I have learned technical things for about 4 years of my undergraduate study. Then I worked as a frontend engineer for almost 2 years. Too many technical things that I’ve faced and experienced. I want to enlarge my skillset and prepare for my next career path, yeah being a tech lead😁.

This is why I take an Information System major, so I can learn to be a [product-minded](https://blog.pragmaticengineer.com/the-product-minded-engineer/) software engineer. Who knows in 2-3 years I’ll be a frontend lead. It means I have to improve my communication and project management skills through this major.

## Networking at University Feels Different

Actually, networking can be gained everywhere. But I don’t know, networking through university colleagues feels different for me. At a BootCamp, someone can get new friends or new network who have the same interest in a field based on the chosen subject that he or she prefers for the Bootcamp. But in the university, I can know new people who have more diverse interests and backgrounds.

For example, currently, I know several friends who have diverse backgrounds like Project Managers, SAP Consultants, IT Consultants, etc. When they’re asked about their thesis topic interest, some of them are interested in the security field, some in project management, and anything else. In this kind of diversity, I feel I can learn a lot from this kind of environment.

## Closing

So yeah, those are my three main reasons why I finally pursue a master's degree in Information systems. There are a lot of things that I want to tell here, but it seems hard to express them in the form of this short article. Should I talk about it on a Twitter Space or Podcast? Please invite me as a speaker if you don’t mind🤣. 

If you have something to be discussed here, you can comment in the comment section below.

Life Update: Pursuing Master’s Degree

## Table of contents

- [Disclaimer](#disclaimer)
- [Introduction](#introduction)
- [Preparation](#preparation)
- [Setup The ESLint Rules](#setup-the-eslint-rules)
- [Publish It To NPM Registry](#publish-it-to-npm-registry)
- [Closing](#closing)

## Disclaimer

> In this tutorial, I’ll focus on the specific use case for typescript code-based. You don’t have to imitate this tutorial 100%. You can adjust the specific parts based on your needs

## Introduction

Lately, I’ve been too lazy if I have to rewrite the exact same ESLint rules for my personal projects. Look at this. You maybe noticed this in my previous blog titled, [Standardize Your Next.js Project](https://yehezgun.com/articles/standardize-your-nextjs-project).

```json
{
  "env": {
    "node": true
  },
  "extends": [
    "next/core-web-vitals",
    "eslint:recommended",
    "plugin:@typescript-eslint/recommended"
  ],
  "parser": "@typescript-eslint/parser",
  "plugins": ["import", "unused-imports", "@typescript-eslint"],
  "settings": {
    "import/resolver": {
      "node": {
        "extensions": [".js", ".jsx", ".ts", ".tsx"],
        "moduleDirectory": ["node_modules", "src/"]
      }
    }
  },
  "rules": {
    "no-unused-vars": "off",
    "@typescript-eslint/no-unused-vars": "off",
    "@typescript-eslint/explicit-module-boundary-types": "off",
    "@typescript-eslint/no-non-null-assertion": "off",
    "@typescript-eslint/no-inferrable-types": "off",
    "@next/next/no-img-element": "off",
    "unused-imports/no-unused-imports": "error",
    "unused-imports/no-unused-vars": [
      "warn",
      {
        "vars": "all",
        "varsIgnorePattern": "^_",
        "args": "after-used",
        "argsIgnorePattern": "^_"
      }
    ],

    "no-eq-null": "warn",
    "import/order": [
      "warn",
      {
        "groups": [
          ["builtin", "external"],
          "internal",
          "parent",
          ["sibling", "index"],
          "object"
        ],
        "newlines-between": "always",
        "alphabetize": {
          "order": "asc",
          "caseInsensitive": true
        }
      }
    ],
    "complexity": "warn",
    "no-console": ["error"]
  }
}
```

Then I knew an old friend who told me that he created his own ESLint rules as an npm package. You can see his [here](https://www.npmjs.com/package/eslint-config-sznm/v/0.1.14). Like before, I asked him why he put an effort to create this thing? Simply because when he creates a new project (especially a personal project), he just needs to extend the ESLint rules. No need to rewrite the whole ESLint rules from scratch.

```jsx
module.exports = {
  extends: ['sznm'],
};
```

So, his statement inspires me to create my own ESLint config library.

## Preparation

First thing first, don’t forget to make an empty directory, then run `npm init` or `yarn init`. You can change `eslint-config-test` with your preferred folder name. Remember that `eslint-config` prefix must exist so it can be published at the NPM registry as the ESLint Config library.

```bash
mkdir eslint-config-test
cd eslint-config-test
yarn init
```

You will have `package.json` file like this.

```json
{
  "name": "eslint-config-test",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "",
  "license": "ISC"
}
```

Now, install the dependencies that we’ll use to make our ESLint config. Remember, you don’t have to imitate this 100%. You may have some other preferred tools, that’s okay.

```bash
yarn add @typescript-eslint/eslint-plugin @typescript-eslint/parser eslint eslint-plugin-import eslint-plugin-sonarjs eslint-plugin-unused-imports
```

## Setup The ESLint Rules

Now, you can start to write your own preferred ESLint rules. Start with creating `eslintrc.js` file, then modify it. Here’s mine, you can use it as a reference.

```jsx
module.exports = {
  env: {
    node: true,
  },
  extends: [
    "eslint:recommended",
    "plugin:@typescript-eslint/recommended",
    "plugin:sonarjs/recommended",
  ],
  parser: "@typescript-eslint/parser",
  plugins: ["@typescript-eslint", "import", "unused-imports"],
  settings: {
    "import/resolver": {
      node: {
        extensions: [".js", ".jsx", ".ts", ".tsx"],
        moduleDirectory: ["node_modules", "src/"],
      },
    },
  },
  rules: {
    "no-unused-vars": "off",
    "no-var": "warn",
    "@typescript-eslint/no-unused-vars": "off",
    "unused-imports/no-unused-imports": "error",
    "unused-imports/no-unused-vars": [
      "warn",
      {
        vars: "all",
        varsIgnorePattern: "^_",
        args: "after-used",
        argsIgnorePattern: "^_",
      },
    ],
    "@typescript-eslint/explicit-module-boundary-types": "off",
    "@typescript-eslint/no-non-null-assertion": "off",
    "@typescript-eslint/no-inferrable-types": "off",
    "import/order": [
      "warn",
      {
        groups: [
          ["builtin", "external"],
          "internal",
          "parent",
          ["sibling", "index"],
          "object",
        ],
        "newlines-between": "always",
        alphabetize: {
          order: "asc",
          caseInsensitive: true,
        },
      },
    ],
    complexity: "warn",
    "no-console": ["error"],
  },
};
```

After you finish this step, now you can import it at `index.js` file.

```jsx
const eslintrc = require("./.eslintrc.js");
module.exports = eslintrc;
```

## Publish It To NPM Registry

Yep, technically you can now publish your rules. You can run `npm publish` or `yarn publish`. Then follow the step in the terminal. You can also create an NPM registry account if you don’t have it before.

Now how to use it? When you want to use it, you can easily extend it at your `eslintrc` file in your project folder. Here’s mine, you can access it at [eslint-config-yehezgun](https://www.npmjs.com/package/eslint-config-yehezgun).

## Closing

This tutorial seems short, but it will have a long-term effect on you. You can now just need to adjust the ESLint config that has been published if you want to make some changes, then it will be implemented to all the projects that use the ESLint rules (you have to update the dependencies too).

Thanks for reading, hope it helps.

Reference:

- [eslint-config-sznm](https://www.npmjs.com/package/eslint-config-sznm)
- Freecodecamp blog - [How To Create Your Own ESLint Config Package](https://www.freecodecamp.org/news/creating-your-own-eslint-config-package/)

How To Publish Your ESLint Rules as NPM Package

## Table of contents

- [Disclaimer](#disclaimer)
- [Introduction](#introduction)
- [Fundamental is Crucial](#fundamental-is-crucial)
- [Focus on The Essential Things](#focus-on-the-essential-things)
- [What You Do Now Can Determine Your Future](#what-you-do-now-can-determine-your-future)
- [Environment Matters](#environment-matters)
- [Closing](#closing)

## Disclaimer
> Again this is based on my experience. This story may not be 100% valid and relate to some people. At least this story can be your reference for your career life.

## Introduction
The story began when I just graduated from college in June 2020. That was a challenging moment because the Covid-19 pandemic began to invade the whole world, including my country, Indonesia. Not only that, but my college friends also face the same issue. That was struggling to get a job. I even found several of my friends to work outside the IT (not linear with his degree) world to earn for living.

After several weeks, one by one of my friends get their first job and that made me very anxious about my future. I've tried my best to apply to many companies but the covid-19 pandemic also causes so many hiring freezes. Thank God, in September 2020, with several of my college friends and even juniors, we got a job at a software house company at Gading Serpong. It is just a small company and the office is not too big, but at that time we only think to earn to live because of the pandemic situation no matter the salary or environment.

At that time, I work as a frontend engineer but mainly used Ionic & Angular to develop a hybrid mobile app. That's [KAI Access](https://play.google.com/store/apps/details?id=com.kai.kaiticketing&hl=en_US). To be honest, I don't like this role. I actually prefer to work as a frontend engineer who focused on web development, but because of the situation at that time and I was still a fresh graduate, I still tried to be optimistic that this job may be the suitable one for me.

I was wrong. In June 2021, I got burned out with my job. It even influences my physical body, so I have to take a rest and do WFH even though the company has implemented WFO. I had to work in a job that I don't like for about a year and finally, I realized at that time, that I should find another job.

Luckily an old friend offer me a freelance project, so I joined him to make a warehouse system using React outside of working hours. That is the first time I learn React through a real case project. Since that, I started to like to craft something using React.

In August 2021, I continued to learn React (and Next.js) by myself. The first thing I made using Next.js is my personal web, [yehezgun.com](https://yehezgun.com). It's just a mainstream project actually. But, since I published it on my Linkedin and caused some recruiters to approach me. This made me encouraged and keep posting my other mini-projects or articles about twice a month.

Thank God, in November 2021 a recruiter from my current workplace approached me through Linkedin. I was offered a frontend engineer role, but this time for web development. I continue the recruitment process and finally, here I am now. So happy with my current role, because the environment is very supportive. My current manager also supports the employees if they have some activities outside primary work like joining the devs community or being a course instructor.

For about a year (almost 2 years exactly😂), I learned so many things from getting my first full-time job, going through burnout, and getting a better job. Like a retrospective session, I'll share 4 primary points related to my previous story.

## Fundamental is Crucial
I've written about this before in my previous article [Why Fundamental Matters?](https://yehezgun.com/articles/why-fundamental-matters). This made me realize that I should strengthen the fundamental things before going further.

Back in the old days when I learn frontend development prematurely, I directly jump into tools and frameworks like React, Angular, and Vue without learning the Javascript basics first. I got my first job and it uses Angular (Ionic) as the main tech stack. Struggled enough when I have to handle some issues that cannot be resolved with any help from the third-party library, so I had to create the logic by myself.

Another problem is when I joined my current workplace in January 2022. I have to relearn Javascript basics because I have to use React as my main tech stack. Not only that, I even have to understand the CSS basics because I work on a project that uses Tailwind CSS for styling purposes.

> If only I have a solid understanding of the basics and fundamental things, it's not a big problem when I have to use tools or frameworks. I just need to adapt to the syntax and don't need to re-learn everything.

## Focus on The Essential Things
I don't know if it is just me or if someone else who also feels the same thing that the more experience we got in the real industry work, the more we realized that we need to choose wisely what tools or frameworks can solve the problem.

For example, I've learned Angular for a long time since I was a college student until I worked in my first workplace at a software house. At first, I think that Angular is easy because with the CLI feature I can generate pages and components easily, and it's an imperative paradigm.

Everything changes when I've worked for around 6 months and realized that the community support for Angular is quite rare and it's hard to find the related or relevant solution when doing some troubleshooting. So because of that, I even made some logic by myself from scratch😵. Not only that but when I was searching for a new job the common market required React as the main tech stack skill.

I actually mentioned it in my previous article about [Frontend Fatigue](https://yehezgun.com/articles/frontend-fatigue). I should choose a framework that has proven, has huge community support and of course, it can help me to solve the problem that I want to solve.

> Focus on problem-solving. Choose the right and suitable tools that can help us to solve the problem, not make it heavier😂.

## What You Do Now Can Determine Your Future
I still remember when I started a habit to publish the article routinely at the beginning of 2021. At first, I post articles in Indonesian (Bahasa) at [diskusi.tech](https://diskusi.tech/yehezkielgunawan). Not a hard topic, I just share my experience and how to handle the problem that I've faced.

In the middle of 2021, I started to build my own personal website, [yehezgun. com](https://yehezgun.com). At that time, I started to expand my English writing skill and post some articles in English. Not only that, I also keep making and publishing some mini projects on my personal website.

It took about six months until I was finally approached by some recruiters and finally I can get my current job because of that habit. I've mentioned it in my previous article about [How To Get Hired Without Applying](https://yehezgun.com/articles/how-to-get-hired-without-applying).

Not only my personal portfolio, but I also joined as a volunteer (cloud advisor) at Bangkit Academy. That's beyond my expertise and experience actually, because I didn't have any cloud computing background but I have to guide my students to learn about cloud engineering🤯. But don't get me wrong, with this experience I learn twice. I learn for myself, then I learn to deliver the material to my student so they can understand what they learn. This affects my career so much and helps me to understand the cloud-related things in my current job even though I'm just a frontend engineer.

> Remember that the current version of yourself is built and developed by your previous version of yourself too.

## Environment Matters
At first, I think working at a software house can be fun because I can learn so many things through the projects that exist, but I was wrong. The project that I handled is based on the client's request and most of them "cannot be interrupted or adjusted". If the client says A, I have to deliver it as A, not B.

The other problem is there's no proper code pattern. A lot of projects but each of them has its own code style and doesn't have a standardized code. When I have to deal with a project that I don't usually work on, I need a longer time just to understand the flow and how the code works.

This made me realize, that I should work at an in-house company that has a dedicated product that usually has a standardized and proper development pattern. Finally, in November 2021, I resigned from my previous workplace and join my current workplace in January 2022.

Working on a dedicated product is like you're adding a new puzzle piece to the existing puzzle board. Of course, because of that, the codes that are produced must be standardized and have the proper pattern so the quality of the product still can be maintained. But in my case, I got a project that has to rewrite the whole landing page from Vue to Next.js😁, but because of it, I can learn while working on it, especially about Next.js which is my current favorite go-to framework.

The most interesting part is finally I have the seniors that can be my career mentor. This is the first time I can have a real mentor in my life. When I was stuck on my task, I can ask them for help with what approach I can use to solve the problem. Even though we work remotely, we can still communicate properly through G Meet or Slack Chat. For me, this is the best work culture that can help me to grow.

> Culture fit is real. It helps a person to grow and become better from time to time.

## Closing
So yeah, this is my story. Feels like a career retrospective right? I hope this can give you a new insight from the (not really😂) experienced frontend engineer perspective.


Retrospective: After One Year Working as a Frontend Engineer

## Table of contents

- [Disclaimer](#disclaimer)
- [Introduction](#introduction)
- [Why Fundamental Matters?](#why-fundamental-matters)
  - [Imagine Struggling At A Job Which Not Use Your Preferred Framework](#imagine-struggling-at-a-job-which-not-use-your-preferred-framework)
  - [Soon or Later You Cannot Rely on Tools Anymore](#soon-or-later-you-cannot-rely-on-tools-anymore)
- [How To Cope or Deal With It?](#how-to-cope-or-deal-with-it)
  - [Re-learn Again From Scratch](#re-learn-again-from-scratch)
  - [Learn a Tools or Framework That Push You To Understand The Basics While Using It](#learn-a-tools-or-framework-that-push-you-to-understand-the-basics-while-using-it)
- [Closing](#closing)

## Disclaimer

> Like previous articles, this is just based on my experiences and some of my friend's stories. Maybe you have a different story, but at least this story can be a reference for you.

## Introduction

The story began when I was graduated in June 2020 and struggled a lot on finding a job. I skipped the fundamental one and learn the frontend frameworks like React, Vue, and Angular. It is kinda hard to pass the user interview session which uses the live coding interview method, because they usually ask the basic question and solve it fast without using any framework or tool, just with plain Javascript at that time.

But it doesn’t bother me too much because I got my first job as a frontend engineer at my previous workplace (a software house company) in September 2020. At that time I use [Ionic](https://ionicframework.com/) and Angular as the main tech stack. I rarely code custom CSS for about a year, because the built-in UI from Ionic is so fascinating and it’s more than enough to deliver the required app to the client.

The new problem appears when I didn’t want to extend my contract there because I want to search for another opportunity to grow. Then I experienced the same problem as what I’ve done in 2020. Mostly I failed on user interview sessions that implement the live coding test.

After struggling a lot, by the grace of God, finally, I can get my current job in December 2021 (onboard on January 2022). Luckily the entrance test is a take-home test so I can maximize my ability. The user interview session did well and I’ve decided to choose this place as my next career journey.

Then another problem appears. For the first three months, I’ve been given some tasks related to styling things. I have no problem when coding the code for integration purposes like fetching data or data manipulation. But styling-related task actually is my greatest weakness.

Like I’ve told you in my previous article titled “[I Remake My Personal Site using Tailwind CSS](https://yehezgun.com/articles/remake-using-tailwind-css)”, I was too dependent on tools, library, or framework. In this case, I was too dependent on styling tools like Chakra UI. I can make the styling using Chakra UI, but when I have to deal with another tool that is not my preference, I struggled much.

That time, I even struggled to make a simple layout for several hours using custom CSS and Tailwind CSS, LOL. This is why I realized, the fundamentals should be not skipped before you jump into tools like Chakra UI, Bootstrap, or other tools.

After about 3 months of struggling with the basic things, here is my reason why you should start or even restart with the fundamentals before going further.

## Why Fundamental Matters?

### Imagine Struggling At A Job Which Not Use Your Preferred Framework

This is what has happened to me actually😆. So in short, I skipped the fundamental of Javascript and CSS and directly jump into React, Next.js, and Chakra UI. 

When I got my first job as a frontend engineer, I got a project which use Ionic and Angular as the main tech stack. For the first three months, I struggled with Ionic and Angular syntax. But luckily I didn’t struggle much when doing some styling because Ionic has provided a nice base UI, so I usually just do some minor styling like changing color or just the font family.

About one year later, I quit that job and found a new opportunity. While finding a job again, I back to my old bad habit, directly learning React and Chakra UI without learning the fundamentals, and successfully created [my own personal site](https://yehezgun.com/). Shortly, I finally can get my current job as a frontend engineer at the new company.

Luckily I code using React and Next.js in my current workplace so I didn’t struggle much for the logic things. But for styling purposes, I have to use Tailwind CSS. As a UI Component user who switches to utility class tool, that’s very “horror” for me, because I have to understand CSS basics when I made some styling.

During the probation period, I struggled a lot with these styling-related things😫. I even need several hours just to make a simple layout for the website. Luckily, along with the time I also learn Tailwind CSS in my free time and can cope with it. You can read my article [here](https://yehezgun.com/articles/remake-using-tailwind-css) which contains my experience when learning Tailwind CSS.

Okay, do you realize something here? **You can directly jump into the framework or library without learning the fundamentals. That’s not a big problem until you got a job which not use your preferred framework. You will struggle a lot to adapt to it because there’s no core concept or solid understanding of it.**

### Soon or Later You Cannot Rely on Tools Anymore

When I’m still a frontend engineer at my previous company, I was too dependent on third-party tools almost for every single task like making a timer and even displaying the formatted date. I was ever given a task by my former manager to display the map on the mobile app. At that time the only thing that existed in my mind is I have to find a suitable third party that can be used for that case.

Several days later, finally I found the [Angular Google Maps](https://angular-maps.com/) library and luckily can solve the problem for a while. But the new problem appears when the client asks for some customization. That’s the first thing that has made me sick for several days just to customize the layout of the displayed map. It’s easy to initialize and integrate, but again third-party tools are usually hard to customize.

The second case is when I got my current job. I discussed with the UI/UX team about the new website project that will be developed. The manager proposes the tools that can be used for the styling purpose. But in the end, we decided to use Tailwind CSS (a utility class styling framework), because **we need a customizable tool** and **if the tool cannot be customized, we have to make our own tool to solve the problem.**

My manager also said the same thing in my probation review statement.

> Strengthen your fundamental understanding of CSS. One day you can’t rely on tools anymore.
> 

## How To Cope or Deal With It?

How to deal with it? What if I’m already like you, skipped the fundamentals, and rely on tools?

Don’t worry there’s still hope here, LOL. I even still struggle with this thing. But here are some tips from me. I even still doing these even I’m a full-time employee now and it’s very helpful for me.

### Re-learn From Scratch

If you have free time outside your main job, please spare time just to learn the basics again. You can learn from any sites like [Freecodecamp](https://www.freecodecamp.org/) or [Hackerrank](https://www.hackerrank.com/) to push yourself re-learn the basics through the coding challenges. If you’re a frontend engineer and want to sharpen your understanding of flexbox, you can try [Flexbox Froggy Game](https://flexboxfroggy.com/). It’s a free web-based game that can help you to learn about flexbox through its gameplay.

In my case, it’s hard to find a suitable time for learning again from scratch because I’ve struggled in finding a job and need it quickly (when I was a job seeker). And now, still hard to find it because I’m a full-time frontend engineer in my current workplace. But it doesn’t mean I can’t learn the basics.

In my free time, I usually follow [Kevin Powel](https://twitter.com/KevinJPowell) on Twitter and watch some of his videos on Youtube to sharpen my concept and understanding of basic CSS. If finding suitable free time to learn is hard for you, at least push yourself to learn the basic concept by reading the official docs like [MDN](https://developer.mozilla.org/en-US/docs/Web/CSS) or watching some youtube videos that explain more about the basics.

### Learn a Tools or Framework That Push You To Understand The Basics While Using It

For me, this tip is very useful. When I have not much time to re-learn the basic, I choose a tool or framework that force me to understand the basics while using it. Like I’ve said before in my previous article [here](https://yehezgun.com/articles/remake-using-tailwind-css), I found it when I’m using Tailwind CSS.

Even I’m not using the CSS syntaxes directly but I can learn and understand the basic CSS concepts through Tailwind syntaxes. To produce good and effective “styling” codes, I have to understand basic concepts like flex, grid, margin, padding, and other CSS concepts.

This also works when I code in React. Even React is a Javascript library, but it contains Javascript syntax which made the developer must face and sharpen the basics first before going through.  I have even re-learn basic [Javascript syntax](https://dev.to/nsebhastian/javascript-basics-before-you-learn-react-38en) so I can produce clean and effective code in React. 

Luckily, my current workplace also uses React and Tailwind CSS as the main tech stack so I can use my work time to work on the task and learn new things through it😁.

## Closing

> **Learn the basics first before jumping into the framework or tools.** It will make your path smooth. You can easily solve any problems that you’ll face because you understand the concept, not only the tools that be used.

Soon or later you cannot rely on tools anymore. I’ve experienced it before when I was developing Map Feature for [KAI Access](https://play.google.com/store/apps/details?id=com.kai.kaiticketing&gl=US) and it was very exhausting for me just to find the suitable tools that actually have deprecated.

You’ll also struggle a lot to find a new job because nowadays most companies implement live code interviews or “agnostic” test cases for the programmer candidate. I even failed so many technical interviews before due to a lack of basic skills.

But don’t worry, keep learning. Don’t fear missing out (FOMO). I know so many frameworks and tools out there. You can read my article about Frontend Fatigue for more details, hope it helps you to determine the suitable tools for you.

But anyway again, **learn the basics first!** I know this method will make you seem like a slow learner. **It’s better to be a slow learner with solid understanding than you force yourself to learn everything and be burnout and exhausted.** Learning is a marathon, not a sprint.

Thank you for reading my article, hope it helps. Let me know if there’s something that you want to discuss in the comment section below.

Why Fundamental Matters?

## Table of contents

- [Disclaimer](#disclaimer)
- [Introduction](#introduction)
- [I Learn CSS Basics While Using Tailwind CSS](#i-learn-css-basics-while-using-tailwind-css)
- [Very Customizable](#very-customizable)
- [I Can Maximize The Use of HTML5 Tags](#i-can-maximize-the-use-of-html5-tags)
- [Closing](#closing)

## Disclaimer

> This post may seem opinionated. I just share why I finally move to Tailwind CSS as my main CSS utility tool.

## Introduction

So, previously I used Chakra UI for my personal site [yehezgun.com](https://yehezgun.com). Everything changes when I got a new full-time job as a frontend engineer in my current company. I realized that I’m too dependent on the development tools like UI libraries and some npm registry packages.

I was ever given a task to fix some layouts using native or vanilla CSS and it took about 2 hours for me just to give some styling for a static page. I realized I have to strengthen my fundamental skill again before going further.

Then I found that [Tailwind CSS](https://tailwindcss.com/) is interesting, so I started to create my own [Next.js + TS + Tailwind CSS Starter Template](https://nexttw-starter.yehezgun.com/). Thanks to [Theodorus Clarence](https://theodorusclarence.com/), his starter template helps me a lot to re-create this template on my own. I use his idea and components splitting concepts and modified them based on my current needs.

I don’t say that Chakra UI is bad. Actually, it helps me a lot if I’m developing a site with a short deadline because it increases productivity. But for learning purposes, I prefer Tailwind CSS. Here are whys I finally use Tailwind CSS for my future personal projects.

## I Learn CSS Basics While Using Tailwind CSS

Tailwind CSS is not UI Component, it is a utility-first framework for styling purposes. When we work with Bootstrap, Chakra UI, or other UI Component libraries, we just set for example class `btn` if we want to make a button component or just set `<Button></Button>` (usually in React UI Libraries).

But in Tailwind CSS, I have to style the component from scratch as I did with plain CSS, but I can completely custom designs in the HTML class name. For me, it feels like writing the inline CSS styles but is a more elegant and much cleaner way.

Code Example:

```html
<button class="bg-sky-600 py-1 px-2 rounded-md">
  Save changes
</button>
```

If I want to add a hover effect, I just add `hover:bg-sky-700` in the class name.

Notice something?

I realized that when I’m using Tailwind CSS, I also feel pushed to re-learn the CSS fundamentals again after a long time, LOL. This is interesting when I made a custom styling with Tailwind, I have to know which styling concept I have to use even I didn’t use the original CSS syntaxes.

For example, when I want to create a layout like below. When I use the UI component like Chakra UI, I can easily use the Flex component and add some gaps and spacing using its props. But when I use Tailwind, I have to set my own flex, flex item, spacing. And of course, I have to custom the buttons below by myself using Tailwind.

![example](https://res.cloudinary.com/yehez/image/upload/v1647335347/Articles/I%20Remake%20My%20Personal%20Site%20using%20Tailwind/Yehez_Example_dljekw.png)

This is very good for me. When I was finding a new job last year, I was interviewed by some users of the companies and they said the same thing, “You’re really good using these tools. But we need an employee who can write and understand the basics. In this case, that’s plain CSS because we still use it in our systems.”

I’ve read [Theodorus Clarence’s docs site](https://docs.thcl.dev/styling/css-scss), he stated that you have to cover the fundamental of CSS before jumping into frameworks like Bootstrap, Chakra UI, or even Tailwind CSS. And this is very true. In my case, I was often rejected by the recruiter when I have to live code using plain CSS. That’s very embarrassing for me, LOL.

As a full-time worker and has graduated almost two years ago from college, I need to find an effective learning method so I can adapt to the current situation and deliver it fast. Actually, I can learn CSS from scratch, but it takes a too long time and I need a job fast at that time when I was a job seeker.

Until I found Tailwind CSS and yeah as I said before, I can learn the basic CSS through every Tailwind syntaxes.

## Very Customizable

Because Tailwind CSS is a utility-first framework, you can fully customize every page or component in your website. You even can make your own design system if you want using Tailwind CSS.

Have you seen Theodorus Clarence’s [Next.js + Tailwind CSS Starter Template](https://github.com/theodorusclarence/ts-nextjs-tailwind-starter)? For me, it’s like a mini design system packed as a starter template. This inspired me to make a similar template of mine, so when I want to create a new project, I can generate it from the starter template and don’t have to worry about the base config or style and of course, I can be more focused on the development process.

This thing made me realize that I have full control when styling the website using Tailwind CSS.

## I Can Maximize The Use of HTML5 Tags

This is very opinionated actually, LOL. But when using Tailwind, I can maximize the use and understanding of HTML5 tags.

Like the first point explanation, when I use the base HTML5 tags, I actually learn about the structure of HTML5 and what’s the best practice that I can implement when creating the web structure.

And like many people said, using proper HTML5 tags can also increase the SEO percentage. You can read the article [here](https://www.greengeeks.com/blog/html-tags-for-seo/).

## Closing

> If you found that learning the fundamentals takes a long time for you, learn and use a tool, library, or framework that forces you to understand the fundamentals through its features.
> 

As full-time workers or job seekers who graduated from college, we have to find an effective learning method, because we’re racing against time, especially when we need a new job fast. Learning from scratch is sometimes too exhausting and we need more time for that.

This is why we have to choose what tools, library, or framework wisely. Choose those that push you to understand the basics while you using them. In my case, Tailwind CSS is very helpful for me to understand the basic CSS syntaxes while I’m using it through its syntaxes.

I hope you can also learn something from these articles, I’m still an amateur in this. Feel free to have some discussions, you can write it in the comment section below.

References:

- [Theodorus Clarence’s Docs Site](https://docs.thcl.dev/styling/css-scss)
- Theodorus Clarence’s [Next.js + Tailwind CSS Starter Template](https://github.com/theodorusclarence/ts-nextjs-tailwind-starter)

I Remake My Personal Site using Tailwind CSS

## Table of contents

- [Disclaimer](#disclaimer)
- [Introduction](#introduction)
- [Preparing The Account](#preparing-the-account)
- [Setup Supabase](#setup-supabase)
- [Deploy on Vercel](#deploy-on-vercel)
- [Configuring Your Umami](#configuring-your-umami)
- [Adding Umami to Your Website](#adding-umami-to-your-website)
- [Closing](#closing)

## Disclaimer

> In this article, I will focus on how to self-host and set up Umami, then integrate it into the Next.js-based project.

## Introduction

Often, when someone or organization wants to set up the web analytics tool, they usually use [Google Analytics](https://analytics.withgoogle.com/). But as some people know that we cannot collect real data because when there’s a person visit a website and he or she set an adblocker in their browser, the analytic tool cannot work properly. And of course, there’s also a privacy issue with this tool.

Alright so are there any alternatives? Yes, I’ll recommend [Umami](https://umami.is/docs/about). Why? According to its official docs, Umami is open source and can be the privacy-focused alternative to Google Analytics.

![Umami Web](https://umami.is/about-screenshot.png)

Okay, so let’s jump to the main point. How to set up and self-host Umami? In this article, I’ll explain how to set up Umami with Vercel and Supabase.

## Preparing The Account

First, of course, make sure you already have a [Github](https://github.com/join) account. If you don’t have it yet, please make it first because it will be needed to deploy our self-host Umami. 

After you have a Github account, make sure you also registered at [Vercel](https://vercel.com/signup) and [Supabase](https://supabase.com/).

## Setup Supabase

Now, you can log in to [Supabase](https://supabase.com/) and go to the main dashboard and click “New Project”. Use the organization and project’s name based on your preferences and needs.


![New Project](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/l9nt4fhzvcwl8vi220o8.png)

Fill in the form fields based on your personal preferences. Also, select the closest region to your domicile in the region form field.


![NewProjectForm](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/yaqc6mupm8jbg7j8vjcr.png)

## Deploy on Vercel

You can easily deploy Umami to Vercel just by open [Umami’s Docs (Running on Vercel section)](https://umami.is/docs/running-on-vercel) and clicking the “Deploy” Button. Then, you can select Github and fill in the repository name and after that, you can just follow the default steps.

If you have reached the step like the image below, head back for a while to Supabase.


![Deploy Vercel](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/6f42lu9gpqrzufuaege9.png)

In Supabase, go to the Settings menu and then click the “Database” section. Go to the “Connection String” segment. Select “URI” and copy & paste it to DATABASE_URL on your Vercel settings. Don’t forget to change “YOUR_PASSWORD” into your own Supabase database password.


![Connection String](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/218qfkelkvksn2we94pm.png)


![Configure Project Vercel](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/6rquvx2g1wcr963a68m3.png)

For the HASH_SALT field, you can use [Password Generator](https://passwords-generator.org/) to generate some random string and copy & paste it. After that, you can deploy it to Vercel.

If you want to change the domain after the deploy process, you can go to the project settings and select the Domain menu, then click the “Edit” button.


![Vercel Change Domain](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/3qs3w6t786wqs90qmf7u.png)

## Configuring Your Umami

Now you can open the deployed Umami on your browser. The default username is `admin` and the password is `umami`. You can change it later if you want. You can go to the Settings menu and go to the profile section to change your current password.


![Umami Change Password](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/qh0mmgv1vez4d131i644.png)

## Adding Umami to Your Website

In the Settings menu, go to the Website section and click “Add Website” Button. You can add your website name and link there and enable the “Share URL” if you want.

After the website is added, you can copy the “Tracking Code”. You can paste it into your project soon.


![Add Umami to Your Site](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/kk14xtn5wg1nld327z58.png)

Now for the final step, go to your web project folder. In my case, I use Next.js and I paste the code in the `_document.tsx` file.


![Next JS Integrate](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/l6yyeu9g78ae0w3mbdk6.png)

And yeah, congratulations! You just need to push the newest commit of your project and you can watch the statistics of your own site at Umami. The statistics will appear on your Umami dashboard within 24 hours.

## Closing

You can follow these same steps on your other projects. Hope it helps. Let me know if you have some feedback or something to discuss in the comment section.

Reference: [How to Setup Umami with Vercel and Supabase (by Jacob Bouchard)](https://dev.to/jakobbouchard/setting-up-umami-with-vercel-and-supabase-3a73)

How to Setup and Integrate Umami to Your Next.js Site

## Table of contents

- [Disclaimer](#disclaimer)
- [Introduction](#introduction)
  - [Back to Fundamentals](#back-to-fundamentals)
  - [Learn The Framework Philosophy](#learn-the-framework-philosophy)
  - [Create Projects](#create-projects)
  - [Code Reviews](#code-reviews)
- [Closing](#closing)

## Disclaimer

> Again, this is just based on my experience as a front-end engineer. You maybe have a different experience or context when you read this, but at least it can give you some reference for your career.

## Introduction

The story began when I was working as a frontend engineer at my first workplace using Angular at that time. At first, I enjoyed Angular but it changed when I want to switch jobs in the mid of 2021. Most of the job vacancies required React as the main skillset. After that, I change my mind and take a maneuver from Angular to React as my main frontend tech stack.

Not only that, when I did some troubleshooting or debugging I need more time to google some stuff if I code using Angular. It’s very different when I use React, I just enter some keywords and the search result will display more accurately based on my needs. This lasted for about almost one year until I finally realized it was time for me to change.

Actually, most of the frontend frameworks still use Javascript (or Typescript) as the main programming language. The main difference is the approach implemented in each framework. This is what I did to overcome and I still do this until now. There are still many things that I don’t understand yet about React, but when I did this, it helps me and I can get a new job because of it. Hope it can help you.

### Back to Fundamentals

React, Angular, Vue, and Svelte are using Javascript (or Typescript) as the main programming language. The main difference is only the approach in each framework. **So it will be easier to back to the basics first, learn Javascript fundamentals before switching to another framework.** 

The framework can change over time, even in just months you maybe need to re-learn it again. If you skip the fundamentals, it will be hard to switch to another framework. Having a solid fundamental Javascript skill can make learning some frameworks easier and faster. You just need to adjust the related syntax according to the framework.

In my case when switching to React, mostly I have to learn Javascript again because as I know React contains more Javascript syntax and logic. Very different when I use Angular, everything can be done with its CLI and default config. I have to make my own custom config while using React.

A site like [freecodecamp.org](http://freecodecamp.org) and [hackerrank.com](http://hackerrank.com) is very helpful for me. I can re-learn Javascript syntax and features through it and train my problem-solving skill.

### Learn The Framework Philosophy

This is the most important part after you learn the basics. Before jumping into any frameworks, you have to discover its philosophy. Why? **Because you have to know how it works, why the founder made the framework, and what problem this framework wants to solve.**

Actually, I skipped this part about the first 3 months when I learn React, LOL. When I face some issues, it takes more time for me to discover what is the main problem of that issue because I didn’t know how it works. I often produced dirty code because I don’t know the best practice for this that time.

Luckily, I follow [Theodorus Clarence](https://twitter.com/th_clarence) on Twitter and he amazingly often tweet some basic things about React (and Next.js). I even just realized some basic things like state management and React DOM after about 6 months of learning and using React, LOL. Why didn’t start earlier, LOL. This is why you should follow useful accounts like him. It can give some new insight even through some simple tweets or tips and tricks.

A friend of mine also gave me a Github repo that contains the explanation of React Philosophies. It can be accessed at [React Philosophies](https://github.com/mithi/react-philosophies). I still processing this, too many things to understand but now at least I can understand some best practices that I can implement by myself.

### Create Projects

**Remember that programming is about problem-solving**. You cannot learn programming just by watching tutorials on Youtube. You have to try it by yourself.

You don’t need to create a complex project, just create a simple one and you can use it by yourself. For example, I created a [simple food app using React + Line Frontend Framework (LIFF) app](https://liff-de-mangan.vercel.app/). It just sends the food list that you’ve selected through LINE Browser. And through this, I can understand how the LIFF Framework works and can be used if I need it.

There’s a term called “Tutorial Hell”. It usually happens you read or watch some tutorials and you feel that you have understood all the material, but there will be great confusion when you try it by yourself. I ever experienced this, but I overcome it by directly creating a project using a framework that I want to learn.

For example, instead of learning React, I’d rather create some projects using React and its supporting libraries.

### Code Reviews

When you finished your projects, don’t stop there. Review it by yourself or by your friends. **Note that every programmer has their own blindspot so maybe there are some things that are missed when you create the project.**

I remember when I worked on my first freelance project using React, I always ask my frontend friend to review my code before merging it at the GitLab Repository. At that time, the code that I made worked properly, but sometimes my friend found that there were some parts that can be improved or made more readable. 

Many may ask, how to produce better code? In my opinion, you have to regularly do some code review, either review it by yourself or ask your friend to review it. **Experience never lies, you will know the right thing after you do or see the wrong ones.**

## Closing

So yeah this is my story when I switched to React. I know maybe some of you have different contexts or testimonies, but I hope this can inspire and even help you if you want to switch to another framework. Let me know if there’s something that wants to be discussed.

This is How I Switch from Angular to React

## Table of contents

- [Disclaimer](#disclaimer)
- [Introduction](#introduction)
- [Why We Need Standardization In Our Project Source Code?](#why-we-need-standardization-in-our-project-source-code)
  - [Every Team Member Has Their Own Code Style](#every-team-member-has-their-own-code-style)
  - [To Increase Maintainability and Readability](#to-increase-maintainability-and-readability)
  - [Not Only Code but Commit Message Also Need To Be Standardized](#not-only-code-but-commit-message-also-need-to-be-standardized)
- [How To Standardize The Project Source Code?](#how-to-standardize-the-project-source-code)
  - [Prettier Configuration](#prettier-configuration)
  - [Configure The Base ESLint Rules](#configure-the-base-eslint-rules)
  - [Configure Husky Base Setting](#configure-husky-base-setting)
- [Closing](#closing)

## Disclaimer

> In this article, I’ll focus on Next.js (using Typescript) based project. You can adapt it to your own needs based on your project source code and the problem that you’ve faced.

## Introduction

Based on my experience in the software development world, Javascript (and Typescript) is the “wildest” programming language. We can use any code styles or conventions by our own preference in every project if we use Javascript.

When I work on a personal project, actually it’s not a big problem because I code for myself and only me who know the code, LOL. But imagine this, how if I have to work in a team with several people and each of them has their own code style? BOOOM, it will be chaos right?

This is just a simple reason why we need a standardized convention in our project source code as software engineers. I think it’s a common problem that needs to be reminded so as a developer we have to keep our code structure clean as has been set.

## Why We Need Standardization In Our Project Source Code?

Before we go too far, I think we have to start with “why” first. Why do we need the standardized convention in our code? Here’re the whys.

### Every Team Member Has Their Own Code Style

Like I’ve told in the Introduction section when I was making my personal projects, I code for myself so maybe I can use whatever code style I like. But everything changes when I have a full-time job and have to work in a team with several people. Every team member has their own code style and it may be confusing when I got a task and need to understand someone’s code that has a very different style.

Not only me actually, when other teammates read my code, they were also confused with my code style, LOL. **This is why we need to make an “agreement” so we can use a consistent code style in our code base.**

### To Increase Maintainability and Readability

I have been worked at a software house company that has a project-based work culture. Our task is finished when the requested app is delivered to the client.

I was a newbie junior frontend engineer at that time and I code with barbaric style. In my mind, I just have to finish and deliver it to the client before the deadline. That was a dark moment in my career life, hahaha.

The situation changes when I switch jobs to another company and now I’m working in an in-house company that has their own product that needs to be developed. The main focus is change now.

In the previous company, my main focus is just to code and deliver. But in the current company, I also have to think about how to make my code is maintainable so it will be easier to be improved or updated when needed.

The answer is quite simple, make and follow the code convention so the code style in the project code base is consistent even it was developed by different people. **The consistent code style makes it readable, and if it’s readable, it will be easier to be maintained.**

### Not Only Code but Commit Message Also Need To Be Standardized

When working with a team, it’s important to tell the informative message when pushing a commit to the Github (or Gitlab) repository. **The best code style is useless if the commit message is bad.** Other team members don’t understand the changes that you’ve made, and it can cause confusion and chaos in the future.

Thankfully, there’s [Conventional Commit](https://www.conventionalcommits.org/en/v1.0.0/) that can help the developers to make a proper commit message before they push their code to the Git Repository. 

## How To Standardize The Project Source Code?

I’ll tell you based on my experience as a front-end engineer. Luckily there are some tools that can help us to make the code convention. Here’s what I usually use.  

- [Prettier](https://prettier.io/) (Code Formatter)
- [ESLint](https://eslint.org/) (Linter for JS-based project)
- [Next Lint](https://nextjs.org/docs/basic-features/eslint) (built-in linter for Next.js)
- [Husky](https://github.com/typicode/husky) (automated linter trigger)
- [Lint Staged](https://github.com/okonet/lint-staged) (run linter before commit)
- [Commit Lint](https://commitlint.js.org/#/) (check the commit message before committing)

> For giving an example purpose, I’ve prepared a simple Next.js (Typescript) project. You can use [next-tailwind-polos](https://github.com/yehezkielgunawan/next-tailwind-polos) if you want to try to standardize the source code using those tools. You can clone it to your local device and don’t forget to install the dependencies using `yarn` or `npm install`

Here’s what we’ll do in the next section:

- Configure [Prettier](https://prettier.io/docs/en/install.html)
- Configure base [ESLint](https://bobobox.atlassian.net/wiki/spaces/BD/pages/2520154113/Frontend+Recommended+Code+Style+Guide+React+Based#In-Next.js-Project-[TYPESCRIPT-Based]) rules
- Install & configure the base [husky](https://typicode.github.io/husky/#/) setting (*Reference: Husky setting [Yehez-Tailwind-Starter](https://github.com/yehezkielgunawan/yehezgun-new/tree/main/.husky)*)
- Install & configure [lint-staged](https://github.com/okonet/lint-staged) and [commitlint](https://commitlint.js.org/#/guides-local-setup)

> In the steps below I’ll use yarn, actually, you can just adapt it by your preference if you use npm. You can see the official docs so you can match them by your need.

### Prettier Configuration

I assume that you’ve already cloned the example project source code, so I will focus on the tool's functionality.

Make sure you’re open the project folder through VS Code or your terminal, then run `yarn add --dev --exact prettier`. Then create a file named `.prettierrc.json` in the root folder, or you can just run `echo {}> .prettierrc.json` in your terminal.

In the `.prettierrc.json` file, you can fill the configuration like below or you can fill it by your needs (reference: [Prettier Config Options](https://prettier.io/docs/en/options.html)).

```json
{
  "endOfLine": "lf",
  "semi": true,
  "singleQuote": false,
  "tabWidth": 2,
  "trailingComma": "es5"
}
```

Now, you can just run `yarn prettier --write [directory scope]` to format your code. Or if you use VS Code, you can set **Format on Save** in your VS Code Settings. You also can use the shortcut to manually format the file (using VS Code) by pressing `Shift + Option + F` (in MacBook) or `Shift + CTRL + F` (in Windows).

### Configure The Base ESLint Rules

Because we use Next.js we will use [ESLint for Next.js](https://nextjs.org/docs/basic-features/eslint). But luckily in the newest Next.js version, it has automatically installed when we initiate the project. So in this case, we just focus on the `eslintrc.json` file wherein the root project.

But make sure, the `lint` command exists in the `package.json` file.

```json
"scripts": {
    "dev": "next dev",
    "build": "next build",
    "start": "next start",
    "lint": "next lint"
  }
...
```

Here are my ESLint rules in `eslintrc.json`. You don’t have to imitate this 100%, just match it by your own preference or current needs.

```json
{
  "env": {
    "node": true
  },
  "extends": [
    "next/core-web-vitals",
    "eslint:recommended",
    "plugin:@typescript-eslint/recommended"
  ],
  "parser": "@typescript-eslint/parser",
  "plugins": ["import", "unused-imports", "@typescript-eslint"],
  "settings": {
    "import/resolver": {
      "node": {
        "extensions": [".js", ".jsx", ".ts", ".tsx"],
        "moduleDirectory": ["node_modules", "src/"]
      }
    }
  },
  "rules": {
    "no-unused-vars": "off",
    "@typescript-eslint/no-unused-vars": "off",
    "@typescript-eslint/explicit-module-boundary-types": "off",
    "@typescript-eslint/no-non-null-assertion": "off",
    "@typescript-eslint/no-inferrable-types": "off",
    "@next/next/no-img-element": "off",
    "unused-imports/no-unused-imports": "error",
    "unused-imports/no-unused-vars": [
      "warn",
      {
        "vars": "all",
        "varsIgnorePattern": "^_",
        "args": "after-used",
        "argsIgnorePattern": "^_"
      }
    ],

    "no-eq-null": "warn",
    "import/order": [
      "warn",
      {
        "groups": [
          ["builtin", "external"],
          "internal",
          "parent",
          ["sibling", "index"],
          "object"
        ],
        "newlines-between": "always",
        "alphabetize": {
          "order": "asc",
          "caseInsensitive": true
        }
      }
    ],
    "complexity": "warn",
    "no-console": ["error"]
  }
}
```

In this case, I use third-party ESLint plugins like [import](https://www.npmjs.com/package/eslint-plugin-import), [unused-import](https://www.npmjs.com/package/eslint-plugin-unused-imports), and [typescript-eslint](https://www.npmjs.com/package/@typescript-eslint/eslint-plugin).

After the config process is finished, you can run `yarn lint` to check if your code is already matched with the ESLint rules or not. You can also run `yarn lint --fix` to automatically fix your code based on the rules that have been set. Remember that sometimes we need to manually edit the code, so don’t overly rely on the automated fixing code.

### Configure Husky Base Setting

Want some automation addition? I usually use [Husky](https://typicode.github.io/husky/#/) to automate the checking process before committing or pushing to the Github Repository.

Because we’re using yarn, we’ll install it by running `npx husky-init && yarn` in the terminal. It will automatically generate the `prepare` command in `package.json` and a base pre-commit config.


![husky install](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/mow4oovc9qxz5omym7vt.gif)

After that, we’ll install the [Lint Staged](https://github.com/okonet/lint-staged) to trigger and run lines on git staged files by executing `npx mrm@2 lint-staged`. It will automatically generate the base command triggers in `pre-commit` husky config file. After that, you can delete or modify the content by your own preference. After that, it will run the linter before the commit process. So you have to make sure that your code is matched with the linter rules.


![Lint staged install](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/tjua26xupptx6ldnzm8u.gif)

Like I’ve mentioned before, not only code, we also need to standardize our commit message before pushing it to the Github repository. So we’ll set [Commit Lint](https://commitlint.js.org/#/guides-local-setup) by executing `yarn add --dev @commitlint/config-conventional @commitlint/cli` in the terminal.

Don’t forget to set the commitlint config as our base commit config by running this command in the terminal.

```bash
echo "module.exports = { extends: ['@commitlint/config-conventional'] };" > commitlint.config.js
```

Now integrate the commit lint into the husky config by executing `yarn husky add .husky/commit-msg 'yarn commitlint --edit $1'` . It will generate a new husky config file named `commit-msg`.


![commit-msg](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/582zmbmylmh0vtdomfrc.png)

Now you cannot make any “barbaric” commit message anymore, LOL.

![commitlint](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/iydc23euxo6bbjaoxf3k.png)

Want to add some additional config before pushing your code to Git Repository? For example, I run `npx husky add .husky/pre-push 'yarn lint'` to generate the husky config that triggers the linter before pushing my code.


![pre-push](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/2vwks591pfcxon0h0oui.gif)

And YEAH!!! IT’S FINISHED. Note that, you don’t have to imitate my method 100%. You can match it with your needs.

## Closing

Actually, this is not an absolute way. There are so many ways or even tools that also help us to standardize our source code. Hope it helps you guys. I’m sorry if still there’s some grammar error. I’m still learning how to write in English properly, hahaha. Let me know if you want to discuss something in the comment section.

Standardize Your Next.js Project with ESLint and Husky

## Table of contents
- [Disclaimer](#disclaimer)
- [Introduction](#introduction)
- [Start From What Problem You’ve Faced](#start-from-what-problem-youve-faced)
- [You Don’t Need to Create Something from Scratch](#you-dont-need-to-create-something-from-scratch)
- [You Even Can Remake A Project That Already Existing](#you-even-can-remake-a-project-that-already-existing)
- [Closing](#closing)

## Disclaimer
> This article may be opinionated because it is based on my personal experiences. But at least it can be your reference on your working for the portfolio as a programmer.

## Introduction
Several days after I published my article titled **[How To Get Hired Without Applying](https://yehezgun.com/articles/how-to-get-hired-without-applying),** some of my friends asked me, `How you easily can get some ideas to create your project for your portfolio?`.  This is the same question when I knew a friend who routinely develops his projects and publishes them.

I knew exactly when we were just graduated in 2020 before getting a full-time job, he routinely publish his projects through Linkedin, Twitter, and his site. You can see some of his projects at <a target="_blank" href="https://sznm.dev/projects">https://sznm.dev/projects</a>. That time, I asked him the same question as the question in the previous paragraph.

In general, these are what I got from his answer. This answer makes me realize that it’s not too hard to generate some ideas in your head.

## Start From What Problem You’ve Faced
Remember**, the “How” will not exist without “Why”.** When you want to create a solution, there must be a problem to be solved. This is the most crucial thing that I’ve tried when I wanted to switch jobs to another company last year.

When I switch to React from Angular, I have to create something using React to strengthen my fundamental skill. That time I felt exhausted when I have to initiate a project from scratch, especially when I have to face the “config things” like husky, ESLint, and Prettier config.

Like I said in my previous article titled **[Why Making A Starter Template Matters?](https://yehezgun.com/articles/why-making-a-starter-template-matters)** then I made a starter template using Next.js, Chakra UI, and Typescript. It may be confusing and exhausting in the first place, but when I want to create some projects in the future I just use the starter template that I’ve made before without getting burnout due to “config things”.

Another example, when I post a microblog on Linkedin, I felt I need a link shortener. I think it’s better if I have my own link shortener so I can customize it with my own preferences. Then I made it at [Yehez-Shortin](https://shortin.yehezgun.com/).

Got the point? **You can find out the problem that you’re facing**, then make a plan to solve it. After that, implement what you’ve planned.

## You Don’t Need to Create Something from Scratch
Thanks to technology, we now can search for information that we wanted through the internet.  I remember a time when I watched an online talk between Pak Sandhika Galih (Web Programming UnPas) and Mathdroid. The talk is titled **[Tips Belajar Programming, Indie Hacker & Reverse Engineering](https://www.youtube.com/watch?v=LKATs6MDeCw).** You can watch it on Youtube (the talk is in Bahasa Indonesia).

> In this modern world, when you want to create a project, especially a coding project, you can easily google for it, search the references that you need, then implement it into your project. You can even imitate someone's project, manipulate it then remake it by your preferences. **~Mathdroid**

That statement was so inspiring for me. For your information, I actually have tried this method and because of it, I can get a new job.

It will be exhausting when you create a coding project from scratch. But remember that they're so many tools or libraries out there that can be used for your project. **For learning purpose, it will be better to create something from scratch to understand how it works in general, but in long term,** **you will need tools that help and boosts your productivity due to deadlines or something else prior.**

But don’t be wrong about this. **The latest tools don’t mean the best. Find suitable tools for your problems!**

## You Even Can Remake A Project That Already Existing
Can’t create something original? You can remake an app or project from what’s already existing. For your information, when I made my own [Next.js + Chakra UI + TS Starter Template](https://github.com/yehezkielgunawan/yehez-nextchakra-starter), I actually just imitate the idea from my friend, you can see his project at https://github.com/sozonome/nextarter-chakra.

Imitate doesn’t mean I remake it with 100% similarities. I took the layout reference and what tools can be useful for me, then I remake it based on my needs. Don’t worry, by remaking it actually you also learn how to make it step by step. **When you already know what to do, it will be easier for you to do the next step.**

**Analyze, imitate, then modify.** This is the very simple thing that enables a country in Asia which currently is one of the most developed countries. Yeah, you must know what I mean.

Another example is when I made my [Yehez-Shortin](https://shortin.yehezgun.com/) (link shortener). It actually a common idea. Most newbie web developers even made this when they just learned a new programming language. But I modified the layout and the feature based on my preferences, like dark mode and custom URL alias.

## Closing
> In this modern era, you can easily find the idea. You just need an internet connection then google it by yourself. Even actually you can find an idea around you.

Sometimes you tried hard to generate or find some ideas to create a coding project. Remember that, coding actually is problem-solving. So start to define or find a problem that you want to solve, then go ahead to solve it.

Thanks for reading, hope it can trigger you to develop your project, LOL. I’m sorry if there are still many grammar errors due I’m learning to write in English properly.

Reference: 

- Bangkit Academy Class 6: Idea Generation & MVP Planning
- [Agustinus Nathaniel’s Portfolio](https://sznm.dev/)

How To Get Any Programming Project Ideas?

## Table of contents

- [Introduction](#introduction)
- [What I've Learned Throughout The Year](#what-ive-learned-throughout-the-year)
  - [Struggling to Overcome Burnout of Fulltime Job Workload](#struggling-to-overcome-burnout-of-fulltime-job-workload)
  - [My Favourite Learning Path](#my-favourite-learning-path)
  - [Finally I Got a New Job](#finally-i-got-a-new-job)
- [Projects I've Worked on in 2021](#projects-ive-worked-on-in-2021)
  - [yehezgun.com](#yehezguncom)
  - [Personalized Starter Template](#personalized-starter-template)
  - [Personal Link Shortener](#personal-link-shortener)
  - [Personal Live Markdown Editor](#personal-live-markdown-editor)
  - [Personal Docs Site](#personal-docs-site)
  - [KAI Access App & A Freelance Project](#kai-access-app--a-freelance-project)
- [Hope For 2022](#hope-for-2022)

## Introduction
Well, without realizing it we are already at the end of 2021. Is it just me or not, this pandemic era makes time goes faster? I remember the last time we can meet each other by a person is about March 2020, and we're almost done everything online for nearly 2 years LOL.

I hope you're all good until today. Like most people do at the end of the year, I'd like to write some of my yearly recap and hope for the next year as a newbie frontend developer. Feels opinionated, but I think this can give you some new insight for planning what to do for the next year. For me, writing this can also be a self-reminder for myself when I read it again.

## What I've Learned Throughout The Year

### Struggling to Overcome Burnout of Fulltime Job Workload
We all know the Covid-19 pandemic has caused a lot of companies to enable Work From Home (WFH) regulation, except my previous company at that time LOL. From February 2021 until I resigned, still had to Work From Office (WFO) 100% every day even it's a software house company and very possible to do everything remotely.

I started to feel that I'm not enjoying my job at my previous company due to the toxic environment. I even did not learn anything except about mitigation and survival, LOL. For about one year I work spontaneously rather than making planning like a sprint planning routine like common tech companies did. When there're requests from the client, then my senior and I just work on it based on the requests.

The manager didn't give support at all. They just give ideas (actually add the workload for the devs) without explicit and concrete examples. So I have to think harder about the implementation. When the app is successfully developed, the developer never received any appreciation, only the managers.

In August 2021, I got burned out and didn't have the energy to work anymore because of the workload and the workflow. It lasts for several weeks. Luckily it was not a busy moment because there's a lack of client requests at that time. Actually, I still love coding, but not for the company's tasks.

I even spoke directly to him, and luckily the manager did not deny the facts that I've spoken. But the general environment and situation make the changes very impossible to be implemented. So I can say, there're no changes until I resigned from that place.

I learned that __work culture and environment are very crucial__. After I survived in this company for about one year and three months, I decided to not extend the work contract and luckily I got a new job for the next year.

### My Favourite Learning Path
In August 2021, after I healed from my burnout, I work on a freelance project with 2 of my former college friends. We made a web app using React (frontend) and Node.js (backend). I fell in love with React because of this.

I struggled a lot on the first week because I used Angular before then I have to switch to React in a short time. But, when I understand the code pattern and the basic things of React I finally finished all of my tasks for the project. Thanks to [Agustinus Nathaniel](https://sznm.dev/) for guiding and helping me to understand React properly.

After that, I invested my money to buy a domain for myself and challenged myself to build my own portfolio site using Next.js. Finally, I can finish it within a month. Not only that, I still developed some personal projects using React & Next.js to sharpen my understanding of React things.

### Finally I Got a New Job
I remember the moment I decided to prepare for my resignation in September 2021. After I finished developing my personal site, I challenged myself to make several personal projects and published them on Linkedin. Sometimes I wrote some articles and published them on Linkedin once a week.

My life changed since that time. I got several direct messages which contain a job offer as a frontend engineer (React-based). I also got a lot of phone calls from the talent hunter who offered me a job for their client company.

Now, I'm very selective in finding a job because of my past job experience. I don't want to get into the same toxic place. So when I got a phone call from the talent hunter or recruiter, I __did some research by myself to find out the information details about the company__, including the company reviews at [Glassdoor](https://www.glassdoor.com/).

I can identify the red flags regarding that company just by looking at the former employee reviews. Not only reviews, if the company does not have a professional profile like Linkedin Page, actually it can be a red flag too. 

Besides that, if I know that I have some friends who work there, I usually contact them and ask them about the work culture and situation there. Actually, I have got an offer letter from a Financial Technology (FinTech) company where some of my friends work there with a high salary. But without asking for more details, I canceled the offer because my friend often overwork and still have to work remotely from home on the weekend (hustle culture). I know the salary is interesting, but hustle culture is not for me and can lead me to burnout again.

> What you see is what you get. If you know you've been warned through the red flag that you got from the previous reviews or the information that got from friends, the reality won't be far from that.

Luckily, in November 2021, a recruiter from another hospitality company reach me through Linkedin. Then I followed the recruitment process and finished the take-home project. The pleasant moment is when during the user interview session with the squad leader. The user was not judgemental. He was even amazed at my take-home project result when he reviewed it. We spent time for the interview for about one hour, talking about my previous projects and experiences. It was so fun.

Several days later, I do the final interview with the manager. He is the first supportive manager that I've ever met. He cares about the employees' mental health and workload. He even explained and tell the truth of the company's current situation to me during the interview. We talk about many things during the interview for about more than one hour, LOL.

Finally, after the salary negotiation and the last interview, I received the offer letter. The recruiter was very helpful. She even reminds me of when there are some mistakes in my submitted personal data.

For your information, I live in Bogor, Indonesia, and the company is at Bandung. It's pretty far from my home city, but luckily I got the option to work remotely even after the pandemic ends, yeah!!!

I'll start to work again in January 2022. Wish me luck and I hope this is the better job for me to grow.

## Projects I've Worked on in 2021

### yehezgun.com
As I mentioned before, this is the first personal project that I've done in 2021 using React & Next.js. You can access and take a look at [yehezgun.com](https://yehezgun.com). I don't like to make complex designs. I'd rather make the simple one so I can understand it by myself when I want to make some improvements, LOL.

### Personalized Starter Template
So far there are two starter templates that I've made.
- [yehez-nextchakra-starter.yehezgun.com](https://yehez-nextchakra-starter.yehezgun.com) -> Next.js (Typescript) + Chakra UI starter template
- [yehez-vitechakra-starter.yehezgun.com](https://yehez-vitechakra-starter.yehezgun.com/) -> React (using  Typescript and Vite as builder) + Chakra UI starter template

You can read my previous article about the benefits of making your own starter template [here](https://yehezgun.com/articles/why-making-a-starter-template-matters).

### Personal Link Shortener
When I wrote an article, sometimes I refer to some links as references. So I thought it will be great if I can have my own link shortener, so I don't need to use and repeatedly search for a link shortener. You can access and even use it at [link.yehezgun.com](https://link.yehezgun.com/).

### Personal Live Markdown Editor
The reason I made this is because I need a live markdown previewer when I wrote documentation (Readme file) for a project that I have made. I made it using React Markdown Previewer to enable the live markdown preview. You can access the live demo at [markdown.yehezgun.com](https://markdown.yehezgun.com).

### Personal Docs Site
I've been exhausted from googling the same thing repeatedly. So I decided to make a site that contains the frequent things that I usually access or use to resolve "the redundancy" LOL. I made it using [Shuding's Nextra](https://github.com/shuding/nextra). You can see mine at [docs.yehezgun.com](https://docs.yehezgun.com).

You can read my previous article about the reason why I made my own personal docs site [here](https://yehezgun.com/articles/why-I-made-my-own-personal-docs-site).

### KAI Access App & A Freelance Project
As I told you before, I never worked on a freelance project with my friends. Unfortunately, it's a private project based on client requests. But I can explain a little about what we've made.

We made a warehousing system in the form of web and mobile apps. One of my friends created the mobile app, and I developed the web app, especially the CRUD process. So the employee just needs to scan the QR Code of the goods and the changes will be automatically done on the server. The other employee can also check and validate the data through the website.

The [KAI Access App](https://play.google.com/store/apps/details?id=com.kai.kaiticketing&hl=en_US&gl=US), actually it's an app developed by my senior and me when I was working in the previous company. My senior developed it from scratch using Ionic & Angular. I just developed the requested feature like the Taxi Order system and PPOB feature.

## Hope For 2022
2021 is a tough year for me personally. You have read my experience about how I struggled to survive and finally can get the new job. Thank God I can survive this year, LOL.

I know there're a lot of things changed and delayed due to the Covid-19 pandemic since 2020. But there're some things that I want to achieve and learn more deeply in 2022.
- __[Tailwind CSS](https://tailwindcss.com/)__  
I know I'm still a newbie in React development. I even still struggled with CSS even I'm a frontend engineer, LOL. So I decided to learn Tailwind CSS as my preferred and go-to CSS utility tool. Why? Because after I read the docs, it can push me to understand the design and little CSS fundamentals while I learn and use it. It also allows me to make my own design system.
- __Clean Code__  
For about one year I work in the previous company, I got a bad legacy code. It was very exhausting when I have to improve some features. The code is like a mess, LOL. If I optimize my parts, it also means I have to optimize the following features. That's why I often code like a barbarian. I realized that I cannot do this anymore and had to change my behavior.
- __Work-Life Balance__  
This is actually the common dream. Every people want to achieve it, LOL. I wish can achieve it through my new job soon. Hopefully, I also get a healthy environment and work culture, especially supportive colleagues.

Yeah, that's all from me. That's my 2021 recap and hope for the next year. What's yours?

2021 Recap

## Table of contents

- [Disclaimer](#disclaimer)
- [Introduction](#introduction)
- [Start with CRUD](#start-with-crud)
- [Build Your Online Presence](#build-your-online-presence)
  - [Build Your Own Site](#build-your-own-site)
  - [Make Some Mini Projects](#make-some-mini-projects)
  - [Publish Your Project](#publish-your-project)
  - [Share Your Idea or Story Through Article](#share-your-idea-or-story-through-article)
- [Join The Developers Community or Event](#join-the-developers-community-or-event)
- [Closing](#closing)

## Disclaimer
> This is just my experience when finding a new job as a front-end engineer. Maybe it seems opinionated, but at least it can be a reference for you. I will tell my story from a front-end engineer perspective.

## Introduction
The story starts when I was graduated from college in 2020. That is the moment when the Covid-19 pandemic began. I have no idea what to do after graduating because I feel overwhelmed with what subject can be focused on.

It changes when a friend told me that there's a free scholarship course at [Dicoding Indonesia](https://www.dicoding.com/). So I registered for that scholarship and got free access to the class. I found that I enjoy crafting something using HTML, CSS, and Javascript at that time.

Soon, I decided to learn some frontend frameworks like Angular, Vue, and React. I started to learn those frameworks by making a simple to-do list. Actually, among those frameworks, I mostly like React as my main framework, but suddenly I got an offer from a company that uses Angular in their codebase. I worked there for about 1 year and 3 months.

During my first journey as a full-time front-end engineer, I realized that the bigger the community of a framework or library, the bigger also the support system. I struggled enough when I have to do some troubleshooting using Angular and it takes more time than when I used React (in my personal project).

So, I started to re-learn React again after working for a year. Luckily, the company also considered migrating to React because some of the frontend engineers complained and told the same reason as I think before. We learned to React together at the office almost every day then.

I learn React by making some mini-projects and publishing them on Linkedin. Then, many jobs offers come to me through phone calls and email until I finally found the suitable one for me. Actually, most of the projects are not spectacular, I even made it just for myself at first.

I think similar things may work for you if currently, you're searching for a new job as a developer. Here are my tips based on my experiences. 

## Start with CRUD
Everything in the developing world is about to Create, Read, Update, and Delete __(CRUD)__. When I re-learned React again after a long time, I started again with CRUD. I just follow the [MDN React To-do list tutorial](https://developer.mozilla.org/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/React_getting_started) and re-code it in my VS Code. This seems very mainstream, but it helps me so much when I make a new project.

This trick also works when you're learning a new framework. You can only need to think about how to Create, Read, Update, and Delete the data using the framework you learn while you trying to understand the syntax too.

## Build Your Online Presence
If you want to get recognized by the recruiter, you have to make yourself recognizable by building your online presence. As a developer, you can start by building your own site, developing & publishing your project on Linkedin and Github, and writing some articles or blogs.

### Build Your Own Site
As a frontend engineer, you can start building it by making your own personal site using your framework or library preferences. For example, after I learned the basic CRUD, I push myself to build my own website using Next.js. You can access it at [yehezgun.com](https://yehezgun.com).

You don't have to make a spectacular one, just be yourself. Your site is your playground, don't be too a perfectionist. I even still trial and error in modifying something at my current personal site.

You may be asked, `Why do I need to make my own site?`.  Actually, there are no formal rules here, back to your preferences. For me, I can do some experiments on my own website because it's mine and __I have full control of it.__

### Make Some Mini Projects
In my opinion, this is the most effective way to understand the technical concept and even get hired. If you're confused about what project you should make, you can __start to make a project that can be used by yourself.__

For example, I started to make my own Next.js starter template. You can check it at [yehez-nextchakra-starter](https://yehez-nextchakra-starter.yehezgun.com/). Why did I make it? The story began when I need to make a new project using Next.js, I wasted my time just doing some repetitive things like ESLint & husky config, base navbar, and base layout. So I decided to make my own starter template as a base template, so I can focus on the development process. You can read the details on my past article [here](https://yehezgun.com/articles/why-making-a-starter-template-matters).

### Publish Your Project
The next step is __show your work__. I have to say, it's mandatory for a developer to have a Github (or Gitlab) account. GitHub is a great way to showcase your projects and show what other technologies you are interested in — by forking, starring, or contributing to them. It also gives other people an idea about the amount of work you have been putting in, by the number of contributions shown on your profile [(Mircea Oprea, 2019)](https://medium.com/streamwriter/creating-an-online-presence-as-a-developer-369ec79fb311).

The other way to publish your project is through Linkedin. You can use this platform to attract the recruiter when they see your published project and offer you the job. For example, I re-code my personal site and publish it as a Linkedin Post [here](https://www.linkedin.com/feed/update/urn:li:activity:6878601141693886465/). Just in several days, I got so many private chats on Linkedin which are job offers. And finally, I can get a new job because of this simple thing.

### Share Your Idea or Story Through Article
Why does writing a blog matter? By writing a tech blog that contains some tutorial, story, or just an idea, you're helping other developers out there to generate new insight or even help them to solve their problems. In other words, you have contributed to the developer world when you write a technical blog.

You can start writing a blog by writing a process while making a project or making some simple tutorials. For example, I wrote an article about how to self-host the Notion API Worker, you can read it [here](https://yehezgun.com/articles/how-to-self-host-notion-api-worker). Without realizing it, I've helped some developers to self-host their own Notion API Worker when they want to use it.

__For me, writing can sharpen my understanding of something,__ because you read twice or even several times when you write. You will surely read your own writings before publishing them and make sure the readers understand them.

## Join The Developers Community or Event
This also gives a significant impact on my career as a front-end engineer. In early 2021, I joined a big event in Indonesia held by Google and the partner companies. Yes, you're right I joined Bangkit Academy as a volunteer.

Yeah I know, I got nervous and feel inferior because of too many pro developers who join as volunteers. The most challenging moment is when I have to co-assist my partner in a live teaching session. His coding and technical skill amazed me because he can explain all the technical processes fluently. But, I'm proud for joining this event because I can __enlarge my networking with other developers__ and learn a lot of things from them.

Sometimes this thing can give you a new opportunity if they offer a new job in their working place.

## Closing

> Build and strengthen your online presence. Soon or later, the opportunity will reach you. Just be consistent and keep going!

I did all those tips since September 2021, and __it works__. Finally, after I struggled to find a new job opportunity, I found one. I even didn't apply it by myself. A recruiter reached me through my Linkedin and I follow the recruitment process. Indeed, I didn't need to do the live code session because I showed my previous work in the user interview session. So it can be called a _live code review session_ because they just review my previous works.

Hope my story can inspire you, especially those who struggled to find a new job. Sorry if there's some grammar error here, I'm still an amateur at writing articles in English.


How To Get Hired Without Applying

# Table of Content
- [Disclaimer](#disclaimer)
- [Introduction](#introduction)
- [It's Like Building Your Library Room](#its-like-building-your-library-room)
- [It Can Be Your "Second Brain"](#it-can-be-your-"second-brain")
- [It Boost Productivity and Save Your Time](#it-boost-productivity-and-save-your-time)
- [You Can Put Everything Here, Not Only About Programming Things](#you-can-put-everything-here-not-only-about-programming-things)
- [Closing](#closing)

# Disclaimer
 This is just my opinion as a newbie frontend engineer who was exhausted from googling the same thing every time I need it. But I hope this article can be a reference for you.
 
# Introduction
 The story began when I decided to switch from Angular to React as my favorite and go-to framework in June 2021. Previously, everything is fine. I googled normally when I have to do some troubleshooting or just want to search for information related to my project using React. Everything changed when I started to feel tired of googling the same thing each time I need that information or code snippet.
 
A college friend suggested I make my docs site. Then, he also showed me his own docs site at [base.sznm.dev](https://base.sznm.dev). Like before, I asked him, "Why did you make this? It's just like you put your notes here.". Then he answered, "I just feel tired of googling the same thing every day. So that's why I made these docs site to put my most used tools, library, or even snippet."
 
Hmm.... nice idea. Now I realized that maybe I need it too. After I made my own personal docs site like him, here are the benefits of making it based on my experience.
 
# It's Like Building Your Library Room
This is the first impression when I put my notes and most used tools on my site. It feels like I made my library. I put and sorted the information based on its categories like putting the books according to their genre.
 
As a programmer, maybe I don't have a big physical bookshelf like at the library. But at least, now I can have my digital library and can be accessed freely from any device.
 
# It Can Be Your "Second Brain"
Too much information out there and it makes the newbies like me confused to select which information I need. __The current problem is not lack of information, but how to filter the information you need.__
 
By making my own personal docs site, I can decide which tool I often use and keep it there. When I need it, I just open my own site and use it in my project. __It reduces the "information obesity" risk in my mind and increases my focus.__
 
# It Boost Productivity and Save Your Time
Imagine when I need information about the tools or snippet that I usually used, but I forget about it and have to google it again and again very often. That's very ineffective and wasting time.
 
For example, I usually use the same ESLint config snippet every time I initiated a new project using React. Before I finished my own docs site, I have to open several browser tabs and googled them. I spend to finish my ESLint config about almost 30 minutes just for it.

But when I put the ESLint config snippet in my personal docs site, I just accessed it and copy & paste it to my project, and install the required dependencies. Such a time saver.

# You Can Put Everything Here, Not Only About Programming Things
Yes, I can put some of my most used code snippets or config in my personal docs site. But not only that. I can put my favorite tools outside programming like video editor tools or productivity tools.

I even can keep my favorite anime list here if I want, LOL. It's like you put your notes on a website, so just use it freely.

# Closing
> If you started to feel tired of googling the same thing every time, or if you repeatedly use some tools or snippet or config, you may need a personal docs platform or site to keep that information.

You can access and take a look at my personal docs site at [docs.yehezgun.com](https://docs.yehezgun.com). You also can make your own using [Nextra](https://nextra.vercel.app/) like mine.

Thanks for reading. I hope my amateur article can give you some new insights. Have a nice day.

# References 
- [base.sznm.dev](https://base.sznm.dev) and [docs.thcl.dev](https://docs.thcl.dev/) as my main example.
- [Nextra](https://nextra.vercel.app/) as the base template

Why I Made My Own Personal Documentation Site?

# Table of contents
- [Introduction](#introduction)
  - [Feeling left behind and not relevant](#feeling-left-behind-and-not-relevant)
  - [Worried that you cannot be an expert due to the fast-changing](#worried-that-you-cannot-be-an-expert-due-to-the-fast-changing)
  - [Exhausted because you have to understand too many things](#exhausted-because-you-have-to-understand-too-many-things)
  - [Troubled when choosing a library or tools](#troubled-when-choosing-a-library-or-tools)
- [How to Cope with It?](#how-to-cope-with-it)
  - [What is the purpose of these tools?](#what-is-the-purpose-of-these-tools?)
  - [Is It Solves The Problem?](#is-it-solves-the-problem)
  - [Who Made This? Who Uses This?](#who-made-this-who-uses-this)
  - [Is It Popular? Is It Has Any Supportive Communities?](#is-it-popular?-is-it-has-any-supportive-communities)
- [Closing](#closing)

# Introduction

> Have you ever felt exhausted, tired, or bored when following the frontend technology updates?

Don't worry, you're not alone. I also feel that when I was a beginner in frontend engineering. I feel enthusiasm when learning about front-end frameworks like Angular, Vue, and React (my current favorite framework). But it changes when the fire nation comes, LOL. You might be realized that recently the update of the frontend technologies is going faster and more massive than before.

Looking back over the years, I remember when I was learning Angular for the first time. Angular 6 is a shiny and powerful framework (for me) at that time. Then Vue and React come and change everything.

> Have you tried Vue? Hey, you should try React, it's fun and easy to learn. What? Do you still use Angular? Oh man, try this lib, blablablabla.

That makes me anxious actually. But I realized that I'm not alone. A lot of developers also face this issue. So, what's the sign of Frontend Fatigue? Tri Hargianto tells that you will feel these signs if you experience Frontend Fatigue.

## Feeling left behind and not relevant
I have felt this before. When I was working as a frontend engineer for the first time, I still use Ionic and Angular as my main framework. I sensed that I'm not relevant with my other friend who also works as a frontend engineer at the other company that uses React or Next.js.

The most uncomfortable moment is when I catch up or meet up with them both in person or online, their mindset about frontend development is highly advanced. I even have a friend who is very expert in React Development. He even understands how every React and Next.js features work. Yes, every single detail, including the updated one.

I feel more anxious when I saw a lot of job opportunities (as a Frontend Developer) requires skill that matches the updated framework or tools. For example, there's a job vacancy that mentions for the candidates must be skilled in React and Redux. As an Angular Developer before, I need to learn about that framework and library because I have never used it before for professional use.

## Worried that you cannot be an expert due to the fast-changing
Have you ever learned a programming language or framework for a while, then it releases a new update with the new features and syntax? It might make you mad because sometimes you need to re-learn it.

For example, when the class component in React is still famous among developers, all newbies out there learn to React through the class component. But it changes when the Hooks come, it enables developers to make the same effect (or logic) with just functional components. And of course, it causes many developers must re-learn React through Hooks and functional components.

Imagine this, this is an example of one framework. We cannot predict the future. Maybe one day there are some new frameworks with powerful features and then cause many companies to migrate from the old one to the new one.

## Exhausted because you have to understand too many things
Only learning the framework is not enough. You often need more resources or a third-party library to support your project using that framework.

When I first time learned React, I cannot learn only React itself. I have to learn the third-party libraries that can support my project like Redux, Chakra UI (UI Component) and React Router (React doesn't have a built-in router like Angular, so it needs the third party router). Sometimes, it makes me exhausted and almost burnout because I have to understand a lot of things.

## Troubled when choosing a library or tools
By reading the writing above, you will realize choosing a library or tools will be not easy as you think. And it's true. Too many options out there, and it makes the newbie developers confused about which one is suitable for their project. 

# How to Cope with It?
According to [Tri Hargianto](https://www.linkedin.com/feed/update/urn:li:activity:6833370002012409856/), every framework or tool claimed that their solution is the best. But in reality, there's no "the best tool". __The important thing is the suitable solution for a problem.__

It's good to get updated, but don't let yourself be exhausted because of it. __Reading about the updates or the articles is enough.__ But if you want to use a library or framework for your projects, you can consider these things.

## What is the purpose of these tools?
Before you install it, make sure you know the purpose of why you want to use it. It is better to make the logic by yourself than installing an overpowered library that requires more resources _(depends on your project scope)_.

So depends on your project scope and requirements, consider that do you need the third-party library to support your project or you can make the logic by yourself?

Remember this, __every tool or third-party library requires more resources. Too much library installed in your project can affect the performance of your application.__

## Is It Solves The Problem?
Next, make sure the tool you use can solve the problem that you face. Back to basic, it depends on your project scope and requirement.

__If the library can boost your productivity, go ahead. But when it creates another new problem, think again.__

## Who Made This? Who Uses This?
By knowing the creator behind a framework or library, it can build trust from its users. You have to do some small research on the creator behind the tools that you use. Who is he/she? What's his/her background? Why did he/she make it?

Also, don't forget to find out the user segment of a framework or library. __By knowing the user segment, you can easily find a suitable community or forum when you do some troubleshooting.__

## Is It Popular? Is It Has Any Supportive Communities?
__The more users of a framework or library, the bigger communities that support it.__ 

For example, React. Why React is so popular nowadays? Because there's a lot of developers use React to develop their apps. When they face some issues or problems regarding React features, they discuss it at a forum like Stackoverflow. It will be easier when you do some troubleshooting because a lot of developers use it and share their problem-solving using React at the forum.

Most important thing is, __make sure the framework or library that you choose is stable for a long period of time.__ Don't let yourself wrongly choose a tool that is outdated or the newest tool but not stable _(still there're issues)_ yet.

# Closing
Tri Hargianto concludes this:

> The wise way to overcome the Frontend Fatigue is to stop overthinking about all updates outside. Just learn what's make you curious and required in your current project.

The point is no matter how massive the frontend tech updates are, the most important thing is **back to basic, it depends on your needs.**

One more thing from me, **learn fundamentals first**. For example, when a person has solid CSS fundamental skills, he/she can easily understand when using *tools* like Bootstrap or Chakra UI.

On a different side, a person who straightly learns Boostrap and skips the CSS will be confused at the end when he/she has to make custom styling. He/she may be also exhausted when switching to another *tool* like Chakra UI because of its different syntax and concept.

> If you have a solid fundamental skill, it will *be* easier for you to switch to another *tool.*


And yeah, that's my experience with Frontend Fatigue. How about you? Let's discuss this here. Hope it inspires you even though I'm still an amateur, hahaha.


Reference: [Tri Hargianto Linkedin Post](https://www.linkedin.com/feed/update/urn:li:activity:6833370002012409856/)

Frontend Fatigue

# Table of contents
- [Introduction](#introduction)
- [You Can Focus on The Development Process](#you-can-focus-on-the-development-process)
- [Increase Your Productivity](#increase-your-productivity)
- [You Can Use It as Portfolio](#you-can-use-it-as-portfolio)
- [Bonus and Closing](#bonus-and-closing)

## Introduction
> Oh man I'm very exhausted. Every time I initiate a new project, I have to configure the following setup or config from the beginning.

That's my thoughts when I was a beginner even until now, LOL. I often felt wasting my time when I have to configure the following configuration every time I started a new project, especially in frontend development.

But this thing changed when I know a friend who is a pro in React Development. I ever work with him as a team in a freelance project. Suddenly, I saw his newest personal site and found several starter templates made using Next.js, Vite, and other else.

I asked him, `Why you made this? This is just a basic starter template.`. Then he answered, `Yes of course. So I don't need to overthink about the configuration every time I initiate a new project using that framework or library.`.

For me it's a brilliant idea. Instead of wasting time to setup the configuration from scratch every time I initiate the new project, why I don't make a starter template for myself so I can focus on the development process?

Since that, I started to make the starter template for myself. Seem useless at the beginning but for the long term, it's worth it and increase my productivity. Here's the benefit of making your own starter template.

## You Can Focus on The Development Process
It's very exhausting when you have to configure the ESLint and Prettier every time you make a new project, right? That's redundant process can be cut by this base starter template.

If you're using a UI Library like Chakra UI or Tailwind, you maybe feel depleting if you have to install it multiple time and setup the configuration again and again. By making and having the starter template, you can just initiate a project based on it and use it forward.

## Increase Your Productivity
If you can more focus on the development process, so it can also boost your productivity. Many times I found that the most confusing moment is not when I found an error because of my code fault, but it's because I made the wrong configuration and it's time consuming.

By having your own starter template, you can define the config like ESLint and Prettier since the beginning. Then, you can reuse it along along with the new project that you initiated.

## You Can Use It as Portfolio
As a beginner developer, I assure that the starter template can be used as a portfolio when applying a job. It seems a simple thing, but maybe you didn't realize that you're not only helping yourself, but also other people who has the same thoughts like you regarding this.

Imagine when you made a starter template. Actually you made it for yourself, then other programmers found your Github repository and use your template then they feel satisfied and helped. You're such a life saver.

## Bonus and Closing
So, how can I made my own starter template? You can check my previous article about it at [https://yehezgun.com/articles/post/how-to-make-your-own-nextjs-starter-template](https://yehezgun.com/articles/post/how-to-make-your-own-nextjs-starter-template).

As a bonus, you also can use my starter template as a reference. It can be accessed at [https://github.com/yehezkielgunawan?tab=repositories&q=template](https://github.com/yehezkielgunawan?tab=repositories&q=template).

Thanks for reading. I hope it can motivates or inspire you. Sorry if my contents still like an amateur, I'm still learning on making tech articles using English. I'm open for feedback. Thank you.


Why Making A Starter Template Matters?

# Table of contents
- [Introduction](#introduction)
- [How to Self Host it?](#how-to-self-host-it)

## Introduction

Lately, I'm learning React and its frameworks (like Next.js) and libraries. I even remake my personal site as my first portfolio in React. Just made it using Next.js and Chakra UI and integrated it into my Notion workspace.

To connect my web to my Notion workspace I used [React Notion](https://github.com/splitbee/react-notion) from Splitbee. You can check it for a while.

So, React Notion use [Notion API Worker](https://github.com/splitbee/notion-api-worker) to handle its requests. It can be also self-hosted using Cloudflare. Cloudflare offers a generous free plan with up to 100,000 requests per day.

I will not explain React Notion details, you can check it alone by yourself. I'll write about how to self-host the Notion API Worker using Cloudflare.

## How to Self Host it?
* You can log in to [Cloudlfare worker site](https://workers.cloudflare.com/) or register if you don't have an account yet.
* Before going further, you can fork and clone the [Notion API Worker](https://github.com/splitbee/notion-api-worker).
* After you cloned it, install the dependencies using `yarn`.
* Rename the file named `wrangler. for example.toml` to `wrangler.toml`.
* Edit `wrangler.toml` according to your preferences. Here's also an example of mine.
```toml
name = [Your worker url]
webpack_config = "webpack.config.js"
type = "webpack"
workers_dev = true
compatibility_date = "2021-10-07"

account_id = [Your Cloudflare account ID]
zone_id = [Your Cloudflare zone_id]

route = "[Your domain]/*"
```
![Wrangler Config](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/a2n0aufbbrwdat2ptprf.PNG)
* Make sure you have installed **wrangler**. You can see how to install it [here](https://developers.cloudflare.com/workers/get-started/guide).
* You can edit the scripts in `package.json` if you want so you can run it with your custom command.
```json
  "scripts": {
    "build": "webpack",
    "dev": "wrangler dev",
    "preview": "wrangler preview",
    "deploy": "wrangler publish"
  },
```
* To run it locally, you can run `yarn dev` and open the link.
![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/x9iecorvzieab4ozco51.PNG)
* To see the preview you can run `yarn preview`.
* The last thing, you can deploy it to Cloudflare server using `yarn deploy` or `wrangler publish`. Then open the link in your browser.
![Wrangler publish](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/a4rgv6u7vkueqlou16fc.jpg)

Tadaaaaa, it's done. You can check your API worker in your Cloudflare dashboard. This is my first English article, LOL. I hope it can help and inspire you.

How to Self Host Splitbee Notion API Worker

# Table of contents
- [Introduction](#introduction)
- [Project Initialization](#project-initialization)
- [Folder Structure](#folder-structure)
- [Modify the Base UI](#modify-the-base-ui)
- [Deploy](#deploy)

## Introduction
Currently, I'm learning about React & Next.js. To understand how it works, I usually push myself to make some mini-projects using that framework. One thing I hate when I develop a project, it's about config.

It started when I knew a friend who made his starter template. I asked him, `Why do you make it?`. He answered, `Well I don't need to worry about the 'configuration' thing when I initiate a new project. So I can focus on the development process.`

I think it's a great idea. I also don't need to feel anxious about the configuration when I make a new project if I have my starter template.

Here's how I made my starter template using Next.js and Chakra UI.

## Project Initialization
This time, I used the example of the base starter template that Next.js provides.
```cli
npx create-next-app --example with-chakra-ui-typescript [YOUR_APP_NAME]
```
Next, I initiated the ESlint config so the code style can be consistent. I added `next-lint` at `package.json` and executed it. The details can be seen [here](https://nextjs.org/docs/basic-features/eslint).
```json
"scripts": {
  "lint": "next lint"
}
```
After that, execute the command `yarn lint` or `npm run lint` to initiate `eslintrc.json`. I modified some things due to personal preferences. You also can adapt it to your preferences.
```js
{
  "env": {
    "node": true
  },
  "extends": [
    "next/core-web-vitals",
    "eslint:recommended",
    "plugin:@typescript-eslint/recommended"
  ],
  "parser": "@typescript-eslint/parser",
  "plugins": ["@typescript-eslint", "import"],
  "settings": {
    "import/resolver": {
      "node": {
        "extensions": [".js", ".jsx", ".ts", ".tsx"],
        "moduleDirectory": ["node_modules", "src/"]
      }
    }
  },
  "rules": {
    "no-unused-vars": "off",
    "@typescript-eslint/no-unused-vars": [
      "error",
      {
        "argsIgnorePattern": "^_"
      }
    ],
    "@typescript-eslint/explicit-module-boundary-types": "off",
    "@typescript-eslint/no-non-null-assertion": "off",
    "@typescript-eslint/no-inferrable-types": "off",
    "import/order": [
      "warn",
      {
        "groups": [
          ["builtin", "external"],
          "internal",
          "parent",
          ["sibling", "index"],
          "object"
        ],
        "newlines-between": "always",
        "alphabetize": {
          "order": "asc",
          "caseInsensitive": true
        }
      }
    ],
    "complexity": "warn",
    "no-console": ["error"]
  }
}
```
After finishing the ESlint config, I made a [Next SEO](https://www.npmjs.com/package/next-seo) config. This library is used to modify the meta-tag which is usually used to optimize the SEO and make a preview for the web project.

First, install the Next SEO using `npm I next-seo`. Then, make `next-seo.config.js` at the root directory. This is my base configuration. You can accommodate with your preferences.
```js
/** @type {import('next-seo').DefaultSeoProps} */
const defaultSEOConfig = {
  title: "yehez-nextchakra-starter",
  titleTemplate: "%s | yehez-nextchakra-starter",
  defaultTitle: "yehez-nextchakra-starter",
  description:
    "Yehezkiel Gunawan's personalized Next.js + chakra-ui + TypeScript starter template",
  canonical: "https://yehez-nextchakra-starter.yehezgun.com",
  openGraph: {
    url: "https://yehez-nextchakra-starter.yehezgun.com",
    title: "yehez-nextchakra-starter",
    description: "Next.js + chakra-ui + TypeScript template",
    type: "website",
    images: [
      {
        url: "https://yehez-og-image.yehezgun.com/**yehez-nextchakra-starter**.yehezgun.com.png?theme=dark&md=1&fontSize=50px&images=https%3A%2F%2Fres.cloudinary.com%2Fyehez%2Fimage%2Fupload%2Fv1631970666%2Fyehez_avatar_vkv7pc.png&widths=200&heights=200",
        alt: "yehez-nextchakra-starter.yehezgun.com og-image",
        width: 800,
        height: 600,
      },
    ],
    site_name: "yehez-nextchakra-starter",
  },
  twitter: {
    handle: "@handle",
    site: "@site",
    cardType: "summary_large_image",
  },
  additionalLinkTags: [
    {
      rel: "icon",
      href: "https://res.cloudinary.com/yehez/image/upload/v1630902976/Assassination_Classroom_-_Koro-sensei_smiling_head_fwpndi.svg",
    },
  ],
};

export default defaultSEOConfig;
```

## Folder Structure
The base config is done, now it's time to make the folder structure. The base folder structure from the example template is quite good, but I want some modification here. Here's mine.
```clean
/src
    /components
        /layout
        /motion
        /wrapper
    /functions
        /helper
    /pages
    /types
```

## Modify the Base UI
It's time to modify the UI and layout. Maybe I won't explain the whole process here. It will be too long to explain. You can modify the layout by your option.

Here's my result [https://github.com/yehezkielgunawan/yehez-nextchakra-starter](https://github.com/yehezkielgunawan/yehez-nextchakra-starter)rr.

## Deploy
Finally, the final step. Don't forget to push the project to your repo in Github or Gitlab. You can check [here](https://www.git-tower.com/learn/git/faq/push-to-github/) for the details.

I used [Vercel](https://vercel.com/) as my hosting platform. It's easy to use, you can integrate your repository with Vercel, so every time you push an update, it also re-build the project. Read [here](https://egghead.io/lessons/next-js-deploy-a-project-on-vercel-formerly-zeit-from-a-github-repository) for the details.

After deployed, let's make the project a public template.
![Template Repo](https://diskusi-tech-production.s3.amazonaws.com/i/mzpxxxc6hdj4i6hd5un5.PNG)

Aaaanddd, that's it. You can use the template using this command
```bash
npx degit [REPOSITORY NAME] <APP NAME>
```
Example: 
```bash
npx degit yehezkielgunawan/yehez-nextchakra-starter test-template
```

For Next.js you can use the built-in command to initiate a project based on the example template.
```bash
npx create-next-app --example [Github Repository Link] <YOUR_APP_NAME>
```
Example : 
```bash
npx create-next-app --example https://github.com/yehezkielgunawan/yehez-nextchakra-starter test-template
```

Your life will be easier with this, so you can focus on the development process every time you initiate a new project, LOL. Congratulations!!!

Here's my starter template: [https://yehez-nextchakra-starter.yehezgun.com/](https://yehez-nextchakra-starter.yehezgun.com/)//. How about you? Not a perfect one, I know. But at least, it's very helpful for me.

Yeah, that's from me. I'm sorry if there're some typos or mistakes here. I'm still an amateur at making a tech article. Happy trying and you can give some feedback here if you want. Thank you.

Reference: [Sozonome NextChakra-starter](https://github.com/sozonome/nextarter-chakra)

How to Make Your Own Next.js Starter Template

# Daftar Isi

- [Disclaimer](#disclaimer)
- [Pendahuluan](#pendahuluan)
- [Deskripsikan Masalahnya](#deskripsikan-masalahnya)
- [Cek Kembali Sebelum Bertanya](#cek-kembali-sebelum-bertanya)
- [Dokumentasikan Solusinya](#dokumentasikan-solusinya)
- [Penutup](#penutup)

## Disclaimer

> Artikel ini dibuat berdasarkan pengalaman pribadi. Bukan bermaksud untuk melarang seseorang bertanya, melainkan untuk memberikan “awareness” agar ada persiapan sebelum bertanya, terutama perihal teknis pemrograman. Semakin jelas deskripsi masalahnya, semakin mudah masalahnya diselesaikan.

## Pendahuluan

Saat masih menjadi asisten laboratorium (aslab) waktu kuliah, saya sering menerima pertanyaan-pertanyaan dari para junior saya. Sepanjang sesi kelas, ketika mereka sedang mengerjakan modul praktikum, sering sekali mereka bertanya kepada saya ataupun partner aslab saya saat itu. Saya sebenarnya tidak ada masalah ketika mereka bertanya, bahkan saya salut karena berarti mereka mulai kritis dan mencoba memecahkan masalah yang ada di modul tersebut.

Tetapi ada hal yang cukup mengganggu saya saat itu. Beberapa dari mereka menanyakan hal-hal yang sebenarnya sudah tertera dalam modul praktikum, jawabannya pun bahkan bisa mereka dapatkan ketika mereka mencobanya sendiri. Tak hanya itu, seringkali saya menerima pertanyaan yang kurang jelas sehingga waktu saya kebanyakan habis hanya untuk memahami apa maksud pertanyaannya dibandingkan menyelesaikan masalahnya.

Itu pengalaman saya sepanjang menjadi aslab sampai 2020. Sebenarnya ini bukan kebiasaan yang baik. Itu sebabnya saya rasa perlu untuk membagikan ini, sehingga kita sama-sama belajar untuk menghindari kebiasaan ini ke depannya. Kurang lebih inilah tips dari saya sebelum bertanya.

## Deskripsikan Masalahnya

Sebelum bertanya, pastikan kamu sendiri sudah tahu apa yang mau kamu tanyakan. Saya punya pengalaman yang cukup menguras energi ketika saya masih menjadi aslab. Hampir sepanjang sesi yang pernah saya ampu, banyak mahasiswa junior yang memberikan pertanyaan yang kurang jelas. Tentunya ini membuat saya sendiri kewalahan karena butuh waktu lebih untuk memahami pertanyaannya itu sendiri.

Banyak yang bertanya, `Kak ini scriptnya gak jalan di PC saya, kenapa ya?`. Ini yang menyebabkan saya harus berdiri di samping PC-nya kurang lebih 5-10 menit hanya untuk memahami masalah yang dihadapi sebelum akhirnya menunjukkan solusi yang pas🤣.

Perlu diingat kalau saja masalahnya dideskripsikan dengan jelas, itu bisa membantu siapa saja yang mau menjawabnya lebih mudah dan cepat tanpa menghabiskan banyak waktu. Setidaknya, temukan dulu akar masalahnya, kemudian deskripsikan dengan jelas ketika bertanya. Kalau akar masalahnya sudah ditemukan, sangat mudah untuk menentukan solusinya.

Contohnya, saya pernah menemukan mahasiswa saya “mem-breakdown” pertanyaannya sebelum bertanya. Mereka saat itu kesulitan untuk fetch data menggunakan Angular HTTP. Saat saya menghampiri mereka, mereka menunjukan demo singkat berikut dengan syntax code yang dirasa ada bug-nya. Mereka bahkan menjelaskan secara runtut. Kurang dari semenit, saya temukan bahwa ada kesalahan sedikit di syntax mereka yang menyebabkan crash pada web app mereka. Cara ini hanya efektif di dalam sesi kelas offline, bisa lain lagi kalau online🤣.

## Cek Kembali Sebelum Bertanya

Saya juga sering menerima pertanyaan yang berulang. Ketika saya selesai dengan masalah mahasiswa yang satu, muncul lagi mahasiswa lain yang menanyakan hal yang sama persis🤣. Saya bahkan harus capek-capek menjelaskan ulang di depan kelas. Ini tidak efektif.

Kasus lain, ketika saya sedang mencoba membantu menyelesaikan isu teknis dari salah seorang mahasiswa saya, ternyata jawabannya ada di google. Terkadang, saya juga mendapati mereka melewatkan langkah atau panduan yang ada di modul praktikum atau dokumentasi.

Dari pengalaman inilah, setidaknya saya mendapati setidaknya 2 kriteria ini harus dipenuhi sebelum bertanya (diasumsikan sudah di-breakdown):

- Apakah pertanyaan ini sudah ditanyakan dan dijawab sebelumnya?
- “Do your own research” dan trial & error sebelum bertanya

Cari tahu dahulu di forum seperti [Stack Overflow](https://stackoverflow.com/), barangkali pertanyaanmu sudah terjawab di sana. Atau kalau di sesi kelas offline, tanyakan kepada temanmu yang telah bertanya dan mendapat jawaban sebelumnya apabila pertanyaanmu sama dengannya.

Untuk teknis coding, dicoba dahulu sebelum bertanya. Cari tahu dulu apa yang salah dari kodinganmu lewat debugging. Atau bisa sambil googling barangkali menemukan jawaban di internet.

Kalau ternyata kamu sudah melakukan hal-hal tadi dan tidak menemukan solusi yang pas, barulah datang bertanya. Tak lupa, deskripsikan masalahnya secara jelas, itu akan sangat membantu bagi yang mau membantu sehingga tidak perlu menghabiskan banyak waktu. Ini tentunya bisa mengurangi potensi redudansi dalam bertanya atau menanyakan hal-hal yang sebenarnya tidak perlu ditanyakan karena sudah terdokumentasikan atau bisa dicari sendiri lewat “googling”.

## Dokumentasikan Solusinya

Ketika akhirnya kamu mendapatkan solusi yang pas, jangan lupa didokumentasikan. Contohnya, akhirnya kamu bisa menemukan cara bagaimana fetch data API dengan Axios, catatlah itu. Kalau punya web personal, buat artikel singkat mengenai solusi yang kamu temukan dan publikasikan sehingga orang lain yang mungkin memiliki masalah serupa bisa tertolong oleh tulisanmu. Biasa sih istilahnya “giving back”.

Tidak hanya itu, kamu pun bisa membaca kembali tulisanmu sendiri ketika menghadapi isu teknis serupa. Itu tentunya akan mengurangi frekuensi “trial & error” yang melelahkan karena kamu sudah mengalami isu tersebut sebelumnya dan tinggal implementasikan kembali solusinya.

## Penutup

Sekali lagi, saya tidak melarang untuk bertanya. Saya hanya memberitahukan agar kita semua memiliki persiapan sebelum bertanya. Semakin jelas deskripsi masalahnya, semakin mudah pula untuk menemukan solusinya.

> Menemukan akar dari suatu masalah, berarti 50% dari solusi.

Persiapan Sebelum Bertanya Hal Teknis

## Daftar Isi

- [Disclaimer](#disclaimer)
- [Pendahuluan](#pendahuluan)
- [Ide Baru dan Unik Seringkali Muncul Ketika Ngobrol Santai](#ide-baru-dan-unik-seringkali-muncul-ketika-ngobrol-santai)
- [Terasa Seperti Sesi Konseling](#terasa-seperti-sesi-konseling)
- [Penutup](#penutup)

## Disclaimer

> Artikel ini ditulis berdasarkan perspektif dan pengalaman saya ketika membuat sesi *coffee talk*. Mungkin tidak 100% valid, setidaknya ini mungkin bisa memberikan perspektif baru mengenai sesi casual 1 on 1.
> 

## Pendahuluan

Pada minggu kedua bulan Juli 2022, saya membuat sesi 1 on 1 terbuka bernama “Ngupi”. Itu sebenarnya istilah plesetan dari kata “kopi”. Saat itu saya hanya menyediakan 3 slot kepada orang-orang yang mau join sesi coffee talk dengan saya secara online.

![https://res.cloudinary.com/yehez/image/upload/v1658824884/Articles/Coffee%20Talk/tweet_mvjcct.png](https://res.cloudinary.com/yehez/image/upload/v1658824884/Articles/Coffee%20Talk/tweet_mvjcct.png)

Mungkin dari beberapa teman pembaca ada yang masih bingung apa itu “coffee talk”? Sebenarnya secara harafiah dapat diartikan ibarat seseorang hangout bersama temannya ke sebuah cafe lalu nongkrong sambil ngopi bersama di sana. Tentunya, karena situasi pandemi yang belum mereda, sesi ini saya buat secara online lewat Google Meet.

Sebelumnya, terima kasih kepada [Dian Yehezkiel](https://twitter.com/dianyehezkiel_), [Fathan](https://twitter.com/fmgono), and Bryan (maaf saya belum tau Twitternya😂) yang telah menghadiri sesi 1 on 1 yang saya buat untuk pertama kalinya. Sebenarnya pengetahuan dan pengalaman kalian jauh di atas saya sih, tapi seperti yang sempat saya singgung di tweet saya, justru saya pun juga perlu mendapatkan insight dari kalian😁.

Nah, dari hasil pembicaraan bersama mereka bertiga, kurang lebih ada 2 hal yang saya dapatkan dari sesi coffee talk ini.

## Ide Baru dan Unik Seringkali Muncul Ketika Ngobrol Santai

Di Indonesia, kita lebih familiar dengan kata “nongkrong”. Saya sendiri telah mengalami bagaimana obrolan tongkrongan justru bisa punya pengaruh lebih besar dalam hidup saya. Saya masih ingat kejadian itu pada awal 2020 ketika masih mengerjakan skripsi di lab kampus sebelum covid mulai ramai.

Saat itu, saya bersama beberapa teman saya sedang stuck dalam pengerjaan aplikasi skripsi kami masing-masing. Ketika makan siang, biasanya kami bareng-bareng pergi ke Lawson seberang kampus dan membeli beberapa snack. Setelahnya, kami menuju ke trotoar pinggir kamus dan nongkrong di sana. Beberapa ada yang sambil merokok, tapi sebagian yang tidak merokok seperti saya biasanya hanya ikut nimbrung dan makan bareng. Bahkan hal itu kami lakukan bersama dosen pembimbing yang memang suka nongkrong juga🤣. 

Benar-benar pengalaman yang mengesankan sih. Ketika kami sedang stuck dalam progress skripsi kami, biasanya kami secara spontan membicarakan itu saat kami nongkrong bersama dosen kami di trotoar pinggir kampus. Kurang lebih setelah sejam kami kembali ke lab, pasti kami kembali dengan ide baru yang bisa-bisanya itu menyelesaikan masalah kami dalam pengerjaan skripsi🤯.

Bisa dikatakan, justru obrolan seperti ini malah lebih berfaedah dibandingkan sesi bimbingan skripsi formal. Kenapa? Karena ketika nongkrong bersama, biasanya kami lebih menyampaikan apa adanya, terutama ketika sedang stuck dan butuh bantuan. Berbeda dengan sesi bimbingan formal yang cenderung malah gugup.

Sama dengan sesi 1 on 1 ini. **Ini bukanlah mockup interview.** Hanya ngobrol santai. Kita bisa sama-sama diskusi hal-hal seperti pengalaman karir, studi, atau hal teknis mengenai frontend development. Terkadang, setelah sesi coffee talk ini, ada saja hal-hal baru yang lahir secara spontan.

## Terasa Seperti Sesi Konseling

Pada mockup interview, tujuannya sudah jelas dan spesifik, yaitu mempersiapkan pesertanya untuk sesi interview perusahaan. Jika pesertanya pesertanya ingin mempersiapkan diri dengan hal-hal teknis (untuk pekerjaan yang berkaitan dengan programming), pastinya sesi mockup interview-nya akan diisi dengan latihan live coding atau menjawab pertanyaan teknis terkait pemrograman.

Saya sebenarnya ingin membuat sesi semacam ini untuk konteks frontend engineering. Tetapi saya sadar diri, pengalaman saya masih jauh dan harus banyak belajar🤣. Karena itulah akhirnya saya memutuskan untuk membuat sesi 1 on 1 kecil-kecilan yang terbuka untuk umum di Twitter.

Dengan [Cal.com](http://Cal.com) setiap yang mau join harus menuliskan apa saja topik yang ingin didiskusikan, supaya sesi 1 on 1 ini tidak kehilangan esensinya. Sebagai contoh, topiknya tentang sharing pengalaman kerja sebagai frontend engineer. Nah selama coffee talk berlangsung, kita bisa saling ngobrolin pengalaman, pernah menghadapi issue apa dan cara menanganinya seperti sesi konseling.

Perlu dicatat bahwa “konseling” ini tidak hanya untuk para peserta, tetapi juga saya pribadi. Justru saya lebih banyak mendapatkan insight baru dari para peserta yang hadir melalui pengalaman dan perspektif mereka. Dengan kata lain, ini seperti konseling dua arah. Yang hadir dan yang membuat agenda sama-sama belajar untuk mendapatkan insight baru.

## Penutup

Nah, kurang lebih itulah pengalaman dan cerita saya terkait sesi 1 on 1. Jangan salah, siapa tau kan hal kecil seperti ini bisa mengubah hidup seseorang padahal hanya obroal casual. Saya pikir kalau para software developer di Indonesia bisa turut membuat kegiatan serupa, secara tidak langsung kita bisa berkontribusi menciptakan talenta digital baru yang handal di negara kita walau hanya lewat obrolan santai.

Semoga ini bisa memberikan perspektif baru ya. Apabila teman-teman ada pengalaman serupa atau sekedar memberikan feedback, silahkan tulis di kolom komentar. Terima kasih.

## Table of contents

- [Disclaimer](#disclaimer)
- [Introduction](#introduction)
- [Gelar vs Sertifikat Biasa](#gelar-vs-sertifikat-biasa)
- [Saya Bisa Belajar Lebih Banyak Hal](#saya-bisa-belajar-lebih-banyak-hal)
- [Networking di Universitas Terasa Berbeda](#networking-di-universitas-terasa-berbeda)
- [Closing](#closing)

## Disclaimer

> Artikel ini murni berasal dari pengalaman dan opini pribadi. Mungkin ada beberapa hal yang kurang relate dengan teman-teman pembaca, atau bahkan belum tentu valid 100%. Setidaknya ini bisa menjadi referensi bagi kalian dalam menentukan pilihan hidup😁.


## Introduction

Cerita bermula ketika saya masih semester 2 saat masih kuliah S1 di tahun 2017. Saya ingat betul ada satu mata kuliah yang namanya Komputer & Masyarakat. Di matkul itu, saya belajar banyak soal etika ilmu komputer di Indonesia. Yang menarik bagi saya adalah dosen pengajar dari matkul ini adalah seorang IT Manager dari sebuah perusahaan asuransi di Gading Serpong.

Satu waktu, saya dan teman saya sempat berincang-bincang dengan pak dosen setelah kelas berakhir dan beliau menceritakan alasan kenapa beliau mau menjadi dosen sekalipun sambil bekerja fulltime sebagai IT Manager. Kurang lebih inilah jawabannya:

> Saya justru sebenernya gak merasa mau jadi dosen awalnya. Saya cuma niat lanjut S2, eh taunya setelah lulus ternyata baru tau bisa jadi dosen buat mahasiswa S1. Gak gimana-gimana sih, saya tetep kerja sebagai IT Manager. Saya tetep bisa kok jadi dosen partime pas weekend kayak gini. Dan sebenarnya ini bentuk “giving back” saya ketika saya ngajar kalian-kalian ini.


Pernyataan beliau inilah yang menjadi cikal bakal ketertarikan saya untuk lanjut studi setelah lulus S1 saat itu.

Setelah lulus S1 tahun 2020 lalu, saya sempat bekerja di sebuah software house di Gading Serpong. Saat itu ada seorang senior sewaktu di kampus yang kebetulan juga bekerja di sana sebagai backend engineer. Namanya adalah ko [Vincentius Kurniawan](https://www.linkedin.com/in/vincentius-kurniawan-88759b146/).

Singkat cerita, saya sempat ngobrol empat mata dengan beliau bertanya-tanya kenapa sih dia mau ambil S2 di Malaysia sebelum kerja dan sekarang malah jadi dosen parttime juga sambil kerja sebagai backend. Inilah jawaban dari beliau kurang lebih:

> Orang itu kebanyakan mikir klo S2 cita-citanya kecil banget mentok jadi dosen. Padahal mereka “miss” sesuatu bahwa jadi dosen itu sebenernya adalah privilege seumur hidup yang didapatkan setelah seseorang lulus S2. Jadi itu bukan tujuan akhir. Kan bisa, “ngedosen” itu jadi side hustle alternative, buat hobi, atau ya “giving back”. Bisa kok kamu tetep kerja sebagai software engineer kayak biasa, pas weekend atau malamnya jadi dosen parttime. Double job kan😁.


Saya tahu bahwa beliau selain bekerja sebagai backend engineer, juga bekerja sebagai dosen parttime di kampus saya sewaktu S1. Dengan kata lain, ya dia bisa “double job”. Weekdays kerja jadi backend engineer, weekend jadi dosen parttime.

Nah dari sinilah keinginan dalam diri saya semakin menguat untuk lanjut studi. Dan setelah saya resign dari kantor tersebut dan mendapatkan job baru di kantor yang sekarang, akhirnya saya memutuskan untuk lanjut kuliah S2 sambil bekerja.

Syukurlah saya mendapat rekan kerja yang suportif, bahkan CTO di tempat saya sekaranglah yang memberikan surat rekomendasi saya untuk lanjut studi🤣. Sebagai informasi ya, saya masih tetap bekerja sebagai frontend engineer kok. Kebetulan di [Binus](https://mmsi.binus.ac.id/) (Information System graduate program) ada program online, jadi bisa deh kuliah di luar jam kerja. Tentunya dengan sistem WFH atau remote working ini menjadi satu benefit tersendiri bagi saya, jadinya gak perlu cape-cape “commuting”. Yang perlu saya khawatirkan ketika kuliah hanyalah listrik dan koneksi internet😂

Nah, kurang lebih inilah penjelasan untuk alasan saya kenapa saya akhirnya memutuskan untuk lanjut S2 jurusan Sistem Informasi.

## Gelar vs Sertifikat Biasa

Seorang teman lama sempat bertanya juga kepada saya, kenapa saya lanjut S2 sementara kan di luar sana banyak bootcamp dan bisa dapet sertifikat juga pula. Inilah jawaban dari saya.

Sebuah Bootcamp kurang lebih berlangsung sekitar 3-6 bulan. Di akhir program, peserta biasanya bisa klaim sertifikat sebagai bukti bahwa pernah mengikuti program Bootcamp dan menyelesaikan tugas akhir yang ditentukan. Tentu ini adalah hal yang sangat baik, karena ini bisa dipakai dan menjadi nilai lebih ketika apply pekerjaan. 

Nah sekarang coba kita bandingkan dengan gelar S2 (dan ijazah tentunya). Biasanya untuk gelar master diperoleh dalam kurun waktu 1,5-2 tahun. Saya bisa mendapat gelar S2 ketika saya menyelesaikan tesis dan mempublikasikannya sebagai paper ilmiah. Ini juga bisa menjadi bukti bahwa saya telah menyelesaikan studi saya dan akhirnya nama saya tambah panjang🤣.

Bedanya apa? Seseorang dengan gelar S2 tentunya akan punya benefit yang lebih “powerful”. Ketika saya sudah lulus S2 nanti, saya punya otoritas untuk memberikan rekomendasi lanjut studi bagi teman atau saudara yang ingin lanjut studi S2 juga. Saya juga bisa menjadi dosen jika saya mau. Dan kebanyakan orang ketika lulus S2, mendapatkan promosi di pekerjaan fulltime mereka karena pasti akan ada “rescaling” dari sisi gaji dan benefit di tempat kerja mereka (tergantung perusahaan).

Perlu diingat, bahwa orang yang lanjut S2 itu tidak berarti cita-citanya sempit hanya ingin menjadi dosen. Itu asumsi yang keliru. Menjadi dosen bukanlah tujuan akhir (kecuali ingin jadi akademisi), itu adalah sebuah privilege atau konsekuensi seumur hidup yang didapatkan seseorang setelah menyelesaikan studi S2. Tentu saja sangat memungkinkan bagi saya untuk menjadi seorang dosen partime tanpa harus meninggalkan pekerjaan saya sebagai frontend engineer. Ketika saya pensiun nanti, mungkin jadi dosen ini bisa jadi karir alternatif juga yang tentu bisa jadi sumber penghasilan tambahan.

## Saya Bisa Belajar Lebih Banyak Hal

Di Bootcamp, peserta biasanya memilih kelas apa yang akan menjadi fokus mereka sampai akhir program tersebut. Misalnya, ada peserta yang ambil path Bootcamp Frontend Engineering selama 6 bulan.  Dia akan fokus untuk belajar mengenai frontend engineering saja. Itu berarti, dia akan fokus belajar sesuai dengan preferensi kelas yang ia pilih.

Saya saat ini mengambil jurusan Sistem Informasi untuk S2. Cukup banyak mata kuliah yang harus diselesaikan sepanjang 1,5 tahun ke depan. Sekalipun masih satu rumpun dengan S1 saya (Informatika) dan pengalaman bekerja sebagai frontend engineer, tetapi di sini saya belajar banyak mengenai project management dan software architecture yang sebenarnya agak menyimpang dari skillset saya saat ini. Mengerti apa yang saya maksud di sini? Saya jadi harus belajar mata kuliah yang mungkin bukan preferensi saya atau bahkan saya kurang suka. Jangan salah tangkap, justru dengan ini saya bisa memperlebar pengetahuan saya dan pastinya akan menhindarkan saya dari mental block saya untuk memahami bidang lain.

Seorang teman ada yang bertanya kepada saya, “Lu kan S1 Informatika, kenapa ambil Sistem Informasi dah?”. Jawaban saya simpel karena saya sudah terlalu “muak” atau jenuh dengan hal-hal berbau teknis sepanjang kuliah S1 selama 4 tahun. Ditambah, saya sudah bekerja sebagai frontend engineer hampir 2 tahun. Sudah banyak hal teknis yang saya pelajari dan hadapi sehari-hari. Jadi, saya memutuskan untuk memperlebar skillset saya sekaligus mempersiapkan career path saya di masa depan, ya bisa dibilang saya ingin menjadi Tech Lead.

Inilah alasan kenapa saya ambil jurusan Sistem Informasi, sehingga ke depan saya bisa menjadi software engineer yang lebih [product-minded](https://blog.pragmaticengineer.com/the-product-minded-engineer/). Siapa tahu kan dalam 2-3 tahun ke depan saya akhirnya bisa menjadi seorang frontend lead. Tentunya dengan ini saya harus improve skill komunikasi dan project management saya melalui kuliah S2 ini.

## Networking di Universitas Terasa Berbeda

Sebenarnya networking ini bisa didapatkan di mana saja. Tapi entah kenapa bagi saya, networking di kampus itu terasa berbeda. Di Bootcamp, seseorang bisa dapat kenalan baru yang punya interset yang mirip atau bahkan sama sesuai dengan subject dari Bootcamp yang dipilih. Misalnya Bootcamp frontend, ya pasti circle pertemanan di situ hanya seputaran orang-orang frontend saja. Berbeda dengan kuliah, teman-teman saya bisa lebih “diverse” dari segi interest tesis atau background nya.

Contohnya sekarang ini, teman-teman kuliah saya berasal dari background yang cukup beragam, mulai dari Product Manager, SAP Consultant, IT Consultant, dan lain-lain. Ketika berbincang-bincang mengenai topik tesis, topiknya beragam pula, mulai dari computer security, project management, dan topik lainnya. Justru dengan perbedaan seperti ini saya bisa belajar lebih banyak dari lingkungan seperti ini.

## Closing

Nah kurang lebih itulah penjelasan mengenai alasan saya lanjut S2 Sistem Informasi. Masih banyak sih yang mau diceritakan, tetapi agak sulit mengungkapkannya dalam bentuk tulisan artikel. Apakah perlu saya ceritakan ini di Twitter Space atau Podcast? Tolong invite saya sebagai pembicara tamu kalau enggak keberatan🤣.

Boleh banget kalau ada hal yang mau didiskusikan di sini, bisa tuliskan di kolom komentar di bawah ya.

Life Update: Akhirnya Memutuskan Lanjut S2

## Table of contents

- [Disclaimer](#disclaimer)
- [Pendahuluan](#pendahuluan)
- [Persiapan](#persiapan)
- [Setup ESLint Rules](#setup-eslint-rules)
- [Publish Di NPM Registry](#publish-di-npm-registry)
- [Penutup](#penutup)

## Disclaimer

> Di tutorial ini, saya akan fokus untuk membuat ESLint rules untuk project berbasiskan Typescript. Teman-teman pembaca tidak perlu meniru 100% tutorial ini, silahkan menyesuaikan dengan kebutuhan masing-masing ya.

## Pendahuluan

Baru-baru ini, saya merasa cukup malas kalau harus menulis ulang ESLint rules yang sama dan berulang ketika membuat personal project baru. Lihat potongan kode di bawah ini. Mungkin teman-teman sedikit *notice*, dan ya ini adalah potongan kode seperti dalam blog saya sebelumnya yang berjudul [Standardize Your Next.js Project](https://yehezgun.com/articles/standardize-your-nextjs-project).

```json
{
  "env": {
    "node": true
  },
  "extends": [
    "next/core-web-vitals",
    "eslint:recommended",
    "plugin:@typescript-eslint/recommended"
  ],
  "parser": "@typescript-eslint/parser",
  "plugins": ["import", "unused-imports", "@typescript-eslint"],
  "settings": {
    "import/resolver": {
      "node": {
        "extensions": [".js", ".jsx", ".ts", ".tsx"],
        "moduleDirectory": ["node_modules", "src/"]
      }
    }
  },
  "rules": {
    "no-unused-vars": "off",
    "@typescript-eslint/no-unused-vars": "off",
    "@typescript-eslint/explicit-module-boundary-types": "off",
    "@typescript-eslint/no-non-null-assertion": "off",
    "@typescript-eslint/no-inferrable-types": "off",
    "@next/next/no-img-element": "off",
    "unused-imports/no-unused-imports": "error",
    "unused-imports/no-unused-vars": [
      "warn",
      {
        "vars": "all",
        "varsIgnorePattern": "^_",
        "args": "after-used",
        "argsIgnorePattern": "^_"
      }
    ],

    "no-eq-null": "warn",
    "import/order": [
      "warn",
      {
        "groups": [
          ["builtin", "external"],
          "internal",
          "parent",
          ["sibling", "index"],
          "object"
        ],
        "newlines-between": "always",
        "alphabetize": {
          "order": "asc",
          "caseInsensitive": true
        }
      }
    ],
    "complexity": "warn",
    "no-console": ["error"]
  }
}
```

Saya tahu dari seorang teman lama (teman kuliah), dia membuat dan publish ESLint Config miliknya menjadi library npm package. Bisa diakses di [sini](https://www.npmjs.com/package/eslint-config-sznm). Kok bisa-bisanya dia niat membuat hal ini? Singkatnya, ini agar ketika dia membuat project baru terutama personal project, dia cukup extend ESLint rules yang dia publish saja. Tidak perlu menulis ESLint rules lagi dari nol.

```jsx
module.exports = {
  extends: ['sznm'],
};
```

Nah, cerita dialah yang menginspirasi saya untuk membuat ESLint config milik saya sendiri.

## Persiapan

Pertama, tentu kita harus buat project directory-nya. Nah, `eslint-config-test` ini bisa kalian ganti dengan preferensi nama sesuka kalian. Tetapi perlu diingat prefix `eslint-config` harus tetap ada agar bisa dipublish ke NPM registry sebagai ESLint Config Library.

```bash
mkdir eslint-config-test
cd eslint-config-test
yarn init
```

Setelah itu, kurang lebih inilah isi dari `package.json` yang terbentuk.

```json
{
  "name": "eslint-config-test",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "",
  "license": "ISC"
}
```

Sekarang, install dependencies yang diperlukan untuk membuat ESLint config. Nah di sini, kalian bisa menyesuaikan dengan kebutuhan masing-masing ya. Tidak perlu meniru 100% apa yang saya install.

```bash
yarn add @typescript-eslint/eslint-plugin @typescript-eslint/parser eslint eslint-plugin-import eslint-plugin-sonarjs eslint-plugin-unused-imports
```

## Setup ESLint Rules

Sekarang, kita mulai menuliskan ESLint rules-nya. Buat file`eslintrc.js` , lalu modifikasi dengan ESLint rules yang kalian preferensikan. Sebagai referensi atau contoh, inilah milik saya.

```jsx
module.exports = {
  env: {
    node: true,
  },
  extends: [
    "eslint:recommended",
    "plugin:@typescript-eslint/recommended",
    "plugin:sonarjs/recommended",
  ],
  parser: "@typescript-eslint/parser",
  plugins: ["@typescript-eslint", "import", "unused-imports"],
  settings: {
    "import/resolver": {
      node: {
        extensions: [".js", ".jsx", ".ts", ".tsx"],
        moduleDirectory: ["node_modules", "src/"],
      },
    },
  },
  rules: {
    "no-unused-vars": "off",
    "no-var": "warn",
    "@typescript-eslint/no-unused-vars": "off",
    "unused-imports/no-unused-imports": "error",
    "unused-imports/no-unused-vars": [
      "warn",
      {
        vars: "all",
        varsIgnorePattern: "^_",
        args: "after-used",
        argsIgnorePattern: "^_",
      },
    ],
    "@typescript-eslint/explicit-module-boundary-types": "off",
    "@typescript-eslint/no-non-null-assertion": "off",
    "@typescript-eslint/no-inferrable-types": "off",
    "import/order": [
      "warn",
      {
        groups: [
          ["builtin", "external"],
          "internal",
          "parent",
          ["sibling", "index"],
          "object",
        ],
        "newlines-between": "always",
        alphabetize: {
          order: "asc",
          caseInsensitive: true,
        },
      },
    ],
    complexity: "warn",
    "no-console": ["error"],
  },
};
```

Setelah selesai tahap ini, jangan lupa import `eslintrc.js`nya di `index.js`.

```jsx
const eslintrc = require("./.eslintrc.js");
module.exports = eslintrc;
```

## Publish Di NPM Registry

Nah secara teknis, kalian sudah bisa publish ESLint rules ala-ala kalian. Tinggal jalankan `npm publish` atau `yarn publish`. Lalu ikuti tahapan yang ada di dalam tampilan terminal kalian. Kalian juga bisa membuat akun NPM registry apabila belum memilikinya.

Cara penggunaannya, cukup mudah. Tinggal extend saja ESLint Config Library yang telah kalian publikasi tersebut ke dalam file `eslintrc` project kalian. Sebagai referensi, inilah ESLint Config Library saya, bisa diakses di [eslint-config-yehezgun](https://www.npmjs.com/package/eslint-config-yehezgun).

## Penutup

Cukup singkat ya blog ini😂, tetapi jangan salah. Efeknya akan berdampak dalam jangka panjang. Kalian hanya perlu mengubah ESLint config yang telah kalian publish sebelumnya ketika dibutuhkan, dan otomatis config-nya akan terimplementasi di semua project yang menggunakannya (dengan catatan, versi dependenciesnya juga diupdate).

Terima kasih sudah menyempatkan membaca. Semoga membantu🙃.

Reference:

- [eslint-config-sznm](https://www.npmjs.com/package/eslint-config-sznm)
- Freecodecamp blog - [How To Create Your Own ESLint Config Package](https://www.freecodecamp.org/news/creating-your-own-eslint-config-package/)

Cara Publish ESLint Config Kamu Sebagai NPM Package

## Table of contents

- [Disclaimer](#disclaimer)
- [Introduction](#introduction)
- [Fundamental Itu Krusial](#fundamental-itu-krusial)
- [Fokus ke Hal Esensial](#fokus-ke-hal-esensial)
- [Apa yang Dilakukan Sekarang Bisa Mempengaruhi Masa Depan](#apa-yang-dilakukan-sekarang-bisa-mempengaruhi-masa-depan)
- [Environment Juga Berperan Penting](#environment-juga-berperan-penting)
- [Closing](#closing)

## Disclaimer
> Seperti biasa, ini berdasarkan pengalaman pribadi. Mungkin bagi sebagian orang bisa kurang relate dan belum tentu 100% valid, setidaknya ini bisa jadi sekedar referensi ya.

## Introduction
Cerita dimulai ketika saya baru wisuda dari kampus says pada Juni 2020 lalu. Itu adalah moment yang cukup sulit karena Covid-19 baru merebak ke seluruh dunia, termasuk Indonesia. Tidak hanya saya rupanya, teman-teman seangkatan saya pun menghadapi masalah yang serupa. Ya tepat, kesulitan mencari kerja setelah lulus. Saya pun mendapati banyak teman saya yang akhirnya terpaksa banting stir ke pekerjaan non-IT (tidak linear dengan jurusan kuliah) demi memenuhi kebutuhan hidup.

Setelah beberapa minggu, satu per satu teman-teman saya mulai mendapatkan pekerjaan fulltime pertama mereka. Tentunya ini membuat saya minder dan overthinking. Saya pun berupaya apply ke beberapa perusahaan, tetapi pandemi Covid-19 membuat banyak perusahaan memberlakukan "hiring freeze". Tapi syukurlah, pada September 2020, bersama dengan beberapa teman kuliah dan bahkan junior (beda satu tahun), kami bisa mendapatkan pekerjaan di sebuah software house di Gading Serpong. Kantornya hanya di ruko kecil yang terletak dekat Pasar Modern Gading Serpong, tetapi saat itu kami semua berpikir yang penting bekerja dulu agar bisa memenuhi kebutuhan sehari-hari.

Saat itu, saya sendiri bekerja sebagai frontend engineer, tetapi lebih sering berkecimpung dalam pengembangan hybrid mobile app menggunakan Ionic dan Angular. Aplikasi yang sempat saya kembangkan adalah [KAI Access](https://play.google.com/store/apps/details?id=com.kai.kaiticketing&hl=en_US). Jujur, saya sebenarnya kurang suka dengan role saya saat itu. Saya prefer lebih fokus dalam bidang web development, tetapi apa daya situasi saat itu cukup berat dan saya juga masih fresh graduate, jadi masih berusaha optimist setidaknya ini bisa menjadi batu loncatan bagi saya.

Ternyata, pada kenyataannya berat sekali. Pada Juni 2021, saya akhirnya burnout dengan pekerjaan saya bahkan sampai mempengaruhi fisik saya. Mulai dari GERD sampai insomnia beberapa minggu. Saya pun terpaksa WFH walaupun saat itu perusahaan memberlakukan WFO. Ya kurang lebih saya harus berjuang dengan pekerjaan yang tidak saya suka dan nikmati selama setahun lebih hingga akhirnya saya memutuskan untuk mencari opportunity baru.

Syukurlah sekitar bulan Juli 2021, ada seorang teman kuliah yang menawarkan project freelance dan akhirnya saya pun join dengan dia untuk membuat sebuah warehouse system dengan React di luar jam kerja. Ini adalah pertama kali saya menggunakan React untuk project real case. Sejak itulah saya mulai suka dengan ekosistem React dan terus belajar hingga sekarang.

Pada Agustus 2021, saya lanjut belajar lebih dalam React dan Next.js. Project pertama yang saya buat sendiri adalah web personal saya di [yehezgun.com](https://yehezgun.com). Itu adalah project mainstream yang biasa dibuat banyak orang ketika baru belajar web. Tetapi, sejak saya mulai berani mempublikasikannya di Linkedin, beberapa recruiter mulai approach saya. Tentunya ini juga memotivasi saya untuk terus membuat mini-project dan artikel secara rutin (2x sebulan).

Syukurlah pada November 2021, seorang recruiter dari tempat saya bekerja sekarang approach saya via Linkedin. Saya ditawari role sebagai web frontend engineer. Tentunya, ini adalah role yang saya impikan dan saya pun mengikuti segala proses rekrutmen hingga saya pun akhirnya diterima dan sampai di titik ini.

Sungguh menyenangkan saya bisa bekerja sesuai dengan role yang saya impikan. Ditambah, kultur kerja di sini sangat suportif. Manager saya juga support apabila karyawannya punya kegiatan lain di luar pekerjaan utama misalnya seperti kegiatan komunitas atau semacam course instructor.

Selama setahunan ini (hampir 2 tahun🤣), saya belajar banyak dari yang tadinya berjuang mendapatkan pekerjaan fulltime pertama, burnout, hingga akhirnya bisa dapat job yang lebih baik. Seperti sesi retrospective, kurang lebih ada 4 point yang ingin saya bagikan kepada teman-teman pembaca.

## Fundamental Itu Krusial
Saya sudah sempat menyinggung ini di artikel saya sebelumnya yang berjudul [Why Fundamental Matters?](https://yehezgun.com/articles/why-fundamental-matters). Ini membuat saya sadar bahwa seharusnya fundamental itu jangan dilewatkan sebelum melangkah lebih jauh. 

Flashback saat saya baru lulus kuliah, saya langsung belajar frontend development secara "premature", langsung belajar tools dan framework seperti React, Angular, dan Vue tanpa belajar dasar Javascript terlebih dahulu. Ketika saya bekerja di kantor sebelumnya yang menggunakan Angular, saya pun sering bergumul dengan task yang ada karena saya sering harus develop kode sendiri tanpa mengandalkan third-party tools.

Masalah lain adalah ketika di kantor yang sekarang sejak Januari 2022. Saya belajar ulang syntax dasar Javascript karena di sini saya menggunakan React sebagai tech stack utama. Tidak hanya itu, saya pun kembali harus belajar dasar-dasar CSS karena menggunakan Tailwind CSS untuk styling.

> Kalau saja saat itu fundamental skill sudah solid, mungkin bukan masalah besar ketika harus berganti-ganti tools atau framework. Jadi hanya perlu adaptasi syntax saja tanpa perlu belajar ulang semuanya.

## Fokus ke Hal Esensial
Entah saya saja atau orang-orang lain juga merasakannya, semakin banyak pengalaman di dunia kerja, semakin sadar bahwa kita harus bijak dalam memilih tools atau framework yang digunakan untuk menyelesaikan masalah.


Sebagai contoh, saya sudah belajar dan menggunakan Angular sejak kuliah hingga bekerja di tempat kerja saya yang sebelumnya. Awalnya, saya pikir Angular itu mudah karena fitur CLInya memudahkan ketika generate page atau component baru, dan imperative paradigm yang menurut saya cukup menarik saat itu.

Semua berubah ketika saya sudah bekerja sekitar 6 bulan dan menyadari bahwa komunitas Angular sudah cukup langka dan sulit sekali menemukan solusi yang relevant ketika troubleshooting. Karena itulah, tak jarang saya harus membuat beberapa logic dari 0😵. Tidak hanya itu, ketika saya mencari pekerjaan baru, kebanyakan perusahaan sudah menggunakan React sebagai tech stack utama.

Saya sempat menyinggung ini di artikel sebelumnya yang berjudul [Frontend Fatigue](https://yehezgun.com/articles/frontend-fatigue). Seharusnya saya memilih tools atau framework yang sudah proven, punya komunitas yang luas, dan tentunya bisa menyelesaikan masalah yang ingin saya pecahkan.

> Fokus pada problem-solving. Pilih tools yang cocok dengan kebutuhan kita yang membantu kita menyelesaikan masalahnya, bukan malah memperberat hidup😂.

## Apa yang Dilakukan Sekarang Bisa Mempengaruhi Masa Depan
Saya ingat betul ketika saya memulai kebiasaan menulis artikel secara rutin sejak awal tahun 2021. Awalnya saya publikasi dalam bahasa Indonesia di [diskusi.tech](https://diskusi.tech/yehezkielgunawan). Saya hanya sekedar berbagi pengalaman dan bagaimana saya mengatasi masalah yang saya hadapi dengan bahasa yang simple dan tidak terlalu berat.

Pada tengah tahun 2021, saya mulai membuat personal web saya sendiri, [yehezgun. com](https://yehezgun.com). Saat itu, saya mulai membiasakan juga menulis dalam bahasa Inggris untuk melatih writing skill saya dan mempublikasikannya. Tidak hanya artikel, saya juga mulai rutin membuat mini-project dan mempublikasikannya di web saya.

Sekitar 6 bulan kemudian, akhirnya beberapa recruiter approach saya dan saya pun bisa mendapatkan pekerjaan saya yang sekarang karena kebiasaan saya ini. Saya sempat menyinggung ini di artikel saya sebelumnya yang berjudul [How To Get Hired Without Applying](https://yehezgun.com/articles/how-to-get-hired-without-applying).

Tidak hanya personal portfolio, saya juga join sebagai volunteer (cloud advisor) di Bangkit Academy. Tahun ini pun saya terlibat sebagai instructor dan capstone mentor. Jujur, saya tidak memiliki background sebagai cloud engineer, tetapi karena role saya sebagai instructor dan mentor, saya harus belajar secara mandiri agar saya bisa menyampaikan materi dengan baik dan dimengerti oleh cohort saya🤯.

Jangan salah, justru dengan pengalaman seperti ini saya belajar 2x. Saya belajar untuk diri saya sendiri dan belajar lagi untuk bagaimana menyampaikannya dengan bahasa yang mudah dimengerti kepada cohort saya saat itu. Ini berefek cukup besar bagi karir saya. Sekalipun saya bekerja sebagai frontend engineer, saya bisa tidak terlalu bergantung pada SRE (Site Reliability Engineer) di tempat saya untuk perihal deployment karena saya bisa melakukan itu secara mandiri😆 berkat pengalaman saya yang sudah sering berjumpa dengan istilah-istilah cloud engineering.

> Perlu diingat bahwa dirimu yang sekarang sebenarnya telah dibangun oleh kebiasaan dan pengalamanmu di masa lalu juga.

## Environment Juga Berperan Penting
Awalnya saya pikir bekerja di software house itu menyenangkan karena saya bisa belajar dari banyak project yang dibuat, tapi ternyata saya keliru. Project yang dibuat kebanyakan berasal dari request client dan "tidak bisa diinterupsi". Jika client bilang A, ya harus deliver A.

Masalah lainnya adalah code pattern. Karena projectnya banyak dan deadlinenya mepet, seringkali yang terpikir dalam kepala adalah yang penting bisa deliver itu tepat waktu ke client tanpa memikirkan kualitas kode yang dibuat. Tak jarang, kalau harus pindah project, cukup banyak waktu yang dihabiskan hanya untuk memahami ulang alur dan maksud kodingan dari existing project 🙃.

Ini akhirnya membuat saya berinisiatif untuk mencari pekerjaan baru yang tergolong sebagai in-house company yang memiliki dedicated product yang tentunya sudah memiliki development pattern yang sudah terbentuk. Akhirnya saya resign dari pekerjaan lama saya dan pindah ke kantor saya yang sekarang.

Bekerja di in-house company itu seperti menambahkan potongan puzzle ke board yang ada. Tentunya, karena itulah kodingan yang dibuat pun harus terstandarisasi dan memiliki pattern yang proper agar kualitas produk tetap terjaga. Tapi dalam kasus saya sih, saya masih bergulat dengan urusan rewrite landing page dari tech stack lama ke React (Next.js)🙃, tetapi justru karena itu saya bisa bekerja sambil belajar, terutama perihal Next.js sebagai tech stack favorite saya.

Yang paling menarik adalah ini adalah pertama kali saya memiliki senior yang bisa menjadi mentor dalam karir saya. Ketika saya stuck dalam mengerjakan task, saya bisa bertanya kepada mereka approach apa yang bisa digunakan untuk menyelesaikannya. Sekalipun bekerja secara remote, tetapi kami bisa tetap "klop" dalam berkomunikasi entah lewat Google Meet atau chat di Slack. Bagi saya, inilah kultur kerja ideal yang membantu saya untuk bertumbuh ke arah yang lebih baik.

> Culture fit itu bukan mitos. Itu bisa membantu seseorang bertumbuh menjadi pribadi yang lebih baik.

## Closing
Ya, kurang lebih itulah cerita saya. Terlihat seperti sesi retrospective ya😆. Gak apa-apa, setidaknya semoga ada insight baru ya dari pengalaman saya ini sebagai frontend engineer (yang masih harus belajar banyak).

Retrospective: 1 Tahun Bekerja Sebagai Frontend Engineer

## Daftar Isi

- [Disclaimer](#disclaimer)
- [Introduction](#introduction)
- [Kenapa Fundamental Itu Penting?](#kenapa-fundamental-itu-penting)
  - [Bayangkan Kamu Harus Bekerja Menggunakan Tools yang Bukan Preferensimu](#bayangkan-kamu-harus-bekerja-menggunakan-tools-yang-bukan-preferensimu)
  - [Cepat atau Lambat Kamu Tidak Bisa Bergantung Pada Tools](#cepat-atau-lambat-kamu-tidak-bisa-bergantung-pada-tools)
- [Bagaimana Cara Mengatasi atau Menghadapinya?](#bagaimana-cara-mengatasi-atau-menghadapinya)
  - [Belajar Lagi Dari 0](#belajar-lagi-dari-0)
  - [Gunakan Tools atau Framework Yang Memaksa Kamu Mempelajari Fundamentalnya Sembari Kamu Menggunakannya](#gunakan-tools-atau-framework-yang-memaksa-kamu-mempelajari-fundamentalnya-sembari-kamu-menggunakannya)
- [Closing](#closing)

## Disclaimer

> Seperti artikel sebelumnya, ini berdasarkan pengalaman pribadi dan hasil pembicaraan dari beberapa teman saya. Mungkin beberapa teman pembaca memiliki pengalaman berbeda, tetapi setidaknya ini bisa menjadi referensi.


## Introduction

Cerita dimulai ketika saya lulus S1 pada Juni 2020 dan bergumul mencari pekerjaan saat itu. Saya dengan polosnya skip bagian fundamental dan langsung loncat ke framework seperti React, Vue, dan Angular. Saya mengalami sendiri bagaimana sulitnya untuk lolos user interview di beberapa perusahaan, terutama yang menggunakan metode live coding interview. Kebanyakan soal yang diberikan adalah soal-soal dasar yang sebenarnya tidak terlalu sulit, tetapi saya kelabakan sendiri karena lemahnya basic skill saya saat itu.

Beruntung pada September 2020, saya bisa mendapatkan pekerjaan pertama sebagai frontend engineer di sebuah software house company. Saat itu, tesnya hanya berupa take home tes menggunakan framework Angular dan syukurlah saya bisa lolos. Saat bekerja di sana saya kebanyakan menggunakan [Ionic](https://ionicframework.com/) dan Angular sebagai tech stack utama. Bahkan, saya pribadi jarang menggunakan custom CSS kurang lebih setahun karena Ionic sudah menyediakan UI Component yang sedemikian rupa sehingga jarang sekali perlu dicustom.

Masalah baru muncul setelah setahun lebih saya bekerja dan tidak berniat untuk memperpanjang kontrak di sana, otomatis saya harus mengulang kembali menjadi job seeker seperti saat saya masih fresh graduate. Cukup banyak kegagalan yang saya alami ketika user interview.

Setelah bergumul ke sana kemari, syukurlah saya bisa mendapatkan pekerjaan baru di kantor yang sekarang sekitar Desember 2021 (on boarding pada Januari 2022). Jenis tes yang dijalani juga merupakan take-home test, sehingga saya bisa memaksimalkan segala potensi saya agar bisa lolos saat itu. Saya akhirnya lolos user interview dan memutuskan untuk menerima offer yang diberikan.

Masalah lain muncul ketika 3 bulan pertama saya masih harus bergulat dengan task kantor yang berkaitan dengan styling (CSS). Saya sebenarnya biasa saja ketika harus koding hal-hal yang terkait logic seperti integrasi, data fetching atau data manipulation. Tetapi, kalau styling, itu adalah kelemahan terbesar saya😂..

Seperti yang pernah saya tulis di artikel saya yang berjudul “[I Remake My Personal Site using Tailwind CSS](https://yehezgun.com/articles/remake-using-tailwind-css)”, saya terlalu bergantung kepada tools atau framework. Dalam kasus saya, kebanyakan terlalu bergantung pada UI Component Library seperti Chakra UI. Saya bisa dengan mudah dan cepat styling dengan Chakra UI, tetapi ketika saya harus berganti menggunakan framework lain atau bahkan native CSS, itu cukup untuk membuat saya tidak tidur seharian😆.

Saat itu, saya bahkan cukup kesulitan membuat layout sederhana hingga menghabiskan berjam-jam menggunakan Tailwind CSS dan custom CSS😩. Di situlah saya sadar, fundamental harusnya jangan dilewatkan sebelum lebih jauh terjun menggunakan tools seperti Chakra UI, Bootstrap, atau tools lain. 

Setelah sekitar 3 bulan bergulat dengan hal-hal sederhana ini, kurang lebih inilah alasan saya mengapa segalanya harus dimulai dari yang dasar dahulu.

## Kenapa Fundamental Itu Penting?

### Bayangkan Kamu Harus Bekerja Menggunakan Tools yang Bukan Preferensimu

Nah inilah yang terjadi pada saya😂. Singkatnya, saya melewatkan dasar-dasar Javascript dan CSS, langsung terjun ke React, Next.js dan Chakra UI.

Di kantor pertama saya ketika saya bekerja sebagai frontend engineer, saya mendapatkan project yang menggunakan Ionic. Untuk 3 bulan pertama, saya cukup bergumul dengan syntax Ionic dan Angular. Beruntungnya kalau masalah styling tidak terlalu sulit karena kebanyakan menggunakan UI Component bawaan dari Ionic, jarang sekali custom CSS.

Setahun kemudian, ketika saya pindah ke kantor yang sekarang, saya masih dalam kebiasaan buruk saya yaitu skip bagian fundamental. Lalu tiba saatnya saya diberikan task yang menggunakan Tailwind CSS. Untuk bagian logic, seperti yang sebelumnya saya katakan, saya tidak begitu kesulitan. Begitu harus membuat styling, itulah saat yang paling “horror” karena saya belum mengerti dasar CSS meskipun saya bekerja sebagai frontend engineer😩.

Sepanjang proses probation, saya pun masih harus bergulat dengan task yang berkaitan dengan styling ini. Saya bahkan harus menghabiskan berjam-jam hanya untuk membuat layout sederhana. Untungnya, seiring waktu, saya juga mempelajari Tailwind CSS di waktu senggang saya dan akhirnya bisa mengatasinya. Kalian bisa baca artikel saya di [sini](https://yehezgun.com/articles/remake-using-tailwind-css) untuk cerita lebih lanjut.

Nah apakah kalian menyadari sesuatu di sini? **Kamu bisa langsung loncat ke framework atau tools tanpa belajar fundamental. Mungkin itu bukan masalah besar sampai akhirnya kamu harus bekerja tanpa framework atau tools preferensimu. Pasti akan cukup melelahkan untuk beradaptasi karena belum adanya pemahaman dasar yang solid akan hal itu.**

### Cepat atau Lambat Kamu Tidak Bisa Bergantung Pada Tools

Ketika di kantor lama, saya terlalu bergantung pada third-party tools hampir di setiap task yang diberikan. Saya pernah diberikan sebuah task untuk menampilkan maps di mobile app dan itu butuh waktu hampir beberapa minggu hanya untuk menemukan third-party library yang cocok.

Sebenarnya dalam beberapa hari saya menemukan library [Angular Google Maps](https://angular-maps.com/) dan bisa menyelesaikan task pada saat itu (untuk sementara). Masalah baru muncul ketika client terkait meminta untuk custom tampilan yang ada. Ini bahkan sempat membuat saya sakit karena butuh beberapa hari kemudian sampai akhirnya fitur tersebut selesai. Mudah memang menggunakan third-party tools, tetapi itu akan sulit di-customize.

Yang berikutnya adalah di kantor yang sekarang. Saya berdiskusi dengan tim UI/UX tentang project web terbaru yang akan dibuat nantinya. Saat itu sang manager sudah menetapkan tools apa saja yang sekiranya bisa digunakan. Tetapi endignnya, kami memutuskan Tailwind CSS sebagai styling framework utama, karena kami butuh yang bisa di-custom sesuai kebutuhan. Kalau tidak ada tools yang bisa di-custom, ya tentu harus bisa buat sendiri bukan?

Manager saya bahkan pernah mengatakan ini dalam sesi probation review saya.

> Perkuat fundamental kamu, terutama perihal CSS. Suatu hari kamu gak akan bisa bergantung sama tools yang ada di luar sana.
> 

## Bagaimana Cara Mengatasi atau Menghadapinya?

Bagaimana kalau seandainya saya sudah terlanjur melewatkan fundamental dan terlalu bergantung dengan tools?

Tenang, masih ada harapan di sini😁. Saya pun masih bergumul kok dengan hal ini. Kurang lebih ini tips dari saya yang bahkan sampai sekarang masih saya lakukan.

### Belajar Lagi Dari 0

Kalau punya waktu senggang di luar jam kerja, cobalah sempatkan untuk belajar lagi hal-hal dasar. Kamu bisa pakai situs belajar pemrograman seperti [Freecodecamp](https://www.freecodecamp.org/) atau [Hackerrank](https://www.hackerrank.com/) untuk melatih kemampuan teknis pemrograman lewat coding challenges yang diberikan. Jika kamu seorang frontend engineer dan mau mempertajam pemahaman flexbox, bisa coba [Flexbox Froggy Game](https://flexboxfroggy.com/). Itu adalah game berbasis web yang bisa menolong kamu untuk memahami cara kerja flexbox.

Dari pengalaman saya pribadi, sangat sulit rupanya menemukan waktu yang pas untuk belajar dari 0 karena saat masih bergumul mencari kerja, saya harus kejar-kejaran dengan waktu untuk mendapatkan pekerjaan. Sekarang pun juga sulit karena sudah bekerja fulltime. Tetapi bukan berarti saya tidak bisa belajar lagi.

Di waktu senggang saya, biasa saya sempatkan follow akun Twitter [Kevin Powel](https://twitter.com/KevinJPowell) (seorang CSS Expert) dan menonton beberapa videonya di Youtube. Setidaknya itu bisa membantu saya untuk memahami dasar CSS secara teori. Kalau kamu kesulitan menemukan waktu yang pas untuk belajar, setidaknya sempatkan sekedar membaca konsep dasar dari dokumentasi resmi seperti [MDN](https://developer.mozilla.org/en-US/docs/Web/CSS) atau menonton video youtube yang membahas dasar-dasar pemrograman.

### Gunakan Tools atau Framework Yang Memaksa Kamu Mempelajari Fundamentalnya Sembari Kamu Menggunakannya

Nah inilah yang menurut saya paling berdampak bagi saya pribadi. Ketika kamu tidak punya waktu untuk belajar fundamentalnya, pilih tools atau framework yang memaksa kamu mempelajari itu sembari kamu menggunakannya. Seperti yang sempat saya katakan sebelumnya di artikel saya di [sini](https://yehezgun.com/articles/remake-using-tailwind-css), saya menemukan itu ketika saya menggunakan Tailwind CSS.

Meskipun saya tidak secara langsung menggunakan syntax CSS, tetapi saya bisa belajar dasar-dasar CSS sembari menggunakan syntax Tailwind. Untuk membuat kode yang baik dan efektif, terutama ketika styling menggunakan Tailwind CSS, saya harus paham dulu dasar-dasar seperti flex, grid, margin, padding, dan konsep CSS lainnya.

Ini juga berlaku di React. Sekalipun React adalah library Javascript, tetapi “jeroannya” kan tetap syntax Javascript yang mau tidak mau harus dipahami dulu sebelum lebih jauh melangkah kan. Saya pun terpaksa belajar ulang [Javascript syntax](https://dev.to/nsebhastian/javascript-basics-before-you-learn-react-38en) supaya kode React yang dihasilkan lebih clean dan efektikf.

Beruntung di tempat kerja saya yang sekarang juga menggunakan React dan Tailwind CSS sebagai tech stack utama, sehingga saya bisa bekerja sekaligus belajar tech stack baru ini😁.

## Closing

> Perkuat fundamental dulu sebelum menggunakan framework atau tools. Itu akan mempermudahmu ketika menghadapi issue atau problem yang ada karena kamu sudah paham konsep dasarnya, bukan hanya tools itu sendiri.


Cepat atau lambat, kita tidak bisa selalu bergantung pada tools. Saya pernah mengalaminya ketika sedang develop fitur map untuk [KAI Access](https://play.google.com/store/apps/details?id=com.kai.kaiticketing&gl=US) dan itu sangat melelahkan, terutama ketika harus custom tampilan dari tools yang sebenarnya sudah *deprecated.*

Kamu juga mungkin akan kesulitan mendapatkan pekerjaan karena sekarang ini kebanyakan perusahaan sudah menerapkan metode live coding interview atau “agnostic” test case untuk kandidat programmer. Saya sendiri pernah gagal dalam proses user interview seperti ini karena belum adanya skill dasar yang solid.

Tapi, jangan khawatir, tetaplah konsisten belajar. Jangan terlalu FOMO. Saya mengerti banyak framework atau tools di luar sana. Bahkan saya sempat menyinggungnya di artikel saya yang berjudul [Frontend Fatigue](https://yehezgun.com/articles/frontend-fatigue).

Tapi sekali lagi, **pelajari fundamentalnya dahulu!** Saya tahu mungkin ini bisa membuat kamu jadi lebih lambat. **Lebih baik lambat belajar tetapi dengan pemahaman yang solid, dibandingkan memaksakan diri belajar banyak malah jadi burnout dan stress sendiri.** Belajar itu seperti marathon, bukan lari sprint.

Terima kasih sudah membaca artikel ini, semoga membantu. Apabila ada hal yang ingin didiskusikan, boleh tuliskan di kolom komentar ya.

Ingin catch-up dengan saya lebih lanjut? Boleh follow Twitter saya di [@YehezGun](https://twitter.com/YehezGun).

Pentingnya Fundamental

## Daftar Isi

- [Disclaimer](#disclaimer)
- [Introduction](#introduction)
- [Saya Belajar Dasar CSS Ketika Menggunakan Tailwind CSS](#saya-belajar-dasar-css-ketika-menggunakan-tailwind-css)
- [Bisa Di-Custom Lebih Leluasa](#bisa-di-custom-lebih-leluasa)
- [Saya Bisa Memaksimalkan Penggunaan Tag HTML5](#saya-bisa-memaksimalkan-penggunaan-tag-html5)
- [Closing](#closing)

## Disclaimer

> Artikel ini mungkin terlihat “opinionated”. Di sini saya akan berbagi pengalaman saya pindah ke Tailwind CSS setelah lama menggunakan UI Component seperti Chakra UI dan Bootstrap.


## Introduction

Mungkin dari beberapa teman-teman pembaca ada yang menyadari ketika membuka personal website saya di [yehezgun.com](https://yehezgun.com). Awalnya saya sering menggunakan UI Component library seperti Chakra UI untuk personal project saya, termasuk personal website saya tersebut. Saya pun menyadari ketika sudah bekerja sebagai frontend engineer di tempat saya sekarang, rupanya saya terlalu bergantung pada tools dan mengabaikan fundamentalnya.

Saya pernah diberikan task untuk memperbaiki sebuah layout dengan native CSS, dan butuh sekitar 2 jam untuk bisa menyelesaikannya, padahal itu hanya halaman static biasa. Karena itulah saya memutuskan untuk kembali ke hal-hal fundamental sebelum melangkah lebih jauh.

Saya menemukan bahwa [Tailwind CSS](https://tailwindcss.com/) ini menarik, jadinya saya putuskan untuk revamp kembali personal web saya dengan starter template saya sendiri (bisa diakses di [sini](https://nexttw-starter.yehezgun.com/)). Sebelumnya, saya mau berterima kasih kepada [Theodorus Clarence](https://theodorusclarence.com/), karena starter template miliknya ini sangat membantu dan menginspirasi saya untuk membuat starter template saya sendiri. Saya menggunakan ide dan beberapa konsep referensi component yang tentunya saya modifikasi kembali sesuai kebutuhan saya.

Saya tidak mengatakan UI Component library seperti Chakra UI itu buruk. Sebenarnya itu sangat membantu saya ketika harus mengerjakan project yang deadline nya mepet atau harus cepat di-deliver karena mudahnya proses layouting dengan fitur-fitur dari Chakra UI. Tetapi untuk tujuan belajar secara mendalam, saya lebih condong kepada Tailwind CSS. Kurang lebih inilah alasan saya akhirnya menggunakan Tailwind CSS.

## Saya Belajar Dasar CSS Ketika Menggunakan Tailwind CSS

Tailwind CSS itu bukan UI Component, melainkan sebuah `utility-first` framework untuk keperluan styling website. Kurang lebih ketika menggunakan Bootstrap, Chakra UI, atau UI Component lainnya, kita dengan mudah set class name `btn` misalnya ketika ingin membuat sebuah button atau set component `<Button></Button>` (biasanya di React).

Di Tailwind CSS, saya harus membuat style sendiri untuk sebuah component dari nol, seperti pada native CSS, tetapi saya bisa lakukan hanya dengan memodifikasi style nya melalui class name pada HTML-nya. Bagi saya, ini seperti menulis `inline CSS` tetapi dengan cara yang sedikit lebih elegan dan lebih mudah.

Contoh kode:

```html
<button class="bg-sky-600 py-1 px-2 rounded-md">
  Save changes
</button>
```

Jika saya ingin menambahkan hover effect, saya cukup tambahkan `hover:bg-sky-700` di class name. Cukup mempermudah bukan?

Nah sampai di sini ada yang menyadari sesuatu?

Sembari menggunakan Tailwind CSS, rupanya saya juga harus paham dasar-dasar CSS lagi nih setelah lama tidak didalami, hahaha. Ini menarik, ketika saya membuat custom styling dengan Tailwind, saya juga harus konsep dasar styling sekalipun saya tidak menggunakan syntax CSS secara langsung.

Contohnya, ketika saya ingin membuat layout sederhana seperti gambar di bawah. Ketika saya menggunakan UI Component seperti Chakra UI, saya bisa mudahnya menggunakan Flex component bawaan dari Chakra UI. Berbeda dengan Tailwind, saya harus styling flex, flex item, spacing nya secara “manual”. Tentu saja, button di gambar di bawah ini, saya juga styling sendiri dengan Tailwind mulai dari border, hover effect, dan bahkan inner padding-nya.

![example](https://res.cloudinary.com/yehez/image/upload/v1647335347/Articles/I%20Remake%20My%20Personal%20Site%20using%20Tailwind/Yehez_Example_dljekw.png)


Bagi saya, tentu ini adalah hal yang sangat berguna walaupun cukup melelahkan, hahaha. Ketika saya sedang dalam tahap mencari pekerjaan tahun lalu, saya sempat diwawancarai oleh beberapa user dari beberapa perusahaan dan feedback dari mereka hampir mirip, “Kamu bisa design web kamu sendiri pake tools ini dengan gampangnya. Tapi di perusahaan kita butuhnya yang bisa native CSS karena website kita gak pake framework CSS supaya bisa dicustom lebih leluasa”.

Saya sempat membaca [Theodorus Clarence’s docs site](https://docs.thcl.dev/styling/css-scss), dan dia sempat menuliskan bahwa sudah sepatutnya kita sebagai programmer harus pelajari fundamental terlebih dahulu sebelum melangkah lebih jauh. Dan saya berani bilang itu sangat valid. Dalam pengalaman saya, saya pernah ditolak oleh recruiter karena saya gagal dalam live code session yang mengharuskan saya untuk coding dengan native CSS.

Sebagai karyawan fulltime dan sudah lulus dari kampus hampir 2 tahun lalu, tentunya saya harus mencari teknik belajar yang efektif sehingga saya bisa adaptasi dengan situasi saat ini dan deliver outputnya dengan cepat. Saya sebenarnya bisa saja belajar lagi CSS dari nol, tapi bagi saya itu terlalu lama dan saya butuh pekerjaan saat masih dalam masa “job-seeking”.

Sampai akhirnya saya menemukan Tailwind CSS ini, seperti yang sempat saya katakan, saya bisa sambil belajar dasar CSS sembari menggunakannya.

## Bisa Di-Custom Lebih Leluasa

Karena Tailwind ini adalah `utility-first` framework, saya tentunya bisa custom setiap halaman atau komponen yang ada di dalam website yang saya develop. Saya bahkan bisa saja membuat *design system* saya sendiri dengan Tailwind ini kalau saya mau dan punya waktu, hahaha.

Sudah lihat Theodorus Clarence’s [Next.js + Tailwind CSS Starter Template](https://github.com/theodorusclarence/ts-nextjs-tailwind-starter)? Menurut saya, ini seperti *mini design system* yang dikemas dalam bentuk starter template. Inilah yang menginspirasi saya untuk membuat template serupa untuk personal project saya ke depan.

Singkatnya, dengan Tailwind CSS, saya bisa memiliki kontrol penuh ketika styling di halaman web yang sedang saya develop.

## Saya Bisa Memaksimalkan Penggunaan Tag HTML5

Ini mungkin yang paling “opinionated” ya. Ketika saya menggunakan Tailwind, saya merasa bahwa saya bisa memaksimalkan penggunaan dan pemahaman tag HTML5.

Seperti penjelasan poin pertama, ketika saya menggunakan tag dasar HTML5, secara tidak langsung saya dipacu lagi untuk memahami *best practice* struktur HTML5 yang bisa saya terapkan.

Seperti kata banyak orang, ternyata penggunaan tag HTML5 itu bisa berkorelasi dengan persentasi SEO loh. Contoh artikelnya bisa dibaca di [sini](https://www.greengeeks.com/blog/html-tags-for-seo/).

## Closing

> Kalau kamu merasa belajar dari nol itu memakan terlalu banyak waktu, mungkin mempelajari tool, library, atau framework yang membuat kamu harus mempelajari fundamental sembari menggunakannya bisa membantu proses belajarmu.
> 

Sebagai karyawan fulltime atau *jobseeker* yang telah lulus kuliah, pastinya harus bisa belajar dengan cepat mengejar segala ketertinggalan yang ada kan karena kita berpacu dengan waktu, terutama saat butuh pekerjaan dengan cepat. Belajar dari nol sepertinya terlalu melelahkan dan terlalu lama.

Inilah sebabnya kita perlu bijak ketika memilih tool, library, atau framework. Pilihlah yang sebisa mungkin mendorong diri sendiri untuk memahami fundamentalnya sembari menggunakannya. Dalam kasus saya, Tailwind CSS ini saya rasa membantu saya memahami dasar CSS sembari melalui syntax-syntax Tailwind tersebut.

Semoga artikel ini bisa menginspirasi ya, saya masih amatir dalam menulis artikel hahaha. Kalau mau diskusi lebih lanjut, sangat boleh kok. Tuliskan saja di kolom komentar di bawah ya.

References:

- [Theodorus Clarence’s Docs Site](https://docs.thcl.dev/styling/css-scss)
- Theodorus Clarence’s [Next.js + Tailwind CSS Starter Template](https://github.com/theodorusclarence/ts-nextjs-tailwind-starter)

Hijrah Ke Tailwind CSS

## Table of contents

- [Disclaimer](#disclaimer)
- [Introduction](#introduction)
- [Siapkan Akun Yang Diperlukan](#siapkan-akun-yang-diperlukan)
- [Setup Supabase](#setup-supabase)
- [Deploy ke Vercel](#deploy-ke-vercel)
- [Konfugurasi Umami](#konfugurasi-umami)
- [Memasangkan Umami ke Website Kalian](#memasangkan-umami-ke-website-kalian)
- [Closing](#closing)

## Disclaimer

> Di artikel ini, saya akan fokus untuk melakukan self-host and setup Umami, lalu memasangkannya di project yang menggunakan Next.js. Teman-teman pembaca bisa menyesuaikan kembali apabila ingin menerapkannya di project yang berbeda.


## Introduction

Seringkali, ketika kita develop suatu project website dan ingin memasangkan web analytic tool, yang terpikirkan rata-rata adalah [Google Analytics](https://analytics.withgoogle.com/). Tetapi seperti yang umumnya kita tahu, tool ini memiliki kelemahan yaitu ketika ada pengujung website kita yang memakai AdBlocker maka tool ini tidak bisa bekerja sehingga datanya tidak akurat. Belum lagi memang ada isu privasi yang sering didebatkan perihal tool ini.

Oke langsung ke intinya saja ya. Jadi apa alternatifnya? Nah di sini saya rekomendasikan [Umami](https://umami.is/docs/about). Kenapa? Dalam dokumentasi resminya, Umami merupakan tool yang open source dan diklaim privacy-focused dibandingkan Google Analytics.

![Umami Web](https://umami.is/about-screenshot.png)

Lalu bagaimana cara setup-nya? Nah di artikel ini saya akan bahas secara cepat cara setup Umami menggunakan Vercel dan Supabase.

## Siapkan Akun Yang Diperlukan

Pertama-tama, jelas kamu harus punya akun [Github](https://github.com/join)  karena ini akan digunakan sebagai repository utama kita saat self-host Umami.

Selain itu, kamu juga harus punya akun [Vercel](https://vercel.com/signup) & [Supabase](https://supabase.com/).

## Setup Supabase

Sekarang, login ke [Supabase](https://supabase.com/) dan kamu akan redirect ke main dashboard, lalu click “New Project”. Silahkan isi form yang ada dengan data dan preferensi kalian ya.

![Supabase New Project](https://diskusi-tech-production.s3.amazonaws.com/i/v3am9ugawppl8exyhjkf.png)

Juga, pilih region yang paling dekat dengan domisili kalian.

![Supabase New Project Form](https://diskusi-tech-production.s3.amazonaws.com/i/iowz8hgnvr7w83ohv2tw.png)

## Deploy ke Vercel

Kalian bisa dengan mudahnya deploy ke Vercel hanya dengan membuka [Umami’s Docs (Running on Vercel section)](https://umami.is/docs/running-on-vercel) dan klik “Deploy”. Lalu, kamu bisa pilih Github sebagai repository dan isi nama repository-nya sesuai preferensi kalian.

Ketika sudah sampai di tahap seperti gambar di bawah, kembali ke Supabase sebentar.

![Deploy to Vercel](https://diskusi-tech-production.s3.amazonaws.com/i/6bazqd30kmb8hl9t9p9o.png)

Di Supabase, silahkan ke menu Settings dan klik “Database” section. Lalu scroll ke “Connection String”. Pilih “URI” lalu copy & paste itu ke DATABASE_URL di Vercel settings kalian. Jangan lupa juga ubah “YOUR_PASSWORD” menjadi password database Supabase kalian.

![Connection String](https://diskusi-tech-production.s3.amazonaws.com/i/lfs18mrew8hp479itzvb.png)

![Configure in Vercel](https://diskusi-tech-production.s3.amazonaws.com/i/2y3jn5947jo30f38l02u.png)

Untuk field HASH_SALT, bisa pakai [Password Generator](https://passwords-generator.org/) untuk generate random string, lalu copy dari situ. Setelah itu kalian bisa klik tombol Deploy.

Jika kalian ingin ganti domainnya, kalian bisa ke project settings dan ke menu Domain, lalu klik tombol Edit.

![Change Domain](https://diskusi-tech-production.s3.amazonaws.com/i/kkz3sukoae10hbpmwbk0.png)

## Konfugurasi Umami

Nah sekarang kamu bisa buka halaman web Umami yang telah kamu deploy tadi. Default username nya adalah `admin`, dan passwordnya adalah `umami`. Kamu bisa ganti passwordnya di kemudian waktu. Bisa ke menu Settings lalu ke Profile section dan klik Change Password.

![Umami Change Password](https://diskusi-tech-production.s3.amazonaws.com/i/pzuk35ekr0oeqoarieos.png)

## Memasangkan Umami ke Website Kalian

Di menu Settings, kalian bisa ke Website section, lalu klik Add Website. Nah di sini silahkan isi nama dan url web kalian dan jangan lupa enable “Share URL”.

Setelah menambahkan website di Umami, copy “Tracking Code”-nya.

![Umami Tracking Code](https://diskusi-tech-production.s3.amazonaws.com/i/nbl2qwptw8jg84hdso1p.png)

Sebagai tahap terakhir, kalian bisa ke project folder kalian (project yang ingin kalian pasangkan Umami). Dalam hal ini project saya menggunakan Next.js dan saya paste code yang telah di-copy tadi di file `_document.tsx`.

![NextJS Integration](https://diskusi-tech-production.s3.amazonaws.com/i/klu6kov92fl6h5zgg6sw.png)

Nah selesai deh, kalian tinggal deploy push commit terbaru dari project kalian ke repository masing-masing. Statistik di halaman dashboard Umami akan muncul dalam waktu kurang lebih 24 jam.

## Closing

Kalian juga bisa terapkan cara ini ke project kalian yang lain tak hanya Next.js. Semoga bisa membantu. Kalau ada pertanyaan atau hal-hal yang ingin didiskusikan, bisa langsung tulis di kolom komentar ya.

Referensi: [How to Setup Umami with Vercel and Supabase (by Jacob Bouchard)](https://dev.to/jakobbouchard/setting-up-umami-with-vercel-and-supabase-3a73)

Cara Setup Umami Dengan Vercel dan Supabase

## Table of contents

- [Disclaimer](#disclaimer)
- [Pendahuluan](#pendahuluan)
  - [Kembali ke Fundamental](#kembali-ke-fundamental)
  - [Learn The Framework Philosophy](#learn-the-framework-philosophy)
  - [Buat Project](#buat-project)
  - [Code Reviews](#code-reviews)
- [Penutup](#penutup)

## Disclaimer

> Seperti artikel saya sebelumnya, artikel ini dibuat berdasarkan pengalaman saya pribadi sebagai frontend engineer. Mungkin teman-teman pembaca memiliki konteks atau testimoni berbeda, tetapi setidaknya semoga ini bisa menjadi referensi baru bagi teman-teman pembaca sekalian.
> 

## Pendahuluan

Cerita dimulai ketika saya bekerja sebagai frontend engineer di tempat kerja saya yang pertama. Saat itu saya masih harus menggunakan Angular. Awalnya, sebagai fresh graduate saat itu biasa saja, tetapi semua berubah ketika menjelang pertengahan tahun 2021 lalu saya melihat kebanyakan lowongan pekerjaan menuntut kandidat untuk menguasai React sebagai *tech stack* utama. Saya yang awalnya saat itu ingin *resign* dan pindah kantor harus urung niat terlebih dahulu dan manuver ke React.

Tidak hanya itu yang menjadi alasan utama saya untuk pindah ke React. Ketika melakukan *troubleshooting* atau *debugging*, tentunya seringkali saya harus berlama-lama *googling* untuk menemukan jawaban yang saya butuhkan ketika saya menggunakan Angular. Berbeda ketika saya menggunakan React, entah kenapa setiap kali mengalami *issue*, dengan mudah dan cepatnya saya bisa menemukan jawaban lewat Stackoverflow atau forum Github.

Sebenarnya, kebanyakan frontend framework masih menggunakan Javascript (atau Typescript) di dalam *codebase* mereka. Perbedaan utama dari setiap framework sebenarnya adalah *approach* yang diimplementasikan di framework tersebut. 

Kurang lebih, inilah yang saya lakukan untuk tetap bisa beradaptasi dengan perkembangan dan perubahan framework yang ada. Tentunya saya pribadi masih melakukan ini karena banyak hal yang perlu saya dalami lebih lanjut, bahkan ada yang masih saya belum mengerti walaupun cukup sering menggunakannya, hahaha. Semoga ini bisa membantu.

### Kembali ke Fundamental

React, Angular, Vue, dan Svelte sebenarnya masih menggunakan Javascript sebagai bahasa pemrograman yang membentuk framework itu semua. Seperti yang pernah saya sebutkan di bagian sebelumnya, sebenarnya perbedaan mencoloknya hanya masalah pendekatan yang dilakukan. **Tentunya, akan lebih baik jika sudah memiliki fundamental yang baik sebelum mempelajari suatu framework.**

Framework berubah sangat cepat, bahkan dalam hitungan bulan bisa ada framework atau update baru, tak jarang saya juga harus belajar ulang kalau ada perubahan yang sifatnya mayor. Nah bahayanya apabila melewatkan hal fundamental, akan kesulitan sendiri ketika belajar suatu framework. Berbeda apabila sudah menguasai dasar-dasar Javascript lalu belajar React misalnya, tentunya akan lebih mudah dan cepat paham karena React kebanyakan menggunakan syntax dasar Javascript.

Kalau pengalaman saya pribadi ketika pindah ke React, saya belajar ulang Javascript karena React sendiri masih menggunakan syntax dan logic Javascript. Berbeda sekali ketika saya menggunakan Angular, hampir semua page, component, atau service bisa dengan mudah di-generate dengan CLI. Nah di React, rupanya tidak ada aturan baku yang membuat saya harus membuat config dan arsitektur project secara *custom.*

Beruntung ada situs [freecodecamp.org](http://freecodecamp.org) dan [hackerrank.com](http://hackerrank.com) yang menurut saya cukup membantu. Saya bisa kembali mempelajari kembali dasar-dasar syntax Javascript dan mengasah kemampuan problem-solving saya.

### Learn The Framework Philosophy

Ini menurut saya yang sangat penting setelah belajar dasar-dasarnya. Sebelum terjun ke sebuah framework, pelajari dahulu *approach* dan filosofi di balik framework tersebut. Kalau perlu, follow akun twitter dari pembuat framework tersebut. Kenapa? **Kamu harus tahu bagaimana framework itu bekerja, kenapa penciptanya mau membuat framework itu, dan apa masalah yang ingin diselesaikan lewat framework yang ia buat.**

Sebenarnya, saya pribadi sempat melewatkan ini bahkan selama 3 bulan lebih ketika terjun ke React, hahaha. Alhasil ketika menghadapi issue tertentu, saya harus berlama-lama *googling* untuk menemukan jawabannya. Seringkali saya juga tidak sadar membuat kode yang “kotor” karena saya saat itu tidak tahu apa *best practice* dan yang semestinya dilakukan.

Beruntung saya follow akun twitter dari [Theodorus Clarence](https://twitter.com/th_clarence) yang meskipun masih mahasiswa, tetapi sangat luar biasa dia bisa membuat arikel dan tweet yang memuat dasar-dasar React (dan Next.js). Bahkan tak jarang saya juga baru memahami dasar-dasar React ketika membaca artikel miliknya, hahaha. Kenapa gak dari dulu ya, haduh....

Saran saya, gunakan media sosial seperti Twitter untuk follow akun-akun seperti dia. Tentunya kamu juga akan bisa mendapatkan insight baru lewat artikel atau bahkan tweet singkat mereka. 

Seorang teman saya juga memberikan sebuah Github repository yang memuat penjelasan lengkap terkait filosofi React. Bisa diakses di [React Philosophies](https://github.com/mithi/react-philosophies). Saya pun belum memahami semuanya, masih banyak yang belum saya mengerti, tetapi setidaknya ini cukup membantu saya mengimplementasikan *best practice* yang bisa saya terapkan sendiri.

### Buat Project

**Perlu diingat, programming itu adalah problem-solving.** Kamu tidak bisa belajar programming hanya dengan menonton tutorial di Youtube. Kamu harus coba sendiri.

Seperti yang pernah saya katakan di artikel sebelumnya, tidak perlu harus sampai membuat project yang complex. Cukup buat yang simpel dan bahkan bisa kamu gunakan sendiri.

Sebagai contoh, saya pernah membuat [simple food app using React + Line Frontend Framework (LIFF) app](https://liff-de-mangan.vercel.app/). Sebenarnya web itu hanya mengirimkan makanan yang telah dipilih lewat LINE Chat saja, hahaha. Tetapi justru karena project ini saya jadi sedikit tahu bagaimana cara LIFF bekerja dan penggunaannya secara umum.

Ada sebuah istilah yang bernama “Tutorial Hell”. Nah ini seringkali terjadi ketika seseorang mempelajari sesuatu lalu merasa paham dengan apa yang dipelajarinya. Namun ketika ingin mengimplementasikannya, malah kebingungan sendiri. Saya pernah mengalami ini, tetapi saya bisa mengatasinya dengan cara langsung membuat mini personal project menggunakan framework yang saya ingin kuasai.

Dibandingkan belajar [sesuatu], lebih baik buatlah sesuatu dengan hal yang ingin kamu kuasai. Sebagai contoh, dibandingkan belajar React saja, lebih baik coba buat project menggunakan React. Seringkali dengan praktek langsung, pemahaman yang terbentuk bisa lebih dalam dibandingkan hanya sekedar melihat saja.

### Code Reviews

Nah selesai buat project nih, jangan berhenti di sana saja. Review kembali sendiri atau minta temanmu untuk review kode yang telah kamu buat. **Perlu diingat bahwa setiap programmer memiliki blindspot masing-masing, sehingga pasti ada saja hal-hal yang terlewatkan ketika membangun suatu project.**

Saya ingat sekali ketika saya mengerjakan project freelance pertama menggunakan React, saya selalu meminta rekan setim saya untuk review kodingan milik saya sebelum merge ke Gitlab Repository. Waktu itu, kode saya sebenarnya biasa saja dan berfungsi dengan baik. Tetapi, seringkali teman saja bisa-bisanya menemukan bagian-bagian yang harusnya bisa di-improve atau dibuat lebih *readable.*

Mungkin sebagian ada yang bertanya-tanya, gimana caranya sih untuk bikin kodingan yang berkualitas (clean code)? Menurut saya, dengan rutin melakukan code review itu akan sangat membantu. **Pengalaman tidak pernah bohong, seringkali seseorang baru mengetahui hal yang semestinya dilakukan ketika melihat atau mengalami yang salah terlebih dahulu.**

## Penutup

Ya inilah pengalaman saya ketika saya hijrah ke React. Mungkin ada teman-teman pembaca yang mempunyai konteks atau testimoni berbeda, tetapi setidaknya ini bisa menginspirasi bahkan membantu teman-teman ketika mau hijrah ke bahasa pemrograman atau framework lain. Apabila ada yang ingin didiskusikan lebih lanjut, boleh tuliskan di kolom komentar ya.

Pengalaman Saya Waktu Pindah Framework Dari Angular ke React

## Table of contents

- [Disclaimer](#disclaimer)
- [Introduction](#introduction)
- [Mengapa Kita Butuh Standarisasi untuk Source Code kita?](#mengapa-kita-butuh-standarisasi-untuk-source-code-kita?)
  - [Setiap Anggota Tim Punya “Code Style” Mereka Masing-Masing](#setiap-anggota-tim-punya-"code-style"-mereka-masing-masing)
  - [Meningkatkan Maintainability dan Readability](#meningkatkan-maintainability-dan-readability)
  - [Tidak Hanya Kodingan, Commit Message juga Perlu Standarisasi](#tidak-hanya-kodingan-commit-message-juga-perlu-standarisasi)
- [Bagaimana Cara Standarisasi Source Code Project Kita?](#bagaimana-cara-standarisasi-source-code-project-kita?)
  - [Konfigurasi Prettier](#konfigurasi-prettier)
  - [Konfigurasi Base ESLint Rules](#konfigurasi-base-eslint-rules)
  - [Konfigurasi Husky](#konfigurasi-husky)
- [Closing](#closing)

## Disclaimer

> Di artikel ini, says akan fokus untuk melakukan standarisasi pada project Next.js (Typescript). Teman-teman pembaca bisa menyesuaikan dengan source code project masing-masing atau berdasarkan kebutuhan ya.


## Introduction

Berdasarkan pengalaman saya di dunia programming, Javascript (dan Typescript) adalah bahasa pemrograman yang paling “liar” yang pernah saya pelajari. Saya dengan mudahnya bisa menggunakan *code convention* versi mana saja sesuka hati saya setiap kali membuat project menggunakan Javascript ini.

Ketika saya membuat personal project, sepertinya tidak menjadi masalah besar karena saya koding hanya untuk diri sendiri dan hanya saya saja yang mengerti kodingan sendiri, hahaha. Tetapi bayangkan kalau harus bekerja dalam tim yang terdiri dari bebrapa orang dan tiap orang juga berpikiran sama bahwa mereka punya *code style* masing-masing dan koding seenaknya? BOOOM, hancur sudah isi kodingannya.

Nah ini adalah salah satu contoh alasan kenapa kita butuh standarisasi untuk *source code* kita sebagai programmer. Ini sebenarnya adalah masalah umum yang dialami banyak programmer di luar sana, apalagi dalam tim. Tapi setidaknya ini juga bisa jadi pengingat bagi kita semua ya untuk tetap membuat kodingan yang rapi dan enak dibaca baik untuk diri sendiri atau orang lain

## Mengapa Kita Butuh Standarisasi untuk Source Code kita?

Nah sebelum lebih jauh, seperti biasa kita harus mulai dengan “why”. Kenapa sih sampai harus pakai standarisasi segala?

### Setiap Anggota Tim Punya “Code Style” Mereka Masing-Masing

Nah seperti yang saya sebutkan di bagian pendahuluan, ketika saya membuat personal project, mungkin tidak terlalu menjadi masalah besar apabila tidak ada standarisasi yang jelas karena hanya saya sendiri yang membuatnya. 

Berbeda jika saat bekerja dalam tim, apalagi sekarang ketika saya bekerja sebagai full-time frontend engineer. Setiap orang punya gaya kodingannya sendiri. Tentu ini bisa membuat bingung sendiri ketika mendapat suatu *task* lalu harus membaca kodingan milik anggota tim lain dan memahaminya terlebih dahulu.

Tidak hanya saya ternyata, ketika orang lain membaca kodingan saya pun sering mereka merasa bingung karena gaya kodingannya berbeda. **Inilah mengapa perlu dibuat semacam *code convention*, supaya kode yang dibuat tetap konsisten walaupun dalam sebuah tim yang orangnya ada banyak.**

### Meningkatkan Maintainability dan Readability

Saya pernah bekerja di sebuah software house yang sistem kerjanya berbasiskan project. Tugas engineer bisa dibilang selesai ketika project telah di-deliver kepada client.

Saya saat itu masih sebagai junior frontend engineer dan tentunya sebagai fresh graduate juga saya seringkali membuat kodingan “bar bar”, hahaha. Dalam pikiran saya saat itu, saya hanya perlu menyelesaikan *request* dari *user* dan *deliver* ketika semuanya selesai. Sungguh pengalaman tidak terlupakan.

Semua berubah ketika saya pindah ke sebuah perusahaan yang tergolong sebagai *in house company*. Yang mana mereka memiliki produk tersendiri yang dikembangkan dalam perusahaan tersebut.

Yang tadinya hanya fokus untuk koding lalu “lempar”, sekarang tidak bisa seperti itu, hahaha. Saya juga harus memikirkan kodingan saya tetap bisa ter-*maintain* dengan baik dan juga harus *readable* sehingga memudahkan apabila perlu *improvement* di masa mendatang.

Caranya sebenarnya cukup simpel, hanya buat dan ikuti *code convention* yang telah disepakati sehingga kodingannya bisa tetap konsisten walaupun dibuat oleh beberapa orang dalam tim. **Kode yang konsisten membuatnya mudah dibaca, nah kalau mudah dibaca dan dimengerti, tentunya akan mudah untuk *maintenance*.**

### Tidak Hanya Kodingan, Commit Message juga Perlu Standarisasi

Jika bekerja dalam tim, sangat penting untuk membuat commit message yang mudah dipahami oleh anggota tim lain sebelum push ke Git repository. **Kodingan yang rapi tentunya akan terlihat sia-sia kalau commit message-nya berantakan. ****Ketika terjadi *issue* dan harus dilakukan *tracking*, akan kebingungan sendiri karena commit-messange nya berantakan.

Syukurlah sekarang ada [Conventional Commit](https://www.conventionalcommits.org/en/v1.0.0/) yang bisa membantu developer untuk membuat commit message yang mudah dibaca.

## Bagaimana Cara Standarisasi Source Code Project Kita?

Di sini saya akan bahas dari perspektif frontend engineer ya. Dalam hal ini adalah Next.js. Di dunia pemrograman Javascript, ada beberapa tools yang bisa dimanfaatkan untuk membantu kita melakukan standarisasi kodingan.

- [Prettier](https://prettier.io/) (Code Formatter)
- [ESLint](https://eslint.org/) (Linter for JS-based project)
- [Next Lint](https://nextjs.org/docs/basic-features/eslint) (built-in linter for Next.js)
- [Husky](https://github.com/typicode/husky) (automated linter trigger)
- [Lint Staged](https://github.com/okonet/lint-staged) (run linter before commit)
- [Commit Lint](https://commitlint.js.org/#/) (check the commit message before committing)

> Hanya untuk memberikan contoh, saya telah menyiapkan sample project Next.js sederhana (Typescript) yang bisa diakses di  [next-tailwind-polos](https://github.com/yehezkielgunawan/next-tailwind-polos). Kalian bisa melakukan konfigurasi dan standarisasi kodingan menggunakan contoh project ini. Silahkan di-clone dan jangan lupa untuk install dependencies dengan `yarn` atau `npm install`.


Ini yang akan kita lakukan berikutnya.

- Configure [Prettier](https://prettier.io/docs/en/install.html)
- Configure base [ESLint](https://bobobox.atlassian.net/wiki/spaces/BD/pages/2520154113/Frontend+Recommended+Code+Style+Guide+React+Based#In-Next.js-Project-[TYPESCRIPT-Based]) rules
- Install & configure the base [husky](https://typicode.github.io/husky/#/) setting (*Reference: Husky setting [Yehez-Tailwind-Starter](https://github.com/yehezkielgunawan/yehezgun-new/tree/main/.husky)*)
- Install & configure [lint-staged](https://github.com/okonet/lint-staged) and [commitlint](https://commitlint.js.org/#/guides-local-setup)

> Di langkah berikutnya saya akan menggunakan `yarn`, teman-teman pembaca bisa menyesuaikan apabila menggunakan `npm`. Untuk lebih lengkapnya, silahkan lihat dokumentasi resmi untuk penggunaan tools terkait ya
> 

### Konfigurasi Prettier

Nah saya asumsikan kalian sudah clone contoh project yang saya berikan di bagian sebelumnya ya, sehingga di sini sudah mulai fokus untuk penggunaan tools terkait.

Pastikan kalian sudah membuka folder projectnya baik dari VS Code atau terminal kalian, lalu jalankan `yarn add --dev --exact prettier`. Lalu, buat file dengan nama `.prettierrc.json` di root folder, atau bisa juga tinggal jalankan `echo {}> .prettier.json` di terminal kalian.

Nah di dalam `.prettierrc.json`, kalian bisa isi dengan konfigurasi seperti di bawah ini, atau kalian bisa modifikasi sesuai keinginan dan preferensi kalian. (referensi: [Prettier Config Options](https://prettier.io/docs/en/options.html)).

```json
{
  "endOfLine": "lf",
  "semi": true,
  "singleQuote": false,
  "tabWidth": 2,
  "trailingComma": "es5"
}
```

Nah, sekarang kalian hanya perlu jalankan `yarn prettier --write [directory scope]` untuk melakukan format pada kodingan kalian. Atau jika kalian menggunakan VS Code, kelian bisa set **Format on Save** di VS Code Settings kalian, tapi pastikan kalian sudah menginstall ekstensi Prettier ini di text editor kalian. Selain itu, bisa juga menggunakan *shortcut* `Shift + Option + F` (di macbook) atau `Shift + CTRL + F` (di windows) untuk memformat file kodingan secara manual.

### Konfigurasi Base ESLint Rules

Karena kita menggunakan Next.js, kita akan memakai [ESLint for Next.js](https://nextjs.org/docs/basic-features/eslint). Beruntung di Next.js terbaru, ESLint secara default telah terinstall secara default di dalam project ini sejak project diinisiasi. Jadi dalam case ini, kita bisa fokus ke file `eslintrc.json` yang ada di root folder.

Tapi pastikan juga bahwa `lint` command sudah ada di dalam file `package.json`.

```json
"scripts": {
    "dev": "next dev",
    "build": "next build",
    "start": "next start",
    "lint": "next lint"
  }
...
```

Kurang lebih, ini isi konfigurasi ESLint milik saya di file `eslintrc.json`. Kamu tidak perlu tiru 100% ya. Kembali lagi ke kebutuhan masing-masing.

```json
{
  "env": {
    "node": true
  },
  "extends": [
    "next/core-web-vitals",
    "eslint:recommended",
    "plugin:@typescript-eslint/recommended"
  ],
  "parser": "@typescript-eslint/parser",
  "plugins": ["import", "unused-imports", "@typescript-eslint"],
  "settings": {
    "import/resolver": {
      "node": {
        "extensions": [".js", ".jsx", ".ts", ".tsx"],
        "moduleDirectory": ["node_modules", "src/"]
      }
    }
  },
  "rules": {
    "no-unused-vars": "off",
    "@typescript-eslint/no-unused-vars": "off",
    "@typescript-eslint/explicit-module-boundary-types": "off",
    "@typescript-eslint/no-non-null-assertion": "off",
    "@typescript-eslint/no-inferrable-types": "off",
    "@next/next/no-img-element": "off",
    "unused-imports/no-unused-imports": "error",
    "unused-imports/no-unused-vars": [
      "warn",
      {
        "vars": "all",
        "varsIgnorePattern": "^_",
        "args": "after-used",
        "argsIgnorePattern": "^_"
      }
    ],

    "no-eq-null": "warn",
    "import/order": [
      "warn",
      {
        "groups": [
          ["builtin", "external"],
          "internal",
          "parent",
          ["sibling", "index"],
          "object"
        ],
        "newlines-between": "always",
        "alphabetize": {
          "order": "asc",
          "caseInsensitive": true
        }
      }
    ],
    "complexity": "warn",
    "no-console": ["error"]
  }
}
```

Di sini, saya menggunakan third-party ESLint plugin seperti [import](https://www.npmjs.com/package/eslint-plugin-import), [unused-import](https://www.npmjs.com/package/eslint-plugin-unused-imports), dan [typescript-eslint](https://www.npmjs.com/package/@typescript-eslint/eslint-plugin).

Setelah proses konfigurasi di sini selesai, kamu bisa jalankan `yarn lint` untuk mengecek apakah kodingan-mu sudah sesuai dengan rules yang ada atau belum. Kamu juga bisa jalankan `yarn lint --fix` yang otomatis melakukan *fixing* di kodinganmu berdasarkan rules yang telah ditentukan. Perlu diingat, bahwa terkadang kita harus melakukan *fixing* manual terhadap kodingan kita, jangan terlalu mengandalkan *fixing* otomatis dari fitur ini ya.

### Konfigurasi Husky

Ingin menambahkan otomatisasi? Dalam hal ini saya biasa menggunakan [Husky](https://typicode.github.io/husky/#/) untuk secara otomatis mengecek kodingan atau commit message sebelum commit atau push ke Git Repository.

Karena kita menggunakan yarn, kita akan install dengan menjalankan `npx husky-init && yarn` di terminal. Itu akan secara otomatis men-generate `prepare` command di dalam `package.json` dan base pre-commit config.

![husky install](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/mow4oovc9qxz5omym7vt.gif)

Setelah itu, kita akan menginstall https://github.com/okonet/lint-staged untuk men-trigger dan menjalankan linter di tahap *git staged files* dengan mengeksekusi `npx mrm@2 lint-staged`. Itu akan otomatis men-generate *base command* untuk men-trigger `pre-commit` *husky config file*. Lalu, kamu bisa hapus atau sesuaikan kembali isi kontennya sesuai preferensimu. Setelahnya, ketika melakukan commit ke Git repository, otomatis akan menjalankan pengecekan linter. Jadi, pastikan kodinganmu sudah sesuai dengan rules dalam linternya ya.

![Lint staged install](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/tjua26xupptx6ldnzm8u.gif)

Seperti yang telah saya sebutkan sebelumnya, tidak hanya kodingan, kita pun perlu standarisasi commit message sebelum melakukan push ke Git Repository. Di sini kita akan memakai [Commit Lint](https://commitlint.js.org/#/guides-local-setup) dengan menjalankan `yarn add --dev @commitlint/config-conventional @commitlint/cli` di terminal.

Perlu diingat juga kita perlu membuat file konfigurasi commitlint ini dengan menjalankan perintah seperti di bawah ini di terminal.

```bash
echo "module.exports = { extends: ['@commitlint/config-conventional'] };" > commitlint.config.js
```

Nah setelah itu, kita bisa integrasikan dengan *husky* dengan menjalankan `yarn husky add .husky/commit-msg 'yarn commitlint --edit $1'`. Itu akan secara otomatis men-generate file konfigurasi *husky* yang bernama `commit-msg`.

![commit-msg](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/582zmbmylmh0vtdomfrc.png)

Nah sekarang kamu tidak bisa lagi membuat commit message yang “bar bar” hahaha. Saran saya, gunakan [ekstensi VS Code Conventional Commit.](https://marketplace.visualstudio.com/items?itemName=vivaxy.vscode-conventional-commits)

![commitlint](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/iydc23euxo6bbjaoxf3k.png)

Ingin menambahkan pengecekan otomatis lagi sebelum push ke Git Repository? Bisa, di sini contohnya saya bisa jalankan `npx husky add .husky/pre-push 'yarn lint'` untuk men-generate file husky config baru yang men-trigger pengecekan linter sebelum push ke Git Repository.

![pre-push](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/2vwks591pfcxon0h0oui.gif)

Nah selesai deh. Perlu diingat lagi, kamu tidak perlu meniru 100% metode yang telah saya beritahukan di sini. Kamu bisa juga menyesuaikan kembali konfigurasinya sesuai dengan kebutuhanmu

## Closing

Sebenarnya cara ini bukan cara satu-satunya ya. Masih banyak metode atau tools lain yang tidak kalah efektif sebenarnya yang juga bisa membantu kita melakukan standarisasi source code kita. Semoga ini bisa membantu teman-teman ya. Silahkan diskusikan ini di kolom komentar ya.

Standarisasi Project Next.js Kamu

## Daftar Isi
- [Disclaimer](#disclaimer)
- [Introduction](#introduction)
- [Mulai dari Masalah yang Kamu Hadapi Saat ini](#mulai-dari-masalah-yang-kamu-hadapi-saat-ini)
- [Terkadang Kamu Tidak Perlu Membuat Sesuatu dari 0](#terkadang-kamu-tidak-perlu-membuat-sesuatu-dari-0)
- [Kamu Bahkan Bisa *Remake* Project yang Sudah Ada](#kamu-bahkan-bisa-remake-project-yang-sudah-ada)
- [Closing](#closing)

## Disclaimer
> Artikel ini mungkin terliat “opinionated” karena ini berdasarkan apa yang saya alami sebelumnya. Setidaknya artikel ini mungkin bisa menjadi referensi bagi teman-teman yang sedang mengembangkan portfolio sebagai *programmer.*

## Introduction
Selang beberapa hari ketika saya mempublikasikan artikel saya yang berjudul **[How To Get Hired Without Applying](https://yehezgun.com/articles/how-to-get-hired-without-applying),** beberapa teman bertanya `Gimana sih caranya bisa dapet ide buat bikin portfolio project kayak gitu?`. Sebenarnya ini juga pertanyaan yang sama ketika saya bertanya kepada seorang teman yang cukup rutin mengembangkan project portfolio pribadinya.

Saya tahu persis ketika kami baru saja lulus di tahun 2020 lalu, sebelum mendapatkan *fulltime job*, dia secara rutin mempublikasikan _project_-nya di Linkedin, Twitter, dan situs pribadinya. Kalian bisa akses contoh-contoh *project* apa saja yang pernah dia buat di <a target="_blank" href="https://sznm.dev/projects">https://sznm.dev/projects</a> Saat itu saya juga sempat menanyakan pertanyaan seperti yang tertulis di paragraf sebelumnya.

Secara umum, inilah poin-poin penting yang saya dapat ketika sedang berbincang dengannya. Jawaban darinya cukup “menendang” pikiran saya bahwa sebenarnya tidak cukup sulit untuk mendapatkan ide.

## Mulai dari Masalah yang Kamu Hadapi Saat ini
Perlu diingat, **the “How” will not exist without “Why”.** Ketika kita ingin membuat sebuah solusi, tentunya harus ada masalah yang akan diselesaikan bukan? Ini adalah hal yang paling mendasar yang pernah saya coba juga ketika saya resign dari kantor lama saya dan mencari pekerjaan baru.

Ketika saya berganti *framework* dari Angular ke React, untuk membantu meningkatkan pemahaman saya, saya tentu harus membuat *project* menggunakan React. Saat itu, saya merasa capek sendiri ketika harus menginisiasi sebuah *project* dari 0, terutama ketika harus berhadapan dengan hal-hal berbau *config* seperti husky, ESLint, dan Prettier config.

Seperti yang pernah saya tuliskan pada artikel saya yang berjudul **[Why Making A Starter Template Matters?](https://yehezgun.com/articles/why-making-a-starter-template-matters),** akhirnya saya membuat sendiri sebuah starter template menggunakan Next.js, Chakra UI, dan Typescript. Awal-awal memang saya sendiri sempat kewalahan harus config ini dan itu saat membuat starter template itu. Tetapi sekarang, ketika saya ingin membuat *project* baru, saya cukup *generate* dari starter template yang sebelumnya saya buat tanpa perlu pusing lagi berhadapan dengan config.

Contoh lain, ketika saya mempublikasi *microblog* di Linkedin, saya saat itu merasa butuh *link shortener.* Saya rasa akan lebih baik kalau saya punya *link shortener*  sendiri sehingga saya bisa *custom* sesuai kebutuhan saya. Akhirnya saya membuat [Yehez-Shortin](https://shortin.yehezgun.com/) sebagai *link shortener* saya sendiri.

Bisa mengerti apa yang saya maksudkan di sini? **Kamu bisa menemukan masalah apa yang sedang anda hadapi atau ingin pecahkan di sekitar anda,** lalu buat perencanaan dan implementasikan solusi yang telah dibuat.

## Terkadang Kamu Tidak Perlu Membuat Sesuatu dari 0
Beruntung kita hidup di era teknologi, sekarang kita dengan bebasnya mencari *resource* yang kita butuhkan lewat internet. Saya ingat betul ketika saya menonton sebuah *talkshow online* dengan Pak Sandhika Galih (Web Programming Unpas) dan Mathdroid. Kalian bisa menontonnya di Youtube yang judul videonya **[Tips Belajar Programming, Indie Hacker & Reverse Engineering](https://www.youtube.com/watch?v=LKATs6MDeCw).**

> Di dunia modern sekarang, ketika kamu ingin membuat sebuah *project,* terutama *coding project,* kamu dengan mudah bisa *searching* sendiri di Google. Cari referensi terkait *problem* yang ingin dipecahkan dan pakai metode yang kamu dapatkan. Bahkan kamu bisa juga kok meniru dari apa yang orang lain telah buat, tapi sesuaikan dengan kebutuhanmu. **~Mathdroid**

*Statement* ini yang menginspirasi saya. Saya sendiri telah mencoba cara ini ketika saya mencari pekerjaan baru, dan ternyata berhasil.

Mungkin akan capek sendiri kalau *develop* semua dari 0. Di luar sana, ada banyak *tools* atau *library* yang tentunya bisa membantu kita saat *develop project*. __Mungkin untuk keperluan belajar, tidak masalah membuat sesuatu dari 0 untuk memahami cara kerja *logic* yang dibuat secara umum, tetapi untuk jangka panjang cepat atau lambat kamu akan butuh *tools* yang  meningkatkan produktifitas dan membantu menyelesaikan *project*-mu karena tuntutan *deadline* atau hal-hal lain.__

Tapi jangan salah tangkap juga ya. **Tools terbaru belum tentu terbaik. Sesuaikan kembali dengan kebutuhanmu!**

## Kamu Bahkan Bisa Remake Project yang Sudah Ada
Gak kepikiran untuk membuat hal baru? *Remake* saja dari yang sudah ada sebelumnya. Contohnya, saat saya membuat starter template https://github.com/yehezkielgunawan/yehez-nextchakra-starter, saya sebenarnya hanya meniru konsep dari milik teman saya sendiri, bisa liat di https://github.com/sozonome/nextarter-chakra.

Dalam hal ini, tidak meniru 100% hanya clone semata ya. Saya hanya ambil referensi *layout* dan *tools* apa saya yang sekiranya juga bisa saya pakai, lalu saya sesuaikan kembali dengan preferensi saya. Jangan salah, justru dengan meniru ini kamu juga bisa memahami bagaimana membuat *project* tersebut secara bertahap. **Ketika kamu sudah tahu apa yang harus dibuat, sangat mudah menentukan langkah berikutnya**

**Amati, tiru, dan modifikasi (ATM).** Ini adalah prinsip yang mungkin kamu sering dengar di mana-mana. Jangan salah, prinsip inilah yang membuat sebuah negara di Asia bisa menjadi salah satu negara adidaya loh. Kamu pasti mengerti apa yang saya maksud.

Contoh lain, ketika saya membuat [Yehez-Shortin](https://shortin.yehezgun.com/) *(link shortener).* Sebenarnya ini adalah ide yang sangat umum. Hampir semua web developer pemula membuat ini ketika mereka baru saja belajar bahasa pemrograman atau *framework* baru. Tetapi tentu saja, saya tidak asal meniru, saya tentu memodifikasinya dengan preferensi saya, seperti dark-mode dan bisa custom URL alias. 

## Closing
> Di era modern ini, ide itu bisa ditemukan di mana saja. Kamu hanya butuh koneksi internet, lalu *googling* saja dengan mudahnya. Bahkan sebenarnya ide bisa muncul dari hal-hal di sekitarmu.

Mungkin kamu sempat berpikir keras mencari ide untuk portfolio project-mu. Tetapi perlu diingat, *coding* itu adalah *problem-solving*. Jadi mulai cari masalah yang bisa kamu pecahkan dan implementasikan metode yang kamu ingin gunakan.

Terima kasih sudah menyempatkan membaca artikel amatir dari saya ya, hahaha. Semoga bisa membantu teman-teman dalam mengembangkan *project portfolio* kalian ya.

Reference: 
- Bangkit Academy Class 6: Idea Generation & MVP Planning
- [Agustinus Nathaniel’s Portfolio](https://sznm.dev/)

Cara Dapatkan Ide untuk Membuat Portfolio Sebagai Programmer

## Table of contents

- [Introduction](#introduction)
- [Apa yang saya pelajari sepanjang tahun 2021?](#apa-yang-saya-pelajari-sepanjang-tahun-2021)
  - [Berjuang Mengatasi Burnout Akibat Workload Pekerjaan](#berjuang-mengatasi-burnout-akibat-workload-pekerjaan)
  - ["Learning Path" Baru Favorit Saya](#"learning-path"-baru-favorit-saya)
  - [Akhirnya Dapat Pekerjaan Baru](#akhirnya-dapat-pekerjaan-baru)
- [Project Selama 2021](#project-selama-2021)
  - [yehezgun.com](#yehezgun.com)
  - [Personalized Starter Template](#personalized-starter-template)
  - [Personal Link Shortener](#personal-link-shortener)
  - [Personal Live Markdown Editor](#personal-live-markdown-editor)
  - [Personal Docs Site](#personal-docs-site)
  - [KAI Access App & A Freelance Project](#kai-access-app-&-freelance-project)
- [Harapan untuk 2022](#harapan-untuk-2022)

## Introduction
Tanpa terasa kita sudah ada di penghujung tahun 2021. Ini perasaan saya saja kah, entah mengapa sejak pandemi ini terjadi waktu berjalan lebih cepat. Saya ingat betul momen di mana terakhir kita bisa bertemu tatap muka itu sekitar Maret 2020, dan ternyata sudah hampir 2 tahun semua berjalan secara online ya, hahaha.

Saya harap teman-teman pembaca dalam keadaan baik yah. Seperti yang dilakukan banyak orang, saya di sini akan menuliskan rangkuman apa saja yang terjadi dan telah dilakukan sepanjang 2021 ini sebagai frontend engineer. Mungkin terlalu "opinionated" ya, tetapi setidaknya ini bisa memotivasi teman-teman pembaca. Dan tentu, dengan menulis ini juga membantu saya untuk kembali mengingat apa yang saya rencanakan ketika saya membacanya kembali.

## Apa yang saya pelajari sepanjang tahun 2021?

### Berjuang Mengatasi Burnout Akibat Workload Pekerjaan
Kita  semua sama-sama tahu bahwa pandemi ini membuat banyak perusahaan memberlakukan WFH, kecuali perusahaan saya yang sebelumnya, hahaha. Sejak Februari 2021 sampai saya resign bulan lalu pun, ternyata sudah menerapkan WFO 100% setiap hari sekalipun perusahaan itu adalah perusahaan teknologi yang sangat memungkinkan WFH.

Saya mulai merasakan kejenuhan dan ketidaknyamanan di kantor lama saya saat itu. Setelah direnungkan, selama setahun bekerja saya tidak belajar apa-apa kecuali mitigasi dan bertahan hidup. Selama ini, saya bekerja secara spontan, hanya menerima _request_ dari _client_ lalu kerjakan dan _deliver_. Tidak ada planning yang jelas, bahkan sejenis _sprint planning_ pun tidak ada.

Atasan pun tidak memberikan support yang cukup. Ketika rapat, hanya sekadar memberikan ide (sebenarnya tambahan workload) tanpa adanya contoh yang eksplisit dan konkrit. Tentu ini membuat saya dan teman-teman developer lainnya harus berpikir keras ketika ingin mengimplementasikannya. Ketika produk berhasil di-_deliver_, sampai saya resign pun tidak ada saya dengar _developer_ mendapat apresiasi. Hanya manajer dan atasan saja yang menikmati langsung apresiasi dari kantor.

Pada bulan Agustus 2021 awal, saya akhirnya mengalami _burnout_ sampai-sampai tidak ada gairah untuk bekerja lagi. Itu berlangsung selama seminggu lebih. Beruntungnya, saat itu _workload_ sedang sepi karena hanya ada sedikit _request_ dari _client_ saat itu. Saya sebenarnya bukan _burnout_ koding ya, hahaha. Saya lebih merasa jenuh dengan _task_ dari pekerjaan saya saat itu.

Saya bahkan pernah berbicara langsung dengan atasan saya saat itu. Beliau tidak menyangkal apapun perkataan yang saya sampaikan karena memang situasinya seperti itu. Tetapi situasi kantor saat itu dan  _environment_ yang tidak mendukung akhirnya menghambat perubahan yang direncanakan. Saya bisa bilang, belum ada perubahan ke arah yang lebih baik sampai saya resign.

Saya akhirnya belajar bahwa __lingkungan dan kulture kerja sangat krusial__. Ini sangat mempengaruhi kondisi mental saya saat itu. Akhirnya saya memutuskan untuk tidak memperpanjang kontrak dan mencari pekerjaan baru di bulan November 2021.

### "Learning Path" Baru Favorit Saya
Di bulan Agustus lalu ketika _burnout_ sudah mereda, saya mengerjakan sebuah proyek freelance bersama 2 orang teman lama. Kami saat itu membuat aplikasi web menggunakan React sebagai frontend framework dan Node.js untuk sisi backend.

Pada minggu pertama pengerjaan proyek, saya cukup kesulitan karena sebelumnya saya menggunakan Angular dalam _frontend development_, tetapi kali ini harus menggunakan React. Tetapi ketika saya mulai paham dengan pola dan dasar-dasar React sembari mengerjakan proyek, akhirnya semua _task_ saya selesai dan justru malah inilah yang membuat saya ketagihan untuk mempelajari React lebih lanjut. Terima kasih [Agustinus Nathaniel](https://sznm.dev/) yang telah membantu dan mengajari saya untuk memahami React, bahkan secara filosofis, hahaha.

Setelah itu, saya menginvestasikan sebagian uang saya untuk membeli domain dan memaksa diri saya untuk membuat personal website sendiri menggunakan Next.js. Akhirnya itupun selesai dalam sebulan. Tidak berhenti di sana, saya pun juga membuat beberapa personal project untuk membantu mempertajam pemahaman saya mengenai React.

### Akhirnya Dapat Pekerjaan Baru
Saya ingat betul momen saat saya mempersiapkan diri untuk resign dari pekerjaan saya yang sebelumnya pada bulan September 2021. Setelah saya selesai _develop_ personal web saya, saya melanjutkannya dengan membangun personal project dan mempublikasikannya di Linkedin. Sesekali, saya juga menulis artikel dan mempublikasikannya di Linkedin seminggu sekali.

Cukup terkejut karena saya mendapat beberapa pesan melalui Linkedin Chat yang menawarkan pekerjaan sebagai _frontend engineer_ (React based). Saya juga sesekali mendapat telepon dari _talent hunter_ yang menawarkan pekerjaan untuk perusahaan _client_ mereka.

Tetapi kali ini, saya agak selektif dalam mencari kerja karena pengalaman saya sebelumnya. Saya tidak mau jatuh ke dalam perangkap yang sama lagi. Jadi, ketika saya _interview_ dengan _recruiter_ terkait, saya melanjutkannya dengan melakukan riset sendiri dengan menggali informasi mengenai perusahaan terkait. Yang paling sering saya lakukan adalah melihat review dari mantan pegawai perusahaan tersebut di situs [Glassdoor](https://www.glassdoor.com/). Atau terkadang melalui informasi dari akun-akun satir di media sosial (tidak perlu saya jelaskan, karena cukup populer, hahaha).

Saya bisa mengidentifikasi _red flags_ dari calon perusahaan yang saya tuju dari review mantan pegawai yang telah resign. Tidak hanya review sih, seringkali perusahaan yang tidak mempunyai akun profesional seperti Linkedin, bisa jadi adalah _red flag_ walaupun tidak semua.

Di samping itu, apabila ada teman yang saya kenal bekerja di sana, saya biasanya kontak mereka untuk bertanya-tanya tentang perusahaan tersebut. Sebagai contoh ketika saya mendapat offer letter dari sebuah FinTech di Jakarta, ada beberapa teman yang bekerja di sana. Gajinya sangat tinggi, mencapai 2 digit padahal dengan title junior. Tetapi setelah saya melihat teman saya sendiri sering lembur dan bahkan harus kerja saat _weekend_ _(hustle culture)_, saya pun mengurungkan niat saya dan membatalkan offer tersebut.

Saya tahu gajinya sangat tinggi di sana, tetapi saya tidak cocok dengan kultur perusahaan tersebut yang cenderung _hustle culture_ yang tentunya sangat berpotensi membuat saya _burnout_ kembali.

> What you see is what you get. Jika sudah mendapat gambaran melalui interview, review dari mantan pegawai, atau bahkan cerita teman sendiri, berarti kurang lebih ketika bekerja di sana, realitanya tidak akan jauh-jauh.

Beruntung, di bulan November 2021 lalu, seorang _recruiter_ dari sebuah perusahaan yang bergerak di bidang _hospitality_ menawarkan posisi sebagai _frontend engineer_. Saya pun mengikuti semua prosedur _recruitment_ yang ada dan menyelesaikan _take home_ project yang diberikan.

Tiba saatnya untuk _user interview_, dan ini adalah interview yang paling menyenangkan yang pernah saya lalui. Saat itu saya wawancara bersama dengan seorang _frontend engineer_ dan _squad lead_. Mereka tidak _judgemental_, malah mengapresiasi apapun jawaban yang saya keluarkan. Bahkan live coding pun jadi bercanda ria, hahaha. 1 jam pun tidak berasa, hanya terasa seperti beberapa menit.

Beberapa hari kemudian, saya interview kembali dengan seorang manager. Ini adalah pertama kali saya menemukan manager yang supportive sejak interview. Beliau sangat _concern_ dengan kesehatan mental dan workload dari bawahannya. Tak hanya itu, beliau juga terbuka dengan situasi dan kultur kerja kantor saat interview. Saya malah merasa seperti berbicara kepada kolega dibandingkan interview kerja.

Akhrinya, setelah interview tersebut, saya dinyatakan diterima. Proses negosiasi gaji pun berjalan lancar dan akhirnya saya menerima offer letter yang telah dinantikan. Sang _recruiter_ pun sangat informatif dan membantu dalam proses _on boarding_.

Sebagai informasi, saat ini domisili saya di Bogor. Sementara perusahaan tersebut ada di Bandung. Syukurlah saya diberikan opsi untuk kerja secara _remote_ bahkan sampai pandemi berakhir pun tetap _remote_.

Saya akan kembali bekerja sebagai frontend engineer pada Januari 2022. Semoga semua berjalan lancar dan tempat baru ini adalah tempat yang cocok untuk pengembangan diri saya juga.

## Project Selama 2021

### yehezgun.com
Seperti yang telah disebutkan sebelumnya, ini adalah project personal pertama saya di tahun 2021 ini yang dibuat menggunakan Next.js. Bisa dilihat-lihat di [yehezgun.com](https://yehezgun.com). Saya tidak suka membuat design yang terlalu apik. Cukup dengan design yang simpel dan mudah dipahami saja, agar ketika perlu improvement, jadi lebih mudah, LOL.

### Personalized Starter Template
Sejauh ini, ada 2 starter template yang pernah saya buat.
- [yehez-nextchakra-starter.yehezgun.com](https://yehez-nextchakra-starter.yehezgun.com) -> Next.js (Typescript) + Chakra UI starter template
- [yehez-vitechakra-starter.yehezgun.com](https://yehez-vitechakra-starter.yehezgun.com/) -> React (using  Typescript and Vite as builder) + Chakra UI starter template

Kalian bisa membaca artikel saya mengenai manfaat starter template di [sini](https://yehezgun.com/articles/why-making-a-starter-template-matters).

### Personal Link Shortener
Ketika saya menulis artikel, seringkali saya menyisipkan link sebagai referensi. Saya pikir akan lebih baik kalau saya punya link shortener sendiri, tak perlu lagi googling untuk mencari link shortener. Bisa dilihat-lihat di [link.yehezgun.com](https://link.yehezgun.com/).

### Personal Live Markdown Editor
Alasan saya membuat ini adalah untuk memudahkan saya ketika harus menulis Readme untuk sebuah project. Saya membuat ini menggunakan React Markdown Previwer, bisa diakses di [markdown.yehezgun.com](https://markdown.yehezgun.com).

### Personal Docs Site
Lelah juga googling hal yang sama hampir setiap hari, itu sebabnya saya putuskan membuat personal docs sendiri untuk menaruh hal-hal penting yang sering saya pakai. Bisa diakses di [docs.yehezgun.com](https://docs.yehezgun.com).

Artikel mengenai ini juga bisa dibaca di [sini](https://yehezgun.com/articles/why-I-made-my-own-personal-docs-site).

### KAI Access App & Freelance Project
Seperti yang telah disebutkan sebelumnya, saya pernah mengerjakan proyek freelance bersama teman-teman saya. Sayangnya ini adalah proyek tertutup, sehingga saya tidak bisa sembarangan mengeksposenya. Tetapi saya akan ceritakan sedikit apa yang kami buat.

Kami saat itu membuat _warehouse system_ dalam bentuk aplikasi web dan mobile. Seorang teman saya men-_develop_ aplikasi mobile, seorang lagi meng-_handle_ backend, dan saya saat itu menangani di sisi frontend, terutama proses alur datanya. Jadi, karyawan di perusahaan _client_ ini cukup men-_scan_ QR code yang ada di setiap label barang di gudang dan datanya akan otomatis akan ter-_update_ di server. Karyawan lain juga bisa mengecek dan memvalidasi datanya via website.

Untuk aplikasi [KAI Access App](https://play.google.com/store/apps/details?id=com.kai.kaiticketing&hl=en_US&gl=US) sebenarnya ini adalah aplikasi yang saya beserta senior saya kembangkan sewaktu kami masih di perusahaan kami sebelumnya. Senior sayalah yang membuat aplikasi ini dari awal. Saya hanya melanjutkan mengembangkan fitur tambahan seperti fitur order taxi dan PPOB.

## Harapan untuk 2022
2021 ini tergolong tahun yang keras untuk saya pribadi. Mungkin teman-teman pembaca sudah membaca banyak cerita saya di atas. Syukurlah akhirnya sudah sampai di titik ini ya.

Saya pribadi sebenarnya ada banyak hal yang akhirnya harus diubah dan tertunda karena pandemi ini sejak 2020. Tetapi kurang lebih inilah yang ingin saya capai dan pelajari lebih lagi di tahun 2022.
- __[Tailwind CSS](https://tailwindcss.com/)__  
Saya tahu saya masih seorang pemula dalam React. Saya bahkan masih harus _struggle_ dengan CSS walaupun saya seorang frontend engineer, hahaha. Itu sebabnya saya ingin mempelajari Tailwind CSS sebagai preferensi utama saya dalam melakukan _styling_. Kenapa? Setelah membaca dokumentasi terkait, rupanya ini bisa mendorong saya untuk memahami fundamental CSS dan design secara umum sembari menggunakan Tailwind. Yang lebih keren lagi, saya bisa saja membuat design system ala saya sendiri menggunakan Tailwind ini.

- __Clean Code__  
Nah, kurang lebih selama setahun bekerja di perusahaan sebelumnya saya mendapatkan _legacy code_ yang cukup "mengerikan", hahaha. Sangat melelahkan kalau harus improve fitur. Kodingannya berantakan sekali. Jika saya merapikan kodingan saya sendiri, itu berarti saya juga harus merapikan kodingan terkait yang lain yang tentu juga banyak. Akhirnya ini membuat saya terbawa untuk koding "bar-bar". Itu sebabnya tahun depan saya harus mengubah kebiasaan saya untuk membuat kodingan yang lebih rapi.

- __Work-Life Balance__  
Ini sebenarnya impian semua orang, hahaha. Saya harap bisa mencapainya lewat pekerjaan baru saya tahun depan. Semoga bisa mendapatkan lingkungan dan kulture kerja yang sehat, terutama kolega yang suportif.

Nah itulah kurang lebih rekap 2021 dari pengalaman saya dan target tahun depan. Kalau teman-teman pembaca gimana?

Recap 2021

## Table of contents

- [Disclaimer](#disclaimer)
- [Pendahuluan](#pendahuluan)
- [Mulai dari CRUD](#mulai-dari-crud)
- [Membangun "Online Presence"](#membangun-"online-presence")
  - [Membuat Website Pribadi](#membuat-website-pribadi)
  - [Buat Project (atau Mini Project)](#buat-project-atau-mini-project)
  - [Publikasi Project](#publikasi-project)
  - [Bagikan Apa yang Telah Dipelajari Lewat Artikel](#bagikan-apa-yang-telah-dipelajari-lewat-artikel)
- [Bergabung dengan Komunitas atau Event](#bergabung-dengan-komunitas-atau-event)
- [Penutup](#penutup)

## Disclaimer
> Ini adalah tulisan berdasarkan pengalaman pribadi sebagai _frontend engineer_. Bagi sebagian teman-teman pembaca mungkin kurang _relate_ dengan ini, tetapi setidaknya ini bisa menjadi referensi bagi kalian. Saya akan menjelaskan dari perspektif saya sebagai frontend engineer.

## Pendahuluan
Cerita dimulai ketika saya baru lulus kuliah di tahun 2020. Saat itu, Covid-19 baru merajalela di seluruh penjuru dunia. Saya pun kebingungan harus melakukan apa dan bingung mau kerja bagaimana, ditambah saya sendiri saat itu bingung menentukan bidang apa yang mau diperdalam.

Semua berubah ketika seorang teman menawarkan beasiswa [Dicoding Indonesia](https://www.dicoding.com/). Saya tak pikir panjang langsung mendaftar untuk mengambil kelas _Frontend Developer_ sebagai _learning path_ saya. Sejak saat itu, akhirnya saya mulai tertarik dengan dunia _Frontend_, ya walaupun masih _struggle_ dengan masalah CSS, hahaha.

Setelah itu, saya pun mempelajari beberapa _frontend framework_ seperti Angular, Vue dan React. Saya memulai belajar dengan membuat _to-do list_ sederhana menggunakan masing-masing framework. Dari ketiga itu, saya sebenarnya sangat suka dengan React, namun karena pada September 2020 lalu saya mendapatkan pekerjaan sebagai _Frontend Engineer_ di perusaahaan yang menggunakan Angular sebagai _codebase_, akhirnya saya masih harus berkecimpung dengan Angular. Saya kurang lebih bekerja di sana selama 1 tahun 3 bulan.

Saat menjadi _frontend engineer_ fulltime pertama kali, semakin hari semakin menyadari bahwa semakin besar komunitas dari sebuah framework, maka _support_nya pun akan semakin masif. Tentunya hal ini dikarenakan ketika saya harus _troubleshooting_ dengan Angular, saya lebih lama menemukan solusi yang tepat. Dibandingkan saat menggunakan React saat mengerjakan personal project, entah mengapa sangat mudah dan cepat menemukan suatu solusi karena komunitasnya begitu masif.

Karena hal itu, akhirnya saya memutuskan kembali ke React setelah bekerja dengan Angular selama kurang lebih setahun. Beruntung, tempat kerja saya saat itu juga sedang dalam proses migrasi ke React karena ada banyak _frontend engineer_ yang sepemikiran dengan saya, sehingga Product Manager terkait mengusulkan dan bertahap mengimplementasikan React ke setiap project _frontend_. Kami pun belajar React bersama kurang lebih sejak Juli 2021.

Saya belajar React dengan cara langsung membuat beberapa mini-project dan sesekali mempublikasikannya di Linkedin. Rupanya karena hal tersebut, ada beberapa tawaran kerja yang saya dapatkan. Bahkan saya bisa mendapatkan pekerjaan baru karenanya. Sebenarnya project yang saya buat bukanlah project spektakuler, hanya project kecil yang sesungguhnya untuk keperluan saya sendiri.

Saya pikir, mungkin hal-hal ini bisa juga berguna untuk teman-teman pembaca, terutama bagi yang sedang mencari pekerjaan sebagai _developer_. Ini tips dari saya berdasarkan pengalaman saya.

## Mulai dari CRUD
Semua hal yang ada di dunia _software development_ sebenarnya merupakan _Create, Read, Update, Delete_ __(CRUD)__. Ketika saya mempelajari React lagi setelah sekian lama, saya mulai lagi dari CRUD. Bahkan awalnya saya cuma mengikuti tutorial dari [MDN React To-do list tutorial](https://developer.mozilla.org/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/React_getting_started) dan menulis ulang kodenya di VS Code. 

Terlihat _mainstream_ dan umum sekali, tetapi dengan mencoba CRUD, setidaknya saya hanya perlu memikirkan bagaimana saya menambahkan data baru, menampilkannya, mengedit, dan menghapusnya di _framework_ yang saya pelajari. Tentunya ini mempercepat saya memahami kembali _syntax_ yang saya pakai saat itu.

## Membangun "Online Presence"
Jika kalian ingin di-_notice_ oleh _recruiter_, tentunya kalian harus membuat diri kalian terekspose dengan cara membangun _online presence_ kalian masing-masing. Sebagai _developer_, kalian bisa memulainya dengan membuat _website_ pribadi, develop dan publikasi karya di Linkedin & Github, serta menulis _technical blog_.

### Membuat Website Pribadi
Sebagai _frontend engineer_, kalian bisa mulai membuat personal website menggunakan framework atau library favorit masing-masing. Untuk contoh, setelah saya memahami cara kerja CRUD secara umum, saya "memaksa" diri saya untuk membuat personal website saya dengan Next.js. Boleh dilihat-lihat di [yehezgun.com](https://yehezgun.com).

Tak perlu harus "ciamik", cukup jadi diri sendiri. Anggap saja itu adalah _playground_ pribadi, jangan terlalu perfeksionis. Saya pun masih _trial & error_ ketika menerapkan sesuatu yang baru di website saya.

Mungkin ada yang bertanya-tanya, `Kenapa saya harus buat website sendiri?`. Sebenarnya tidak ada aturan baku mengenai ini sih. Tetapi pendapat saya pribadi, dengan memiliki personal web, saya bisa bereksplorasi sepuasnya di sana karena itu milik saya sendiri dan __saya punya kontrol penuh di sana__.

### Buat Project (atau Mini Project)
Menurut saya, ini adalah cara yang efektif untuk memperdalam suatu konsep teknis dan bahkan untuk direkrut oleh suatu _company_. Kalau kalian bingung mau buat apa, bisa loh dimulai dengan __membuat project yang bisa kalian pakai sendiri__. Atau sederhananya, mulai dari hal-hal di menyelesaikan masalah kalian sendiri.

Contohnya, saya memulai dengan membuat starter template dengan Next.js. Bisa diakses di [yehez-nextchakra-starter](https://yehez-nextchakra-starter.yehezgun.com/). Kenapa saya buat itu? Sederhananya, ketika saya membuat project baru, saya malas sekali untuk menghabiskan waktu saya untuk hal-hal repetitif seperti config dan base UI. Akhirnya saya putuskan buat starter template sendiri, sehingga saya fokus untuk development. Penjelasan detailnya bisa diakses di artikel saya di [sini](https://yehezgun.com/articles/why-making-a-starter-template-matters).

### Publikasi Project
Tahap berikutnya adalah __tunjukkan karyamu__. Saya harus katakan, sudah sepatutnya seorang programmer memiliki akun Github atau Gitlab. Github adalah tempat terbaik untuk memamerkan project kalian dan memperlihatkan teknologi apa yang menjadi preferensi kalian. Itu juga bisa menunjukkan seberapa besar _effort_ atau kontribusi kalian lewat jumlah kontribusi yang ada di profil Github kalian [(Mircea Oprea, 2019)](https://medium.com/streamwriter/creating-an-online-presence-as-a-developer-369ec79fb311).

Selain itu, kalian juga bisa mempublikasikan karya kalian di Linkedin. Cara ini bisa juga loh membuat _recruiter_ tertarik dengan profil kalian ketika kalian rajin mempublikasikan karya kalian dan akhirnya menawarkan pekerjaan. Contohnya, ketika saya mempublikasikan hasil _revamp_ personal web saya di Linkedin (bisa dilihat di [sini](https://www.linkedin.com/feed/update/urn:li:activity:6878601141693886465/)), hanya selang beberapa hari ada beberapa _recruiter_ mengirimkan tawaran pekerjaan lewat _Direct Message_. Dan saya pun akhirnya mendapatkan pekerjaan baru karenanya.

### Bagikan Apa yang Telah Dipelajari Lewat Artikel
Mengapa kemampuan menulis ini penting bagi programmer? Dengan menulis blog seperti tutorial, tips & trick,  atau bahkan sekedar cerita testimoni, secara tak sadar kalian juga berkontribusi menolong _developer_ lain yang mungkin mengalami hal serupa. Siapa tahu kan?

Paling sederhana, kalian bisa memulai menulis proses atau tutorial singkat mengenai project kalian. Contohnya Saya menulis tutorial singkat bagaimana cara melakukan _self-host_ Notion API Worker, bisa dibaca di  [sini](https://yehezgun.com/articles/how-to-self-host-notion-api-worker). Tanpa saya sadari, sebenarnya secara tidak langsung saya membantu orang-orang yang juga ingin _self-host_ Notion API Worker mereka ketika mereka membutuhkannya.

Bagi saya, menulis juga bisa menajamkan pemahaman saya akan sesuatu, karena saya "membaca dua kali" bahkan berkali-kali ketika saya menulis. Tentunya sebelum tulisan saya dipublikasi, saya harus membacanya berkali-kali memastikan teman-teman pembaca mengerti apa yang saya maksud.

## Bergabung dengan Komunitas atau Event
Ini juga berdampak signifikan bagi karir saya. Di awal tahun 2021 lalu, saya bergabung sebagai volunteer di salah satu acara Google dan perusahaan partner terkait. Ya, gak salah tebak, saya bergabung dengan Bangkit Academy sebagai _volunteer_.

Saya tahu dengan _skill_ saya saat itu rasanya "kebanting" dengan para developer senior yang juga bergabung saat itu. Saat paling menegangkan adalah saat saya menjadi _teaching assistant_ bagi _partner_ pengajar saya di salah satu sesi kelas online. Gila deh skill koding dan teknisnya, saya pun terkesima dengan cara menjelaskannya yang begitu _fluent_. Tetapi, saya bangga menjadi bagian dari program ini, karena saya pun dapat __memperluas networking saya dengan developer lain__ dan belajar banyak dari mereka.

Terkadang jika beruntung, mereka juga bisa menawarkan atau memberitahu bahwa ada slot lowongan kerja di tempat mereka.

## Penutup

> Coba bangun dan perkuat online presence kalian. Cepat atau lambat, __opportunity__ akan menjangkau kalian selama kalian konsisten dalam menjalankannya.

Saya pribadi telah melakukan tips-tips saya sendiri sejak September 2021, dan __berhasil__. Akhirnya, setelah saya bergumul karena ingin mendapatkan pekerjaan baru, ternyata dapat juga. Saya bahkan tidak _apply_ secara mandiri, seorang _recruiter_ mengirimkan tawaran kerja lewat Linkedin saya dan saya ikuti semua prosedurnya. Yang lebih mengagetkan lagi, saya pun tidak perlu melakukan _live coding_ karena saya telah menunjukkan karya-karya saya sebelumnya saat user interview, sehingga bisa dibilang sesi ini berubah menjadi _live code review_ karena mereka hanya _review_ project saya sebelumnya, hahaha.

Semoga pengalaman saya ini bisa menginspirasi teman-teman pembaca, terutama yang sedang mencari pekerjaan baru. Semangat kawan-kawan!


Mendapatkan Tawaran Kerja Sebagai Programmer Tanpa Apply Mandiri

# Table of contents
- [Disclaimer](#disclaimer)
- [Introduction](#introduction)
- [Seperti Membuat Perpustakaan Digital Pribadi](#seperti-membuat-perpustakaan-digital-pribadi)
- [Bisa Menjadi "Second Brain" atau "Otak Kedua"](#bisa-menjadi-"second-brain"-atau-"otak-kedua")
- [Meningkatkan Produktifitas dan Menghemat Waktu](#meningkatkan-produktifitas-dan-menghemat-waktu)
- [Bisa Menyimpan Apapun, Tak Hanya Hal-Hal terkait Programming](#bisa-menyimpan-apapun-tak-hanya-hal-hal-terkait-programming)
- [Penutup](#penutup)

# Disclaimer
 
Sebenarnya ini adalah pengalaman pribadi sebagai _frontend engineer_ pemula yang merasa kewalahan karena harus _googling_ hal yang sama ketika butuh suatu informasi. Setidaknya ini bisa menjadi referensi bagi teman-teman pembaca.
 
# Introduction

 > Kata siapa dokumentasi itu hanya untuk project-project besar? Gak cuma project sih sebenarnya. Kamu pun bisa membuat situs dokumentasi untuk lingkup pribadi loh.
 
Cerita bermula ketika saya memutuskan untuk hijrah ke React dari Angular sebagai _framework_ favorit dan _learning path_ sejak bulan Juni 2021 kemarin. Sebenarnya awalnya aman-aman saja, ketika saya butuh _troubleshooting_ atau butuh informasi terkait React dan tools-tools terkait, saya hanya butuh membuka Google dan mencari informasi seperti pada umumnya. Ternyata lama kelamaan, saya merasa "capek" sendiri, karena seringkali saya _googling_ hal yang sama, yaitu _tools_ atau _snippet_ yang sering saya pakai.
 
 Seorang teman lama (teman kuliah) sempat menyarankan saya membuat _Personal Documentation Site_, seperti semacam web dokumentasi, tetapi untuk lingkup personal saja. Dia lalu menunjukkan _personal docs site_ miliknya yang dapat diakses di [base.sznm.dev](https://base.sznm.dev). 
 
 Saya pun bertanya kepadanya, "Lah kenapa lu seniat itu bikin web yang isinya cuma catatan pribadi?". Jawabannya kembali membuat saya tercengang.
 
 > Ya cape lah googling sesuatu yang sama yang sering dipake tiap saat. Ngabisin waktu aja, jadi kepikiran deh bikin web yang bisa gw isi dengan hal-hal yang sering gue pribadi pake. Misalnya _snippet_ atau _config_ React gitu. Jadi gw hanya perlu buka web punya gw sendiri, dan jauh lebih efektif kan.
 
Hm.... benar juga. __Daripada saya berulang kali (redundant) googling hal yang sama, apalagi itu adalah hal yang sering saya pakai, kenapa saya juga tidak membuat situs sendiri yang memuat tools atau snippet kodingan yang sering saya pakai. Jadinya tidak perlu membuang waktu untuk googling lagi.__ Sejak saat itu saya memulai membuat _personal docs site_ saya sendiri dan inilah manfaat yang saya rasakan secara pribadi.
 
# Seperti Membuat Perpustakaan Digital Pribadi
 
Inilah impresi pertama saya saat menaruh segala catatan pribadi dan _tools_ yang sering dipakai di situs saya sendiri. Seperti menyortir buku-buku pada rak perpustakaan berdasarkan genre atau kategori buku, itulah yang saya rasakan ketika saya mulai menyortir informasi yang sering saya akses dan gunakan di situs pribadi saya sendiri.
 
Sebagai seorang _programmer_ yang belum memiliki perpustakaan pribadi secara fisik, setidaknya hasrat saya sudah sedikit terpuaskan ketika saya bisa memiliki perpustakaan pribadi secara digital, hahaha. Hebatnya ini bisa diakses lewat perangkat laptop atau _smartphone_.
 
# Bisa Menjadi "Second Brain" atau "Otak Kedua"
 
 Terlalu banyaknya informasi yang beredar di internet sekarang ini tentunya membuat seorang pemula seperti saya sangat kebingungan untuk memilah mana informasi yang saya butuhkan saat ini. Benar kata seorang dosen sewaktu kuliah, __masalah yang dihadapi generasi sekarang itu bukan kekurangan informasi, melainkan terlalu banyak informasi (information obesity) sehingga perlu skill khusus untuk menyaring informasi yang ada.__
 
Nah, dengan membuat _personal documentation_, saya dengan lebih leluasa bisa menentukan _tools_ apa yang memang sering saya gunakan, lalu saya cantumkan saja di dalam web saya. Ketika saya membutuhkan informasi terkait hal tersebut, saya hanya tinggal membuka web saya tersebut dan mengakses atau menggunakannya (_copy & paste_). Pastinya akan menghemat waktu dan meningkatkan fokus dibandingkan saat googling pada umumnya kan.
 
# Meningkatkan Produktifitas dan Menghemat Waktu
 
Nah bayangkan setiap saat butuh informasi, kita buka Google untuk googling. "Mending" googlingnya hanya sesekali, kalau ternyata terlalu sering dan googling hal yang sama terus, tentunya ini __redundant__ dan menyita waktu bukan?
 
Saya beri contoh di sini. Misalnya saya sering menggunakan settingan ESLint yang sama di setiap project saya yang menggunakan React. Nah sebelumnya, saya sering googling terlebih dahulu bahkan sampai membuka banyak browser tab. Kurang lebih saya menghabiskan waktu untuk mencari _snippet_ terkait sekitar 30 menit hanya untuk _config_ ESLint.
 
Ketika saya mulai membangun situs dokumentasi pribadi saya, saya menaruh _snippet_ ESLint yang sering saya pakai di sana. Saat saya membutuhkannya ketika menginisiasi project baru, saya hanya perlu membuka web saya lalu _copy & paste_ ke dalam project saya. Gimana, terasa kan perbedaannya?

# Bisa Menyimpan Apapun, Tak Hanya Hal-Hal terkait Programming

Tidak hanya berupa _snippet_ kodingan saja loh. Saya bahkan bisa menyimpan _tools_ lain di luar dunia _programming_, misalnya _tools_ untuk _video editing_ atau _productivity_.

Saya pun bahkan bisa menyimpan list _anime_ apa saja yang saya tonton atau bahkan _watch list_-nya sekalian, hahaha. Ya namanya situs milik sendiri kan, tentunya bisa digunakan seleluasa mungkin, tidak ada batasan baku di sini.

# Penutup

> Jika kamu sudah mulai merasa capek sendiri ketika googling hal yang sama terus, apalagi itu adalah hal yang sering dipakai, misalnya snippet atau config kodingan, mungkin kamu bisa pertimbangkan untuk membuat web dokumentasi pribadimu. 

Itulah indikator utama apakah kamu butuh web dokumentasi pribadi atau tidak.

Sebagai penutup, teman-teman pembaca bisa mengakses _personal docs site_ milik saya di [docs.yehezgun.com](https://docs.yehezgun.com). Semoga ini bisa jadi inspirasi atau referensi teman-teman ya.

Kalian juga bisa membuat situs dokumentasi pribadi ini dengan [Nextra](https://nextra.vercel.app/) seperti milik saya.

Terima kasih telah membaca artikel ini. Semoga artikel amatir saya ini bisa membantu teman-teman dalam bekerja ya.

Reference: 
- [base.sznm.dev](base.sznm.dev) and [docs.thcl.dev](https://docs.thcl.dev/) as my main example.
- [Nextra](https://nextra.vercel.app/) as the base template

Manfaat Membuat Situs Dokumentasi Pribadi

# Table of contents
- [Disclaimer](#disclaimer)
- [Pendahuluan](#pendahuluan)
  - [Merasa Cemas Kurang Update dan Skill Tidak Relevan](#merasa-cemas-kurang-update-dan-skill-tidak-relevan)
  - [Merasa Kesulitan Jadi Expert Karena Perubahan yang Cepat](#merasa-kesulitan-jadi-expert-karena-perubahan-yang-cepat)
  - [Kewalahan Karena Harus Menguasai Banyak Hal](#kewalahan-karena-harus-menguasai-banyak-hal)
  - [Bingung Memilih Tools atau Framework](#bingung-memilih-tools-atau-framework)
- [Bagaimana Cara Mengatasinya?](#bagaimana-cara-mengatasinya)
  - [Apa Tujuan Tools Ini?](#apa-tujuan-tools-ini?)
  - [Apakah Itu Cocok untuk Masalah yang Dihadapi?](#apakah-itu-cocok-untuk-masalah-yang-dihadapi?)
  - [Siapa yang Membuat? Siapa yang Pakai?](#siapa-yang-membuat?-siapa-yang-pakai?)
  - [Apakah Itu Cukup Populer dan Memiliki Komunitas Pendukung?](#apakah-itu-cukup-populer-dan-memiliki-komunitas-pendukung?)
- [Penutup](#penutup)

# Disclaimer
Di artikel ini, saya lebih fokus membahas dari sisi pengalaman saya sebagai frontend engineer ya. Tidak menutup kemungkinan developer yang menggunakan bahasa pemrograman atau framework lain juga mengalami hal yang serupa, tetapi setidaknya ini bisa menjadi referensi.

# Pendahuluan

> Capek banget ya ngikutin perkembangan teknologi frontend. Baru belajar bentar, eh ada update baru, syntax baru, fitur baru pula. Hadeeehhh.

Tenang, anda tidak sendirian. Saya pun pernah dan mungkin sedang mengalami ini juga sih. Ketika saya pertama kali belajar _frontend engineering_ untuk pertama kali, rasanya antusias sekali. Saat itu saya sedang semangat-semangatnya belajar Angular, Vue, dan React dalam satu waktu. Tapi semua berubah ketika negara api menyerang, wkwk. Kerasa gak sih, makin hari, perkembangan dunia frontend semakin masif? Contohnya, baru-baru ini Next.js sudah rilis versi 12.0 dengan fitur-fitur barunya yang menggugah selera.

Kembali _flasback_ sedikit saat masih awal sekali saya belajar Angular, yang mana saat itu Angular 6 masih cukup _hype_ dan _powerful_ (bagi saya). Kemudian muncul _framework_ baru seperti Vue dan React, dan itu mengubah segalanya.

> Weh, udah coba Vue belum? Lu coba React deh, asik tuh bisa ngoding HTML di JS. Hah masih pake Angular? Jadul banget lu.

Tentu pernyataan-pernyataan tadi hanya sebagian kecil dari yang saya temui di kenyataan sehari-hari. Rupanya saya tidak sendirian, banyak juga ya yang mengalami _Frontend Fatigue_ ini.

Apa sih tanda-tanda kalau kita bisa jadi mengalami _Frontend Fatigue_? Nah mengutip dari post Linkedin Tri Hargianto, kurang lebih ada 4 hal yang menjadi indikasi seseorang mengalami _Frontend Fatigue_.

## Merasa Cemas Kurang Update dan Skill Tidak Relevan
Nah, saya pernah merasakan ini. Tahun lalu ketika saya bekerja sebagai _frontend engineer_ pertama kali, saya masih menggunakan Ionic dan Angular. Saya mulai gelisah ketika bertemu dengan teman-teman kuliah yang juga merupakan _frontend engineer_ di tempat lain, mereka kebetulan menggunakan _framework_ dan _tools_ terbaru di kantor mereka masing-masing. 

Yang paling membuat gelisah adalah saat kami bertemu dan saling membicarakan hal-hal teknis dalam dunia _frontend development. Saya kenal seorang teman yang sudah ahli dalam React Development. Ia sangat mahir dan mengetahui setiap fitur-fitur yang ada di React, bahkan cara kerjanya pun dia paham. Sampai-sampai, _update_ terbaru dari React 18 yang nanti akan rilis dia paham seluk beluknya. Sungguh mencengangkan bagi saya yang masih bertahan di _framework_ merah ini wkwk.

Kekhawatiran saya bertambah ketika sedang iseng mencari lowongan pekerjaan baru sebagai _Frontend Engineer_. Kebanyakan kantor sudah menuntut karyawannya untuk bisa _develop_ aplikasi dengan React dan Redux yang sekarang ini sedang _booming_. Sebagai Angular Developer, tentunya saya harus belajar ulang mengenai React dan _library-library_ pendukungnya seperti Redux, karena saya belum pernah menggunakannya.

## Merasa Kesulitan Jadi Expert Karena Perubahan yang Cepat
Pernahkah anda ketika baru saja belajar suatu _framework_, tak lama kemudian muncul versi barunya yang terdapat _syntax_ atau fitur baru? Tentunya menyebalkan ya, karena kadang-kadang hal itu membuat kita harus belajar ulang deh.

Masih ingat saat awal-awal React masih menggunakan _class component_? Semua tutorial dan para pemula di luar sana berbondong-bondong belajar React dengan _class component_. Semua berubah ketika Hooks tiba. Sekarang, _developer_ bisa membuat _logic_ yang sama hanya dengan _functional component_. Lihatlah sekarang, hampir semua tutorial mengenai React sudah menggunakan Hooks dan _functional component_. Yang sebelumnya terbiasa menggunakan _class component_ pun terpaksa harus belajar ulang mengenai Hooks dan _functional component.

Terbayang kan? Ini baru contoh dari salah satu _framework_. Kita tidak bisa prediksi ke depan akan seperti apa. Bisa jadi, nanti ada _framework_ baru lagi yang lebih _powerful_ dan membuat banyak perusahaan _migrate_ ke _framework_ tersebut. Otomatis, kita sebagai _developer_ pun "terpaksa" harus _up to date_.

## Kewalahan Karena Harus Menguasai Banyak Hal
Sekarang ini, hanya mempelajari _framework_-nya saja tidaklah cukup. Pasti kita sering menemui di mana kita butuh _library_ tambahan untuk menunjang project kita.

Ketika saya pertama kali belajar React, saya tidak bisa hanya belajar React saja. Saya harus belajar _third party library_ lainnya seperti Redux, Chakra UI (UI Component) dan React Router (React tidak punya router bawaan seperti Angular, sehingga perlu install router). Terkadang, ini membuat saya lelah dan nyaris burnout karena harus belajar banyak hal dalam satu waktu sekaligus.

## Bingung Memilih Tools atau Framework
Nah setelah membaca tulisan-tulisan di atas tadi, pastinya ketika menentukan _framework_ atau _tools_ apa yang akan dipakai dalam suatu project menjadi lebih kompleks dari yang dipikirkan. Terlalu banyak opsi di luar sana, membuat _developer_ terutama pemula menjadi bingung mau pakai yang mana.

# Bagaimana Cara Mengatasinya?
Menurut [Tri Hargianto](https://www.linkedin.com/feed/update/urn:li:activity:6833370002012409856/),  setiap _framework_ atau _tools_ mengklaim bahwa merekalah yang terbaik. Faktanya, tidak ada tools yang terbaik. __Yang terpenting justru adalah solusi yang tepat untuk masalah yang tepat.__

Sangat bagus apabila masih terus _update_ dengan perkembangan yang ada. Tapi jangan sampai terlalu tenggelam di dalamnya, sampai-sampai kewalahan sendiri. Jika sampai membuat penasaran sekali, cukup baca atau lihat artikel tentangnya. Jika ingin menggunakannya untuk _project_ kalian, mungkin hal-hal ini bisa menjadi pertimbangan.

## Apa Tujuan Tools Ini?
Sebelum install, pastikan ketahui dulu tujuan kenapa harus pakai _tools_ tersebut. Adalah lebih baik kalau ternyata bisa membuat _logic_ sendiri daripada install _third party library_ yang membutuhkan _resource_ tambahan (tergantung _scope_ project masing-masing).

Ya tergantung lingkup project-nya. Pertimbangkan baik-baik apakah benar kamu membutuhkan _library_ ini? Atau jangan-jangan, malah sebenarnya bisa buat _logic_ sendiri karena _scope_-nya kecil.

Perlu diingat, setiap _library_ tentunya memerlukan _resource_. __Tentunya, jika terlalu banyak _tools_ yang diinstall, itu akan memperngaruhi performa dari aplikasi yang dibuat__.

## Apakah Itu Cocok untuk Masalah yang Dihadapi?
Selanjutnya, pastikan _tools_ yang digunakan bisa membantu menyelesaikan masalah yang sedang dihadapi. Kembali ke dasar, semua tergantung _scope_ dari _project_ yang dikembangkan.

__Kalau ternyata _library_ yang digunakan bisa meningkatkan produktifitas, silahkan lanjutkan. Tetapi apabila malah membuat masalah baru, sebaiknya pikir ulang.__

## Siapa yang Membuat? Siapa yang Pakai?
Nah, dengan mengetahui pencipta di balik sebuah _framework_ atau _library_, tentunya ini bisa meningkatkan kepercayaan penggunanya. Sesekali risetlah siapa yang menciptakan _tools_ tersebut? Apa latar belakangnya? Kenapa dia sampai membuat _tools_ tersebut?

Jangan lupa juga, kita perlu mengetahui segment user dari _tools_ yang kita pakai. __Dengan ini setidaknya akan membantu kita mencari forum terkait ketika kita menghadapi _issue_ terkait _tools_ yang dipakai.__

## Apakah Itu Cukup Populer dan Memiliki Komunitas Pendukung?
__Semakin banyak pengguna dari sebuah _framework_ atau _library_, komunitasnya pun pasti akan berkembang pesat.__

Contohnya React. Kenapa React populer sekarang ini? Karena sudah banyak sekali _developer_ di luar sana yang menggunakan React untuk mengembangkan aplikasi mereka. Ketika menghadapi _issue_ terkait fitur React, mereka mendiskusikan dan saling berbagi bagaimana cara mereka mengatasinya di forum seperti Stackoverflow. Tak jarang juga, sampai-sampai mereka membuat Pull Request ke Repository React sendiri untuk memperbaiki _issue_ yang ada.

Apa efeknya? Tentunya akan memudahkan kita ketika kita menghadapi _issue_ di React, akan sangat mudah menemukan solusinya di forum karena banyak yang pakai dan berdiskusi di sana.

Terlebih lagi, __pastikan tools yang digunakan cukup stabil dalam waktu yang panjang__. Jangan sampai salah pilih _tools_ yang terlalu _outdated_ atau _tools_ baru yang masih banyak _bug_.

# Penutup

Nah dari tulisan tadi, Tri Hargianto menyimpulkan bahwa:

> Tindakan bijak untuk menangani Fronend Fatigue adalah berhenti terlalu memikirkan semua hal baru yang muncul dan cukup mempelajari yang memang **betul-betul menarik perhatianmu** atau yang **diperlukan di pekerjaanmu.**

Intinya, semasif apa perkembangan teknologi frontend ini, yang terpenting adalah **sesuaikan dengan kebutuhanmu, jangan asal ikut trend.**

Sedikit lagi tambahan dari saya, yaitu **perkuat fundamental**. Contohnya, ketika seseorang sudah menguasai dasar-dasar CSS dengan baik, akan sangat mudah baginya untuk menggunakan *tools* seperti Bootstrap atau Chakra UI. Dan ketika ia berpindah ke *tools* lain pun, ia tidak merasa kesulitan.

Berbeda dengan yang langsung belajar Bootstrap tanpa belajar dasar-dasar CSS terlebih dahulu. Ketika ia ingin berpindah ke *tools* lain seperti Chakra UI misalnya, ia malah kelimpungan sendiri dengan *syntax* dan konsep yang ada.

> Jika penguasaan fundamental sudah solid, akan sangat mudah untuk beralih dari satu *tool* ke *tool* yang lain. Tak hanya itu, apabila ia perlu melakukan custom entah dari sisi styling atau logic, itu tidak akan menjadi momen yang menyeramkan.


Nah itulah pengalaman saya terkait Frontend Fatigue ini. Gimana? Ada yang relate? Bisa diskusi di Diskusi.tech ini ya. Semoga menginspirasi walaupun tulisan saya ini masih amatiran, hahaha.


Reference: [Tri Hargianto Linkedin Post](https://www.linkedin.com/feed/update/urn:li:activity:6833370002012409856/)

# Table of contents
- [Pendahuluan](#pendahuluan)
- [Jadi Lebih Fokus ke Proses Development](#jadi-lebih-fokus-ke-proses-development)
- [Meningkatkan Produktifitas](#meningkatkan-produktifitas)
- [Bisa Dijadikan Portfolio](#bisa-dijadikan-portfolio)
- [Bonus dan Closing](#bonus-dan-closing)

# Pendahuluan
> Duh cape juga ya, tiap kali mau inisialisasi project baru harus setup config kayak ESLint sama Prettier berkali-kali.

Itulah yang ada di pikiran saya ketika membuat project baru, bahkan sampai sekarang sebenarnya sih, hahaha. Saya sering merasa "capek" sendiri ketika berulang kali harus _setup_ konfigurasi setiap kali memulai sebuah project, terutama project frontend development ya.

Semua berubah ketika saya mengenal seorang teman yang sudah saya ketahui sangat ahli terutama soal React Development. Saya pernah bekerja bersamanya di sebuah proyek _freelance_. Ketika itu, saya iseng melihat _web profile_ miliknya dan menemukan ada beberapa _starter template_ yang dia cantumkan di _website_.

Saya sempat bertanya-tanya, `Gila niat bener lu bikin template kayak gini.`. Dengan spontan dia menjawab, `Ya biar tiap kali bikin project baru pake framework atau library itu, gak perlu pusing soal config-config yang makan waktu.`.

Menurut saya ini adalah ide yang mantap. Benar katanya, daripada menghabiskan waktu untuk pusing memikirkan konfigurasi, kenapa tidak membuat satu _template_ yang nanti bisa dipakai berulang kali setiap kali buat project baru. Jadi saya tidak perlu pusing harus membuat ulang konfigurasi yang memang cukup memakan waktu, jadinya bisa fokus koding deh.

Sejak saat itu, akhirnya saya pun memutuskan untuk membuat starter template ala saya sendiri. Artikelnya bisa kalian baca di [sini](https://yehezgun.com/articles/post/cara-membuat-starter-template-nextjs-ala-kamu-sendiri). Terlihat sepele memang, tetapi kalau dipikir untuk jangka panjang, justru ini akan sangat membantu. Kenapa? Mari kita bahas sedikit.

# Jadi Lebih Fokus ke Proses Development
Seperti yang tadi sempat tertulis di atas, bayangkan saja setiap kali ketika kalian membuat project baru, kalian harus setup ESLint, Prettier, atau Husky. Tak jarang, konfigurasi ESLint pun kadang membutuhkan _third party plugin_ yang harus diinstall. Proses ini tergolong _redundant_ dan bisa di-_cut_ apabila kalian sudah memiliki starter template sendiri.

Contoh lain, kalau kalian menggunakan _UI Library_ seperti Chakra UI atau Tailwind, proses instalasi dan konfigurasi awalnya saja sudah bikin malas bukan? Apalagi kalian harus melakukannya setiap kali menginisialisasi project baru. Nah, dengan memiliki template sendiri ini, kalian bisa hanya tinggal "clone" saja dan pakai tanpa perlu pusing soal konfigurasi.

# Meningkatkan Produktifitas
Kalau sudah bisa lebih fokus ke proses _development_, otomatis produktifitas kalian saat _develop_ suatu aplikasi akan meningkat juga. Seringkali yang saya alami, momen yang membingungkan adalah bukan saat menemukan _error_ yang disebabkan kodingan yang salah, melainkan saat ada _error_ yang disebabkan karena konfigurasi yang salah atau belum selesai. Tentunya ini akan menyita waktu bukan?

Nah, kalau kalian memiliki starter-template sendiri, kalian bisa _define_ konfigurasi seperti ESLint atau Prettier sejak awal. Setelahnya, jadinya tinggal pakai saja saat kalian menggunakan template tersebut.

# Bisa Dijadikan Portfolio
Jangan salah ya, terlihat sepele memang hanya membuat base template. Tetapi ini juga bisa dijadikan sebagai _portfolio_ loh. Kalian tidak hanya menolong diri sendiri, tetapi juga bisa menolong programmer lain.

Bayangkan saja, awalnya mungkin kalian membuat template ini hanya untuk pemakaian personal. Tetapi kadang tanpa sadar, ada programmer lain yang mengakses _Github repository_ kalian dan menggunakan template kalian untuk mengembangkan aplikasinya. Kalau seperti meme yang populer, `You're a life saver!`.

# Bonus dan Closing
Jadi, cara bikin starter template-nya gimana? Nah ini bisa kalian baca detailnya di [https://yehezgun.com/articles/post/cara-membuat-starter-template-nextjs-ala-kamu-sendiri](https://yehezgun.com/articles/post/cara-membuat-starter-template-nextjs-ala-kamu-sendiri)i.

Sebagai bonus, kalian bisa akses dan gunakan starter template saya sebagai referensi di [https://github.com/yehezkielgunawan?tab=repositories&q=starter](https://github.com/yehezkielgunawan?tab=repositories&q=starter).

Ada 2 starter template yang bisa digunakan untuk saat ini, yaitu ViteChakra-Starter dan NextChakra-Starter. Silahkan dibaca Readme nya untuk cara pemakaiannya ya.

Sekian artikel singkat kali ini. Semoga bisa memotivasi teman-teman ya. Mohon maaf kalau masih ada kesalahan atau kekurangan dalam artikel ini, karena saya pun masih amatir dalam hal ini. Silahkan tulis feedback kalian di kolom komentar ya, terima kasih.

Manfaat Buat Starter Template Sendiri

# Table of contents
- [Pendahuluan](#pendahuluan)
- [Kenapa Banyak Programmer Masih Asal Koding?](#kenapa-banyak-programmer-masih-asal-koding)
- [Dampak dari Asal Koding](#dampak-dari-asal-koding)
- [Cara Bangun Kebiasaan Ngoding Rapi](#cara-bangun-kebiasaan-ngoding-rapi)
- [Dampak dari Ngoding Rapi](#dampak-dari-ngoding-rapi)

# Pendahuluan
> Dah yang penting selesai, deliver ke client, kelar dah.
Begitulah ucapan saya saat pertama kali bekerja sebagai fulltime frontend engineer. Begitu ada _report_ bug dari client, habis sudah rencana _weekend_ yang damai dan tentram itu.

Seiring berjalannya waktu, akhirnya saya sadar bahwa kebiasaan ini adalah _toxic_. Mungkin untuk beberapa saat aplikasi yang dibuat berjalan dengan lancar. Namun, ketika client memberikan _request_ baru entah itu perbaikan fitur atau pembuatan fitur baru, pastinya saya harus mengulik kembali kode yang telah saya buat itu. Dan ya, bisa ditebak akhirnya jadi pusiiiaaaaang sendiri.

Rupanya saya tidak sendirian. Fenomena ini ternyata cukup umum ditemui dalam dunia pemrograman bahkan di level _company_ sekalipun.

Apa sih yang menyebabkan kok banyak ya _programmer_ yang asal koding? Emang dampaknya apa kalau begitu?

Terus gimana caranya biar bisa bangun kebiasaan ngoding yang efektif dan rapi? Apa sih manfaatnya?

Oke, kita bahas satu-satu ya di sini.

# Kenapa Banyak Programmer Masih Asal Koding?
__Faktor pengalaman__ adalah faktor yang paling sering ditemui. Biasanya (tidak juga sih, tapi kebanyakan yang pernah saya temui), ketika seseorang baru belajar soal __programming__, tak jarang struktur kode, file, folder, bahkan penamaan variabel masih terkesan amatir. Tapi tidak apa-apa, saya pun pernah di tahap ini dan ini normal kok. Selama konsisten untuk belajar dan __upgrade__ diri terutama perihal konsistensi untuk membuat kodingan yang lebih rapi dan mudah dipahami (__readable__), lama kelamaan kebiasaan baik itu akan terbangun dengan sendirinya.

Selain itu, ada juga __faktor environment__ atau lingkungan di mana tempat si programmer bekerja. Seringkali, bukannya malas untuk ngoding rapi. _Deadline_ yang mepet dan _request_ atau _task_ bertubi-tubi seringkali membuat programmer menjadi tergesa-gesa dan tidak memiliki waktu untuk merapikan kodenya. Apalagi kalau mendapat _legacy code_ (kodingan project yang sudah dibuat oleh programmer sebelumnya) yang sudah terlanjur "rusak", akan membutuhkan tenaga dan waktu ekstra untuk merapikannya kembali.

Dari pengalaman saya ini, tidak hanya faktor secara individu dari si programmer yang menyebabkan kodingan yang ia hasilkan "berantakan", melainkan faktor lingkungan juga berperan besar dalam hal ini.

# Dampak dari Asal Koding
Teman-teman pembaca sudah pasti bisa menebak apa yang akan terjadi kalau kebiasaan buruk ini terus dilakukan. Kurang lebih inilah efek jangka panjang apabila sang programmer masih terus asal koding tanpa pikir panjang:
* Saat __bug__ menyerang, habislah sudah. Tak perlu dijelaskan, ini sudah cukup horror ketika dialami, hahaha.
* Akan kesulitan sendiri ketika harus menjumpai kode yang sebelumnya telah dibuat saat harus _update_ fitur. Ketika hanya Tuhan yang tau maksud isi kodingannya, maka malanglah nasibnya hehehe.
* Harus buka kodingan saat update konten yang dibuat dengan _hard-code_. Betul _hard-coding_ terasa cepat dan mudah saat develop suatu aplikasi atau produk. Tetapi untuk jangka panjang, ketika ada _update_, pastinya si programmer akan berulang-ulang membongkar isi kodingannya yang tentunya akan melelahkan.
* Kualitas program yang dibuat pun menurun. Tentu saja kodingan yang tidak efektif, apalagi cenderung redundant akan mempengaruhi performa dari aplikasi yang dibuat.

# Cara Bangun Kebiasaan Ngoding Rapi
Dari tadi kita sudah bahas penyebab dan dampak dari kebiasaan ngoding yang berantakan. Sekarang mari kita bahas bagaimana cara membangun kebiasaan agar saat koding, kita bisa menghasilkan kode yang berkualitas. Gimana caranya?

* Mulai dari _folder structure_. Coba mulai pisahkan folder-folder sesuai peruntukannya. Contohnya apabila membuat project dengan React bisa dilihat di [sini](https://reactjs.org/docs/faq-structure.html) mengenai _File Structure_. Agak sulit menjelaskan ini karena bisa panjang sekali dan preferensi setiap orang berbeda-beda. 
* Hindari kebiasaan _hard-coding_. _Hard-coding_ singkatnya adalah penulisan kode statik dimana pengunjung tidak dapat mengubah nilainya karena ditulis langsung melalui text-editor. Untuk lingkup kecil mungkin tidak terlalu berpengaruh, tetapi kalau sudah besar, sebaiknya konten-konten yang akan ditampilkan di aplikasi yang dibuat dimuat di dalam Database atau CMS saja. Gak mau kan harus bolak-balik bongkar kodingan hanya untuk update teks, hehehe.
* Menggunakan _linter_. Nah di Javascript/Typescript sendiri kita sudah bisa menggunakan [ESLint](https://eslint.org/docs/user-guide/) yang merupakan linter untuk mengatur _style coding_ agar tetap konsisten dan sesuai dengan _style_ yang kita atur. Simpelnya, dengan ESLint kita akan "dipaksa" ngoding rapi sesuai _rules_ yang telah di-_define_. Secara garis besar ada 3 jenis _style guide_ yang populer, yaitu AirBnB, Google, dan standar. Detailnya bisa dilihat di [sini](https://betterprogramming.pub/comparing-the-top-three-style-guides-and-setting-them-up-with-eslint-98ea0d2fc5b7).
* Menggunakan bantuan plugin [Prettier](https://prettier.io/). Nah plugin ini bisa diinstall di VS Code. Gunanya untuk membantu merapikan struktur kode yang telah kita buat, sehingga menjadi lebih nyaman saat dipandang.
* Menggunakan [Conventional Commits](https://marketplace.visualstudio.com/items?itemName=vivaxy.vscode-conventional-commits) untuk membantu membuat _commit message_ yang sebagaimana mestinya ketika _push_ ke _repository_ Github atau Gitlab. Tidak hanya kodingan yang harus rapi, _commit message_ pun patut diperhatikan kualitasnya agar memudahkan proses _versioning_ dan _debugging_ saat diperlukan.

Sebenarnya ada alternatif tools lain selain yang saya sebutkan ini, kalau ada yang tahu dan pernah pakai silahkan tulis di kolom komentar ya.

Nah selain menggunakan tools, ada faktor-faktor lain yang tidak kalah penting untuk dilakukan agar kualitas kodingan yang dibuat bisa lebih baik. Ya, itu adalah [planning sebelum koding](https://yehezgun.com/articles/post/planning-sebelum-koding). Mudah untuk dikatakan, tetapi sesulit itu juga menjaga konsistensinya.

# Dampak dari Ngoding Rapi
Mungkin saat mencoba _best practice_ yang telah disebutkan, rasanya akan sulit sekali. Saya pun pernah merasakan saat-saat di mana, saya sendiri frustasi sendiri ketika mendapati kodingan saya _error_ karena tidak sesuai dengan _rules_ dari linter yang telah saya _define_. 

Tapi tenang, semakin dibiasakan justru itu akan semakin baik untuk si programmer itu sendiri. Bahkan orang lain yang membaca kodingan kita pun jadi lebih cepat paham karenanya. Apa aja dampak lainnya dari kebiasaan ngoding rapi ini?

* Memudahkan dan lebih cepat paham ketika membaca kembali kode yang sudah dibuat. Dalam tim, tentunya harus dipikirkan kembali agar kodingan yang dibuat tidak hanya dipahami oleh si pembuatnya saja, tetapi juga harus dipahami oleh rekan-rekan setim. Ini tentunya akan memudahkan proses _debugging_ atau integrasi saat diperlukan.
* Meningkatkan kualitas dari aplikasi atau program yang dibuat. Kebalikan dari dampak negatif yang sebelumnya, dengan kebiasaan ngoding rapi ini tentunya akan berpengaruh positif bagi performa dan kualitas dari aplikasi yang dibuat.
* Mengurangi frekuensi "bongkar" kodingan. Karena konten-konten dari aplikasi atau program yang dibuat dimuat di Database atau CMS, tentunya _user_ bisa mengubahnya lewat akses yang diberikan tanpa harus "bongkar" kodingan.

Sebenarnya banyak dampak lain yang tak kalah menarik dari kebiasaan ini. Tapi setidaknya, inilah pengalaman saya saat saya mulai membiasakan ngoding rapi. Gimana teman-teman, ada kisah menarik saat kalian menerapkan ini? Komen dan diskusikan di kolom komentar ya.

Manfaat Ngoding Rapi

# Table of contents
- [Pendahuluan](#pendahuluan)
- [MVP = Minimum Viable Product](#mvp--minimum-viable-product)
- [Cara Bikin MVP Sendiri](#cara-bikin-mvp-sendiri)
- [Cari Tahu Masalah Apa yang Ingin Diselesaikan](#cari-tahu-masalah-apa-yang-ingin-diselesaikan)
- [Buat Visi Jangka Panjang](#buat-visi-jangka-panjang)
- [Implementasi Pengembangan MVP](#implementasi-pengembangan-mvp)
  - [1. Fokus pada problem utama yang ingin dipecahkan](#1-fokus-pada-problem-utama-yang-ingin-dipecahkan)
  - [2. Prioritaskan fitur utama.](#2-prioritaskan-fitur-utama)
  - [3. Pastikan Produknya Selesai](#3-pastikan-produknya-selesai)
  - [4. Iterasi secara konsisten](#4-iterasi-secara-konsisten)
- [Buat Roadmap](#buat-roadmap)

## Pendahuluan
Sejak dunia stratap, eh startup merajalela pasti kalian yang pernah atau telah berkecimpung di dunia teknologi sering mendengar istilah MVP. Ya, MVP inilah yang tidak bisa dilepaskan dari perkembangan sebuah startup company. 

Gak hanya startup sih, lingkupnya bisa lebih luas lagi, terutama kalau dalam hal _product development_. Semua _product_ besar yang terkenal sekarang ini, sebenarnya lahir dari MVP.

Sebentar, sebentar. Sebelum lebih jauh, mungkin kita harus tau istilah MVP ini apa sih maksudnya? Oke mari kita mulai ya...

## MVP = Minimum Viable Product
Ya, itu adalah kepanjangan dari MVP. Secara harafiah, MVP berarti adalah _product_ yang memiliki fitur dasar untuk menarik perhatian dan memenuhi kebutuhan pengguna yang menjadi target pasar.

Dilansir di Forbes, istilah ini pertama kali dikenalkan oleh Eric Ries, salah seorang pengusaha dan juga konsultan startup dari Amerika dengan bukunya yang berjudul __Lean Startup__. Teknik ini biasa digunakan untuk memvalidasi kembali asumsi dari sebuah model bisnis dan menguji target pasar yang dituju.

Dengan MVP, perusahaan bisa dengan waktu yang relatif singkat membangun dan merilis produk dengan fitur dasar dan "melemparnya ke konsumen". Setelah itu, pastinya _user_ atau konsumen akan memberikan _feedback_ untuk memberitahu apa saja yang harus di-_improve_ untuk memenuhi kebutuhan mereka. Dari _customer feedback_ itulah akhirnya bisa dilakukan iterasi kembali untuk menyesuaikan dengan kebutuhan user.

![MVP](https://diskusi-tech-production.s3.amazonaws.com/i/44k56hvwimyrs0mf4ns1.PNG)
Ingat! MVP berbeda dengan prototype. Jangan hanya berfokus pada kata "minimum", tetapi juga ada istilah "viable". Jangan juga hanya fokus untuk menyempurnakan fitur, tetapi juga harus menemukan kesesuaian dengan market yang ada dan tentunya dikondisikan dengan kondisi "real"-nya.

Nah kalau sekilas membaca pengertian tadi, dapat kita pahami bahwa __MVP bukanlah sekedar produk, melainkan sebuah proses atau kerangka berpikir (_framework_)__ karena terdapat proses iterasi yang akan dilakukan terus-menerus mengingat kebutuhan _user_ bisa berubah seiring perkembangan zaman.

## Cara Bikin MVP Sendiri
Tidak hanya untuk skala perusahaan atau startup, kita sendiri pun secara individu bisa menerapkan teknik MVP ini loh. Saya pun sendiri sudah mencoba menerapkannya dan ternyata menyenangkan, hahaha. Tidak perlu sampai menghasilkan provit sih, setidaknya ini bisa digunakan untuk self-improvement. Kalau provit ya syukurlah.

Saya menerapkan  teknik ini ketika saya membuat mini-project Link Shortener sederhana. Live demo-nya dapat diakses di [https://link.yehezgun.com/](https://link.yehezgun.com/)/. Selanjutnya, saya akan membahas bagaimana membuat MVP dari sudut pandang saya sebagai _frontend engineer_. Maklum karena saya sudah cukup lama berkecimpung di bidang itu. Teman-teman pembaca bisa menyesuaikan dengan bidang dan kondisi masing-masing ya, hehehe.

Singkatnya, ada 4 cara untuk membuat MVP ala kalian sendiri. Dilihat pada gambar ini. Coba kita bahas satu per satu. Saya akan bahas dalam scope mini-project yang telah saya buat sebelumnya, supaya lebih pas dengan kondisi "real" yang dihadapi.
![Create MVP](https://diskusi-tech-production.s3.amazonaws.com/i/2jmfh91hqujpx85ii5w4.PNG)

## Cari Tahu Masalah Apa yang Ingin Diselesaikan
Sebelum menyelesaikan masalah, pasti harus tahu dulu kan masalahnya apa. Sesederhana itu, tetapi sesulit itu juga menjalankannya apabila sudah terbiasa bar-bar, eitss.

Kalau sudah sampai ranah bisnis, pastinya solusi yang dibuat harus bisa dijadikan sumber provit atau untung. Tetapi untuk scope kecil ini, setidaknya _requirement_ yang ditentukan bisa menyelesaikan masalah yang ingin kita _solve_.

Menyesuaikan dengan scope mini-project saya, yaitu Link Shortener, berarti saya ingin membuat aplikasi web yang bisa meringkas alamat web yang dirasa terlalu panjang. Bahkan, aplikasi web ini juga bisa meng-_custom_ alamat web dengan domain yang lebih singkat dan mudah diingat.

## Buat Visi Jangka Panjang
Setelah kita tahu akar masalah yang akan kita _solve_, saatnya koding. __Eh jangan dulu!__

Tentukan dulu, produk yang kita buat sejatinya akan dijadikan apa atau lebih mudahnya, produk kita mau dikenal sebagai apa?

Intinya, jangan hanya sekadar produknya jadi, tetapi tidak dipikirkan apa _goal_ jangka panjangnya. Kalau dalam ranah bisnis, pastinya ini sudah menjadi visi utama dari produk yang dibuat.

Hm... susah ya, rasanya terlalu besar visinya. Oke, kita perkecil scope-nya. Menyesuaikan dengan project Link Shortener tadi, saya ingin agar link shortener yang saya buat ini bisa dengan mudah meringkas url atau alamat web yang dirasa terlalu panjang menjadi alamat web yang lebih singkat dan mudah diingat.

Nah dengan mengetahui tujuan akhir atau kerennya _endgame_ dari produk yang akan kita buat, barulah kita bisa mulai implementasi.

## Implementasi Pengembangan MVP
Nah di tahap ini, baru deh koding. Eitsss... gak asal koding yak.

Setidaknya, 4 prinsip yang harus kita ketahui sebelum lebih jauh.

### 1. Fokus pada problem utama yang ingin dipecahkan
Nah kembali ke dasar. Jangan sampai produk yang kita buat tidak menyelesaikan masalah yang sebelumnya sudah kita ketahui ya. Kalau dalam konteks aplikasi link shortener tadi, hasil akhirnya harus bisa meringkas url yang tadinya panjang menjadi lebih pendek.

### 2. Prioritaskan fitur utama.
Kalau pakai contoh link shortener tadi, fitur utama yang akan dibuat adalah fitur meringkas url yang panjang menjadi lebih pendek, baik secara random ataupun custom dari input user.

### 3. Pastikan Produknya Selesai
Walaupun ada kata "minimum" pada MVP, bukan berarti jadi asal-asalan atau "serabutan". 
> Minimum yang dimaksud adalah produk yang dihasilkan haruslah memenuhi kebutuhan user walaupun dengan fitur-fitur yang mungkin masih _basic_.

### 4. Iterasi secara konsisten
Ingat, MVP itu adalah proses, bukan sekedar garis finish. Tentunya kita perlu tahu apa saja yang harus di-_improve_ ke depannya. Di tahap ini, evaluasi kembali apakah produk yang dibuat telah sesuai dengan target pasar. Bahkan kalau _scope_-nya sudah masuk ke ranah bisnis, harus divalidasi kembali dengan _user feedback_ yang diterima. Dengan demikian, kita pun semakin tahu secara mendalam apa yang dibutuhkan _user_ atau target pasar.

Kalau dalam scope _project_ pribadi, setidaknya setelah kita merilis aplikasi yang dibuat, coba buat semacam _to do list_ yang berisi _improvement_ apa saja yang sekiranya bisa dibuat di masa mendatang nanti.

Setelah itu, kembalilah ke tahap pertama dan lakukan secara konsisten.

## Buat Roadmap
Tidak hanya sekedar menyelesaikan atau membuat produk. Perlu ada rencana jangka panjang agar produk yang dibuat bisa menjadi _long last_. 

Untuk skala kecil, tidak perlu sampai memikirkan strategi marketing atau bahkan meningkatkan "cuan", hahaha. Kalau ala saya sih, saya membuat _to do list_ sederhana yang berisi fitur-fitur atau perbaikan apa saja yang nantinya akan saya buat di project link shortener tadi. Contohnya bisa diakses di [https://github.com/yehezkielgunawan/yehez-shortin](https://github.com/yehezkielgunawan/yehez-shortin)n.

> Daripada nunggu sempurna, kenapa gak coba bikin versi "lite"-nya, tapi setelah itu di-_improve_ pelan-pelan. (Kata seorang teman)

Mungkin penjelasan saya ini terdengar oversimplifikasi. Aslinya sih, lebih komplek ya kalau bicara soal MVP. Tetapi setidaknya, prinsip sederhana ini bisa kita terapkan untuk _self improvement_ secara individu kita masing-masing.

Nah seperti itulah kira-kira proses membuat MVP sendiri. Gimana denganmu? Boleh ditulis di kolom komentar ya.

Referensi : 
Bangkit Academy Soft Skills Module 6: Idea Generation and MVP Planning

Cara Buat MVP ala Kamu Sendiri

# Table of contents
- [Pendahuluan](#pendahuluan)
- [Inisialisasi Project.](#inisialisasi-project)
- [Folder Structure](#folder-structure)
- [Modifikasi Tampilan Dasar](#modifikasi-tampilan-dasar)
- [Tahap Deploy](#tahap-deploy)

## Pendahuluan

Baru-baru ini, saya sedang mendalami React & Next.js. Tentunya untuk memperdalam konsep tentang React & Next.js ini saya sedang rajin-rajinnya membuat project iseng menggunakan _framework_ tersebut. Satu hal yang membuat saya sedikit sebal ketika menggunakannya adalah perihal _config_.

Bermula dari seorang teman yang terlebih dahulu membuat _starter template_ sendiri. Saya pun bertanya-tanya, mengapa dia seniat itu membuatnya? Rupanya, ada _statement_ yang akhirnya membuat saya juga membuat _starter template_ sendiri.

> Males cuy. Tiap initiate project baru harus bikin config lagi dari awal berkali-kali. Makanya kepikiran, kenapa gak bikin starter template aja buat diri sendiri, jadi kalo mau buat project baru, tinggal pake _template_ itu aja dan gak pusing config dari awal.

Setelah dipikir lebih lanjut, benar juga ya. Kenapa saya tidak membuat _starter template_ ala saya sendiri untuk mempermudah saya dalam men-_develop_ aplikasi web menggunakan _Next.js_ ini? Mungkin teman-teman pembaca juga akan memikirkan hal ini, hahaha.

Kali ini saya akan coba membagikan cara saya untuk membuat _starter template_ Next.js. Untuk _UI component_-nya, saya menggunakan [Chakra UI](https://chakra-ui.com/), karena inilah UI component yang paling mudah saya pelajari saat ini.

Mari kita mulai!

## Inisialisasi Project.
Karena saya tipikal orang yang tidak mau pusing. Jadinya saya menggunakan [_starter template_ dasar](https://github.com/vercel/next.js/tree/canary/examples/with-chakra-ui-typescript) yang disediakan Next.js yang menggunakan Chakra UI.

Template tersebut bisa dipakai dengan command :  
```bash
npx create-next-app --example with-chakra-ui-typescript [YOUR_APP_NAME]
```

Sebelum lanjut lebih jauh, saya menginisiasi dahulu ESLint agar _code style_ yang dipakai nanti bisa konsisten. Hal itu dapat dilakukan dengan menambahkan script untuk mengeksekusi `next-lint` di `package.json`. Bisa liat di [sini](https://nextjs.org/docs/basic-features/eslint) untuk lebih lanjut.
```json
"scripts": {
  "lint": "next lint"
}
```

Setelah itu, jalankan command `yarn lint` atau `npm run lint` untuk menginisiasi file `.eslintrc.json`. Lalu dalam hal ini, saya lakukan beberapa modifikasi. Berikut isi dari `eslintrc.json` milik saya. Kalian bisa melakukan beberapa penyesuaian sesuai kebutuhan masing-masing.

```json
{
  "env": {
    "node": true
  },
  "extends": [
    "next/core-web-vitals",
    "eslint:recommended",
    "plugin:@typescript-eslint/recommended"
  ],
  "parser": "@typescript-eslint/parser",
  "plugins": ["@typescript-eslint", "import"],
  "settings": {
    "import/resolver": {
      "node": {
        "extensions": [".js", ".jsx", ".ts", ".tsx"],
        "moduleDirectory": ["node_modules", "src/"]
      }
    }
  },
  "rules": {
    "no-unused-vars": "off",
    "@typescript-eslint/no-unused-vars": [
      "error",
      {
        "argsIgnorePattern": "^_"
      }
    ],
    "@typescript-eslint/explicit-module-boundary-types": "off",
    "@typescript-eslint/no-non-null-assertion": "off",
    "@typescript-eslint/no-inferrable-types": "off",
    "import/order": [
      "warn",
      {
        "groups": [
          ["builtin", "external"],
          "internal",
          "parent",
          ["sibling", "index"],
          "object"
        ],
        "newlines-between": "always",
        "alphabetize": {
          "order": "asc",
          "caseInsensitive": true
        }
      }
    ],
    "complexity": "warn",
    "no-console": ["error"]
  }
}

```

Setelah melakukan config ESLint, saya lanjut untuk meng-_config_ [Next SEO](https://www.npmjs.com/package/next-seo). Tools ini berguna untuk memodifikasi meta-tag yang biasa digunakan untuk mengoptimasi SEO dan membuat preview web kita.

Pertama-tama, install Next SEO dengan command `npm i next-seo`. Lalu buat file `next-seo.config.js` di root folder (folder terluar). Kurang lebih inilah isi dari`next-seo.config.js` saya, silahkan teman-teman pembaca bisa menyesuaikan dengan kebutuhan.
```js
/** @type {import('next-seo').DefaultSeoProps} */
const defaultSEOConfig = {
  title: "yehez-nextchakra-starter",
  titleTemplate: "%s | yehez-nextchakra-starter",
  defaultTitle: "yehez-nextchakra-starter",
  description:
    "Yehezkiel Gunawan's personalized Next.js + chakra-ui + TypeScript starter template",
  canonical: "https://yehez-nextchakra-starter.yehezgun.com",
  openGraph: {
    url: "https://yehez-nextchakra-starter.yehezgun.com",
    title: "yehez-nextchakra-starter",
    description: "Next.js + chakra-ui + TypeScript template",
    type: "website",
    images: [
      {
        url: "https://yehez-og-image.yehezgun.com/**yehez-nextchakra-starter**.yehezgun.com.png?theme=dark&md=1&fontSize=50px&images=https%3A%2F%2Fres.cloudinary.com%2Fyehez%2Fimage%2Fupload%2Fv1631970666%2Fyehez_avatar_vkv7pc.png&widths=200&heights=200",
        alt: "yehez-nextchakra-starter.yehezgun.com og-image",
        width: 800,
        height: 600,
      },
    ],
    site_name: "yehez-nextchakra-starter",
  },
  twitter: {
    handle: "@handle",
    site: "@site",
    cardType: "summary_large_image",
  },
  additionalLinkTags: [
    {
      rel: "icon",
      href: "https://res.cloudinary.com/yehez/image/upload/v1630902976/Assassination_Classroom_-_Koro-sensei_smiling_head_fwpndi.svg",
    },
  ],
};

export default defaultSEOConfig;

```


## Folder Structure
_Setting_-an dasar selesai, waktunya menyesuaikan _folder structure_. Sebenarnya struktur folder dari template dasar Next.js ini sudah bagus, namun entah mengapa saya ingin melakukan modifikasi lebih untuk menyesuaikan dengan preferensi saya.

Kurang lebih, inilah struktur folder yang saya miliki.
```clean
/src
	/components
		/layout
		/motion
		/wrapper
	/functions
		/helper
	/pages
	/types
```


## Modifikasi Tampilan Dasar
Saatnya modifikasi tampilan dasar. Di sini saya mungkin tidak akan menjelaskan isi dari kodingannya karena akan sangat panjang. Di tahap ini kalian bisa memodifikasi isi kodingan sesuai dengan kebutuhan kalian masing-masing.

Sebagai contoh, kalian bisa melihat hasil modifikasi tampilan dasar saya di [https://github.com/yehezkielgunawan/yehez-nextchakra-starter](https://github.com/yehezkielgunawan/yehez-nextchakra-starter)rr.


## Tahap Deploy
Setelah puas dengan tampilan dasar, waktunya deploy kodingan kita ke Github. Untuk cara push project baru ke Github, bisa lihat di [sini](https://www.git-tower.com/learn/git/faq/push-to-github/).

Dalam hal ini, saya menggunakan [Vercel](https://vercel.com/) sebagai platform hosting saya. Sangat mudah menggunakannya, cukup integrasikan repo Github kita dengan Vercel, maka setiap commit yang telah ada akan dibuild secara otomatis. Untuk detail caranya dapat dilihat di [sini](https://egghead.io/lessons/next-js-deploy-a-project-on-vercel-formerly-zeit-from-a-github-repository).

Setelah semua ter_deploy_, jangan lupa untuk membuat repo Github kita sebagai template publik. Caranya bisa klik `Settings` -> `Options` dan centang `Template Repository`.
![Template Repo](https://diskusi-tech-production.s3.amazonaws.com/i/mzpxxxc6hdj4i6hd5un5.PNG)

VIOLAAA, template anda sudah jadi. Template kalian bisa digunakan dengan cara menjalankan command :
```bash
npx degit [Nama repo] <Nama_app>
```
Contohnya :  
```bash
npx degit yehezkielgunawan/yehez-nextchakra-starter test-template
```
Jangan lupa untuk install _dependencies_ dengan command `npm install` atau `yarn` jika menggunakan cara ini.

Atau.

Kalian bisa menggunakan command bawaan dari Next.js untuk menginisiasi suatu project baru menggunakan template dasar yang kalian buat sendiri. Caranya dengan command:
```bash
npx create-next-app --example [Link Repo Github] <YOUR_APP_NAME>
```
Contohnya:
```bash
npx create-next-app --example https://github.com/yehezkielgunawan/yehez-nextchakra-starter test-template
```

Dengan ini, hidup kalian sedikit dipermudah ketika kalian mau membuat project baru menggunakan Next.js, karena kalian bisa fokus untuk develop saja tanpa pusing memikirkan config dasar yang sebenarnya repetitif dan bisa diatasi dengan menggunakan atau membuat template sendiri.

Ini hasil modifikasi starter template saya sendiri: [https://yehez-nextchakra-starter.yehezgun.com/](https://yehez-nextchakra-starter.yehezgun.com/)//. Bagaimana dengan kalian? Tak perlu terlalu sempurna, yang penting sesuai dengan preferensi kalian dan memudahkan kalian dalam proses development.

Demikian artikel saya untuk kali ini. Mohon maaf kalau bahasa saya masih sangat amatir, maklum baru sekarang-sekarang ini belajar menulis artikel, hahaha. Selamat mencoba dan jangan sungkan-sungkan untuk memberikan __feedback__ di kolom komentar Diskusi.tech agar saya bisa tau bagian mana yang bisa saya improve. Terima kasih.

Referensi : [Sozonome NextChakra-starter](https://github.com/sozonome/nextarter-chakra)



Cara Membuat Starter Template Next.js Ala Kamu Sendiri

# Table of contents
- [Disclaimer](#disclaimer)
- [Pendahuluan](#pendahuluan)
- [Membuat Design atau Mockup UI](#membuat-design-atau-mockup-ui)
- [Menentukan Library dan Framework Apa saja yang akan Digunakan](#menentukan-library-dan-framework-apa-saja-yang-akan-digunakan)
- [Menentukan Struktur Folder dan File Project](#menentukan-struktur-folder-dan-file-project)
- [Proses Koding](#proses-koding)
- [Self Code Review dan Minta Feedback Teman](#self-code-review-dan-minta-feedback-teman)
- [Self Retrospective](#self-retrospective)

## Disclaimer
Ini bukan artikel tutorial ya, hahaha. Ini hanya artikel yang membahas lebih kepada pengalaman pribadi bagaimana saya membuat ulang personal website saya, yaitu [yehezgun.com](https://yehezgun.com) dengan framework dan pendekatan metode yang berbeda yang sekiranya bisa menjadi referensi bagi teman-teman pembaca juga.


## Pendahuluan
Berawal dari proyek _freelance_ yang menggunakan [React](https://reactjs.org/) beserta _library-library_ pendukung lainnya, membuat saya penasaran dan ingin terjun sedikit lebih jauh, hahaha. Di samping itu, metode pengerjaan proyek dengan [planning sebelum koding](https://yehezgun.com/articles/post/planning-sebelum-koding) sangat membantu dalam pengerjaan proyek itu sendiri.

Akhirnya saya memutuskan untuk men-_challenge_ diri saya sendiri untuk mempelajari framework tersebut dengan cara me-_remake_ web portfolio saya sendiri. Sebenarnya, saya sudah memiliki personal web saya di [yehezkielgunawan123.vercel.app](https://yehezkielgunawan123.vercel.app), namun saya ingin membuat ulang dengan konsep yang lebih minimalis dan tentu dengan framework yang berbeda.

Awalnya saya adalah tipe _programmer_ ***barbar*** yang lebih suka langsung koding tanpa pikir panjang. Tapi rupanya, setelah setahun bekerja sebagai _frontend engineer_, rupanya kebiasaan itu saya akui toxic dan harus diubah. Untuk itulah kali ini saya mencoba menerapkan perencanaan sebelum saya koding untuk personal web saya yang baru supaya _code_ yang dihasilkan pun lebih berkualitas dan _maintainable_. Tentunya proses planning sebelum koding kali ini saya sesuaikan dengan _scope_ yang lebih kecil untuk _personal project_.


## Membuat Design atau Mockup UI
Sebelum memulai proses koding, pertama-tama saya harus mendapatkan gambaran bagaimana tampilan _web_ yang akan saya buat nantinya. Untuk hal ini, saya menggunakan [Figma](https://figma.com) untuk membuat _mockup_-nya.

Karena saya bukan UI Designer, saya agak _effort_ untuk memikirkan konsep desain _web_ saya sendiri, hahaha. Tapi bukan berarti saya tidak bisa mendesainnya ya. Beruntungnya, tanpa sengaja saya menemukan sebuah _web_ milik [Lee Robinson](https://leerob.io/) yang memiliki desain minimalis dan sederhana tetapi tetap enak dipandang. Akhirnya saya pun membuat desain minimalis seperti miliknya dengan beberapa penyesuaian dan preferensi dari saya sendiri.

Desain _mockup_ saya ini dapat diakses di [**sini**](https://www.figma.com/file/6d877o5HqJm5GstkH3dM1B/Profile-Reborn?node-id=0%3A1)

Tidak memiliki jiwa seni bukan berarti tidak bisa membuat desain ya. Prinsip klasiknya amati, tiru, dan modifikasi. Mungkin terdengar klasik, tetapi justru prinsip inilah yang bahkan bisa membuat sebuah negara seperti Tiongkok menjadi negara maju sekarang.

Sah-sah saja mengambil referensi dari karya orang lain, selama kita cantumkan nanti di daftar referensi yang akan dibuat ya. Di dunia yang serba cepat ini, tak perlu harus membuat dari nol. Kita bisa cari sumber pengetahuan dari orang lain yang sudah membuatnya terlebih dahulu.


## Menentukan Library dan Framework Apa saja yang akan Digunakan
Ibarat ingin membuat kue, tentu kita harus menentukan alat dan bahan apa saja yang akan dibutuhkan. Ini perlu dilakukan agar tools yang kita gunakan tidak terlalu _overpowered_ (OP) atau kekurangan tools.

Semakin banyak _library_ yang di-_install_ tentu akan membuat _node-modules_ akan semakin gemuk dan bisa saja mempengaruhi performa _web_ yang dibuat. Untuk itulah, saya menentukan apa saja _framework_ dan _library_ yang akan digunakan sejak awal.

Dalam hal ini, saya memutuskan untuk menggunakan:
- Repo [Template NextJS + Typescript + Chakra UI](https://github.com/vercel/next.js/tree/canary/examples/with-chakra-ui-typescript) sebagai _project initialization_
- Library [React Notion](https://github.com/splitbee/react-notion) sebagai _renderer_ elemen dari Notion untuk React component.
- [Chakra UI](https://chakra-ui.com/) untuk styling dan UI component.
- [React Icon](https://react-icons.github.io/react-icons/) untuk keperluan menampilkan icon-icon.

Selain menentukan _framework_ dan _library_, tak lupa saya juga membuat config untuk ESLint agar _code_ yang dihasilkan bisa lebih rapi.

```
//.eslintrc
{
  "root": true,
  "parser": "@typescript-eslint/parser",
  "plugins": [
    "@typescript-eslint",
    "prettier"
  ],
  "extends": [
    "eslint:recommended",
    "plugin:@typescript-eslint/eslint-recommended",
    "plugin:@typescript-eslint/recommended",
    "prettier",
    "next"
  ],
  "settings": {
    "import/resolver": {
      "node": {
        "extensions": [
          ".js",
          ".jsx",
          ".ts",
          ".tsx"
        ],
        "moduleDirectory": [
          "node_modules",
          "src/"
        ]
      }
    }
  },
  "rules": {
    "no-console": 1,
    "no-unused-vars": "warn",
    "no-return-assign": "off",
    "@typescript-eslint/explicit-module-boundary-types": "off",
    "@typescript-eslint/no-inferrable-types": "off",
    "no-undefined": "warn",
    "complexity": "warn"
  }
}
```

```
//.prettierrc
{
    "semi": true,
    "trailingComma": "all",
    "printWidth": 80,
    "singleQuote": false
}
```


## Menentukan Struktur Folder dan File Project
Sebenarnya, sudah ada struktur file _default_ yang telah disediakan ketika melakukan create project menggunakan Next JS, tetapi kali ini, saya membuat sedikit perubahan pada struktur project yang ada.

```
/src
   /components
   /constant
   /function
      /helper
      /lib
   /pages
   theme.tsx
```

Folder _components_ berisi komponen-komponen kecil yang merupakan hasil modularisasi untuk ditampilkan di halaman web. Selain itu, biasanya saya juga membuat _reusable component_ di dalam folder ini yang bisa digunakan secara berulang agar tidak redundant.

Pada folder _constant_ dapat berisi variabel-variabel global yang digunakan di banyak component. Terkadang, saya juga menyimpan variabel dari _local environment_ di sini.

Di folder _function_, ini berisi hal-hal yang sifatnya _logic_. Subfolder _helper_ berisi _function-function_ yang berisi _logic_ yang membantu proses _development_, contohnya _function_ untuk mengubah tampilan tanggal. Untuk _function_ yang sifatnya untuk _fetch_ data, biasanya ditaruh di dalam subforlder _lib_.

Di Next JS, folder _page_ berisi component keseluruhan dari halaman yang akan ditampilkan dalam _web_ yang akan dibuat. Beruntunglah, _framework_ ini memiliki _routing_ bawaan yang cukup membantu proses _development_, karena saya cukup menyamakan nama _file_ dengan nama _routing_-nya.

## Proses Koding
Ya, tibalah proses koding. Saya bukan manusia ambis yang langsung menyelesaikannya dalam satu hari. Karena faktor pekerjaan _fulltime_ dan juga ada proyek _freelance_ yang sedang saya kerjakan, otomatis saya hanya punya sedikit waktu saat sedang senggang atau ketika _weekend_.

Karena menggunakan Typescript, hal pertama yang saya lakukan adalah men-_define_ tipe variabel apa saja yang akan saya butuhkan. Setelah itu, barulah saya membuat _function_ atau _logic_ yang diperlukan. Terakhir, saya membuat UI untuk tampilan _web_ saya ini.

Untuk _task management_, saya hanya membuat _to-do list_ sederhana di catatan Notion saya. Saya hanya perlu menuliskan apa saja fitur yang harus dibuat dan menandainya ketika sudah selesai. Contohnya seperti ini :
- Fetch data Project
- Fetch data Artikel
- Halaman Home
- Halaman Projects
- Halaman Artikel
- Halaman About Me

Karena terbiasa _barbar_, saya jarang men-_define_ tipe variabel saat ngoding Typescript. Tetapi dengan bantuan ESLint, saya memaksa diri saya sendiri untuk belajar membuat kodingan yang rapi dan _readable_, sehingga memudahkan saya sendiri untuk mengembangkannya di masa mendatang.


## Self Code Review dan Minta Feedback Teman
Tak lupa setelah _web_ saya selesai dibuat, saya dengan polosnya meminta _feedback_ dari beberapa teman yang saya kenal. Bukan untuk pamer sebenarnya, tetapi lebih untuk mengetahui apa saja yang bisa saya _improve_ dari yang sekarang.

Ada yang lucu dari proses ini. Ketika saya mengecek sendiri kodingan saya, saya merasa kodingan saya berjalan dengan baik. Tapi rupanya, ketika saya meminta teman saya untuk mengeceknya, rupanya banyak hal yang perlu di-improve sekalipun itu bukan bug.

Tak sedikit komentar dan saran dari teman-teman saya. Bukannya membuat kecewa, tetapi justru hal inilah yang membuat saya semangat kembali untuk memperbaiki apa saja yang salah dan meng-_improve_ tampilan dan bahkan kodingan saya.

## Self Retrospective
Seperti _project_ sungguhan, saya menampung _feedbacks_ dari teman-teman saya dan menyesuaikannya dengan apa yang saya buat. Jadi, sembari saya publikasikan karya saya di Linkedin, saya juga sambil jalan memperbaiki dan mengembangkan kembali apa yang bisa di-_improve_.

Itulah mengapa makin hari ada banyak perubahan yang terjadi dalam _web_ saya, entah secara tampilan atau _logic_ kodingan.

---

Keseluruhan proses di atas saya lakukan kurang lebih selama sebulan sepanjang bulan Agustus 2021. Cukup _struggle_ karena harus menyempatkan diri di tengah kesibukan pekerjaan dan _freelance_. Tapi ternyata, ketika melihat hasilnya saya sendiri cukup terkejut dengan diri saya sendiri yang rupanya bisa melampaui batas saya sendiri.

Di sini saya banyak belajar, bahwa sebenarnya _feedback_ dari orang lainlah yang membuat saya jadi tau apa yang kurang dan perlu dikembangkan lebih lagi. Penting sebagai _programmer_ untuk meminta _feedback_ dari yang lebih jago atau berpengalaman. Saya sendiri sudah mengalaminya dan akan melakukannya lagi suatu saat nanti.


Seperti itulah kira-kira cerita saya dalam membangun _personal website_ saya, yaitu [yehezgun.com](https://yehezgun.com). Untuk Github repository-nya, kalian bisa akses di [https://github.com/yehezkielgunawan/yehezgun.com](https://github.com/yehezkielgunawan/yehezgun.com)m. Silahkan juga kalau teman-teman pembaca ingin memberikan feedback lewat kolom komentar atau PR di Github ya, hahaha.

Cerita Di Balik yehezgun.com

# Table of contents
- [Pendahuluan](#pendahuluan)
- [1. Menentukan Requirement Apa Saja yang Dibutuhkan](#1-menentukan-requirement-apa-saja-yang-dibutuhkan)
- [2. Menentukan Fitur dan Pembagian Task](#2-menentukan-fitur-dan-pembagian-task)
- [3. Memulai Koding](#3-memulai-koding)
- [4. Code Review](#4-code-review)
- [5. Retropective](#5-retropective)

# Pendahuluan
> Yang penting koding, masalah error atau jalan itu program gak masalah deh.

Begitulah kira-kira ucapan saya sebagai mahasiswa pemula yang saat itu sedang mendalami ilmu programming. Alhasil nyaris burnout karena kebingungan sendiri menentukan apa yang harus dilakukan ketika negara api menyerang, eh error menyerang. Jangankan error, saat satu tugas atau task selesai, pasti akan kelimpungan untuk menentukan arah selanjutnya yang harus dituntaskan.

Hidup saya berubah ketika mendapatkan proyek *freelance* dari seorang teman kuliah setelah lulus (saat itu menggunakan React untuk sisi *frontend* dan Express JS untuk sisi *backend*). Karena teman saya ini adalah orang yang *"selalu tertata rapi dalam bekerja"*, dari struktur _source code_ saja sudah membuat mata jadi terbuka lebar bak orang yang baru melihat *kodingan surga*. Semua folder dan file sudah ditentukan tempatnya dan direncanakan dengan matang.

Kami saat itu menggunakan metode Kanban dalam pengerjaan proyek ini. Setiap sebulan sekali, diadakan update progress dan task apa saja yang sudah selesai dan akan diselesaikan. Ini tentu sangat memberikan dampak bagi saya yang awalnya seorang *programmer bar-bar*.

Kami bisa menghabiskan sekitar 2-3 jam sendiri untuk _planning task_ bahkan detail alur cara pengerjaan setiap task pun bisa memakan sekitar satu minggu sendiri. Bagi saya saat itu, terkesan jadi lama sekali proses perencanaan ini. Tetapi saya baru merasakan efeknya kemudian ketika saya memulai mengetikan kode di *text editor*.

Tak perlu panjang-panjang menjelaskan dampak dari **Planning Before Coding** ini. Sederhananya, terasa sulit dan lama di awal saat merencanakan apa saja yang akan dikerjakan dan bagaimana nanti cara pengerjaannya. Tetapi, semua akan terasa lancar ketika diimplementasikan dalam bentuk kode. Ya, itu semua karena semuanya telah terencana sejak awal, kalaupun menemui hambatan tentunya akan jauh lebih mudah menanganinya karena arahnya sudah jelas dari semula.

Lalu, bagaimana cara menerapkan teknik **Planning Before Coding** ini? Ada beberapa langkah yang kami terapkan yang bagi kami, ini sangat membantu. Dalam hal ini mungkin saya akan fokus dalam konteks *frontend development* dikarenakan saat itu role saya sebagai *frontend developer*.


# 1. Menentukan Requirement Apa Saja yang Dibutuhkan

Dengan adanya *Product Requirement Document* (PRD), kami sebagai programmer menjadi terbantu untuk memahami apa saja yang *user* kami butuhkan. Tak hanya itu, semua kesepakatan awal telah tertulis untuk mencegah perubahan yang bersifat mayor yang terjadi di tengah *development*.

Sebagai *programmer*, hal ini tentunya sangat membantu ketika *development*. Dari awal, kami sudah mendapatkan gambaran umum akan proyek ini ketika sudah selesai nanti. Dengan demikian, menentukan fitur apa saja yang akan dikerjakan akan sangat mudah.


# 2. Menentukan Fitur dan Pembagian Task

Dari sisi *backend*, kami pun membuat API Contract sebagai pedoman dalam pengembangan API. Sang *backend engineer* dalam tim kami pun merasa terbantu dengan adanya dokumen ini. Kami bisa menghabiskan waktu 2-3 hari sendiri untuk menentukan *endpoint* dan *response* API-nya. 

Untuk sisi *frontend*, tentunya teman saya telah membuatkan beberapa *mockup* untuk memudahkan *frontend development*. Tak hanya itu, component UI yang sekiranya bisa dibuat menjadi *reusable* sudah di-*define* sejak awal, sehingga ini bisa mengurangi resiko terjadinya *redudancy*.

Setelah dokumen-dokumen tersebut selesai, tiba saatnya untuk pembagian tugas menggunakan [Clickup](clickup.com). Proses *task splitting* ini sendiri hampir memakan waktu semalaman untuk satu kali *planning* dalam sebulan. Belum lagi, beberapa hari kemudiannya, kami harus menentukan lagi alur atau cara kami menyelesaikan satu *task*. Di sini prosesnya juga menyita waktu, karena metode atau cara yang digunakan untuk menyelesaikan satu *task* haruslah cara yang *clean*, sehingga ketika melanjutkan *task* berikutnya, tentunya akan memudahkan.

Bisa dibilang, dalam satu bulan kami bisa menghabiskan 1 minggu pertama hanya untuk *planning*. Terkesan melelahkan di awal bagi saya saat itu. Tetapi justru dampaknya akan terasa ketika mulai mengerjakan.


# 3. Memulai Koding

Di sinilah efeknya mulai terasa. Seorang *backend engineer* dalam tim kami entah bagaimana bisa, dia berhasil menyelesaikan nyaris 90% API yang telah ditentukan dalam API Contract kurang dari sebulan. Ketika kami tanya, ia hanya menjawab `Ya gimana, semuanya dah clear sejak awal, palingan kalau bingung ya bingung hal-hal yang baru kepikiran aja.`

Dari sisi *frontend*, karena saya saat itu saya juga masih belajar React, saya merasa agak lambat dalam memahami bagaimana struktur *project* React dan *syntax-syntax*-nya. Namun, karena semua telah direncanakan sejak awal, bahkan cara pengerjaan tiap task pun terdeskripsikan dengan baik, saya pun yang seorang pemula bisa dengan lebih cepat memahami dan menyelesaikan *task* yang ada. 

Memang minggu pertama saat pengerjaan dimulai, saya masih kelimpungan. Tetapi, semuanya mulai terasa ringan di minggu-minggu berikutnya karena sebelum mengerjakan, saya membiasakan membaca deskripsi tiap *task*. Ketika saya paham, barulah saya mulai mengetikan kode di *text editor* saya. Syukurlah saya bisa menyelesaikannya tepat waktu.


# 4. Code Review

Setiap kali satu *task* selesai, saya harus melakukan *Merge Request* di Gitlab agar teman saya bisa mengulas kembali isi kode yang telah saya tulis. Awalnya, saya sering sekali mendapatkan komentar dan harus revisi kembali karena banyak kode yang bisa dijadikan *reusable* dan lebih efektif. 

Bak bimbingan dosen saat skripsi, proses revisi pun bisa terjadi lebih dari sekali. Ini semata-mata bukan untuk menghambat, tetapi untuk jangka panjang agar kodingan yang ditulis bisa tetap *maintainable* dan tidak membuat pusing diri sendiri ketika melanjutkannya. Justru pada proses inilah, saya jadi mengerti bagaimana cara membuat kode yang efektif dan *maintainable*. Tenang saja, semakin sering di-*review* justru semakin tahu apa saya yang harus di-*improve* di waktu mendatang.


# 5. Retropective 

Proses *retrospective* sederhananya adalah refleksi kebelakang dan perencanaan ke depan. Apa saja yang terjadi di masa lalu, dievaluasi dan dicatat. Mulai dari hal positif, hingga hambatan yang sempat terjadi.

Tak hanya itu, setelah evaluasi, kami pun kembali merencanakan apa yang akan dilakukan di masa mendatang untuk penyelesaian proyek ini. Ini contohnya:

```clean
Di Kanban kemarin, ada beberapa task yang deskripsinya belum tertulis. Jadi bingung deh cara kerjainnya, makanya ada task yang belum selesai.

Berarti, next planning pastiin semua task nya dah jelas ya. Kalau ada yang belum jelas bisa sambil jalan aja biar gak blocking satu sama lain.
```

Setelah proses ini selesai, kami kembali ke langkah pertama di bulan berikutnya untuk menyelesaikan sisa *task* yang ada.



Terkesan simpel, tetapi ini termasuk hal yang fundamental. Inilah sebagian pengalaman pribadi saya saat mengerjakan sebuah proyek. Mohon maaf apabila masih ada kekurangan atau kesalahan dalam artikel ini. Semoga pengalaman ini bisa menginspirasi teman-teman pembaca sekalian.


Referensi: 
[How to Plan a Coding Project](https://thecodebytes.com/how-to-plan-a-coding-project-a-programming-outline/)

Planning Sebelum Koding

# Table of contents
- [Pendahuluan](#pendahuluan)
- [Lebih dari Sekedar Koordinator Asisten Laboratorium](#lebih-dari-sekedar-koordinator-asisten-laboratorium)
- [Lebih dari Sekedar Project Leader](#lebih-dari-sekedar-project-leader)
- [Kesimpulan](#kesimpulan)

# Pendahuluan
Tulisan ini sebenarnya adalah pengalaman saya sepanjang kuliah hingga lulus dan bekerja sebagai full-time programmer. Ini juga merupakan ungkapan terima kasih saya kepada senior saya sekaligus yang saya anggap mentor yang membantu saya dalam pengembangan diri saya sebagai developer sejak masih menjadi mahasiswa.

Sejujurnya, sejak awal kuliah sebagai mahasiswa Informatika sampai semester 5, saya masih buta dan tidak tahu arah spesialisasi apa yang harus saya dalami dalam dunia pemrograman. Memasuki semester 6, mata saya semakin terbukakan dengan banyaknya bidang pekerjaan dalam dunia IT yang tentu membuat kepala pusing 7 keliling.

Di kampus tempat saya belajar saat memasuki semester 6, banyak mahasiswa sudah mulai mengambil ancang-ancang untuk melamar intership atau magang ke beberapa perusahaan. Ada yang melamar sebagai front-end engineer, ada juga yang back-end. Beberapa teman bahkan ada yang melamar magang sebagai data scientist, wow.

Saya kembali melihat ke dalam diri saya saat itu dan timbullah rasa gelisah mengenai bidang apa yang ingin saya tekuni secara spesifik. Syukurlah saya sempat bertemu dengan beberapa orang ini. Mereka adalah senior-senior yang sekaligus saya anggap sebagai mentor yang telah mengubah pandangan dan pikiran saya. Sampai lulus sekarang pun, saya tetap mengingat nasihat-nasihat yang pernah mereka berikan kepada saya saat itu.

Di artikel ini saya akan share bagaimana peranan mentor sangat mempengaruhi karir saya sebagai programmer.

# Lebih dari Sekedar Koordinator Asisten Laboratorium
Semasa saya menjadi mahasiswa IT, saya juga melakukan part-time job sebagai asisten laboratorium di kampus saya (biasa disebut aslab). Setiap aslab memiliki koordinator (atau koor) masing-masing. Saat itu, saya memiliki koordinator bernama ko Wendy.

Pembawaannya yang begitu blak-blakan membuatnya dikenal sebagai orang yang galak dan ditakuti oleh banyak mahasiswa. Setiap ada mahasiswa yang kedapatan melakukan plagiat, pasti akan langsung diproses untuk mendapatkan nilai 0 dan akan diberikan surat peringatan oleh fakultas. Saya pun pada awalnya berpikir seperti itu.

Tetapi, semua berubah ketika minggu UAS selesai dan kami para aslab diajak makan bersama olehnya di sebuah restoran di Alam Sutera. Di sana, saya mendengar obrolan yang belum pernah disingkapkan. Beliau menjelaskan mengapa beliau berlaku seperti itu dengan detailnya. Pandangan saya pun berubah sejak itu.

Satu nasihat yang saya ingat betul adalah `Jangan terpaku sama nilai aja. Percuma nilai A tapi gak bisa ngoding bener. Mending nilai C, tapi di dunia real-nya bisa bikin karya yang ciamik.`. Begitulah kira-kira apa yang beliau katakan.

Saya pun setelahnya sesekali menyempatkan diri untuk datang ke ruangannya atau terkadang beliau yang datang ke laboratorium tempat saya berjaga. Saya sempat ditanyai, `Jadi, bidang apa yang mau didalami nih? Jangan bilang semuanya ya. Pilih dong bidang mana yang mau dipelajari lebih secara spesifik!`. Nadanya yang tegas tetapi sambil tertawa membuat jantung saya hampir copot.

`Saya sih minatnya web ko. Tapi bingung nih front-end atau back-end yang mau didalami secara spesifik.` Begitulah jawab saya saat itu.

Mendengar jawaban saya, dengan pengetahuan dan pengalamannya sebagai fulltimer, beliau menjelaskan dengan detail pilihan-pilihan apa yang tersedia sesuai dengan jawaban yang saya berikan. Sebagai mahasiswa yang masih polos saat itu, saya pun hanya bisa tertegun mendengar penjelasannya. Namun ada nasihat yang masih menempel di kepala saya, `Perdalam aja dua-duanya. Fullstack dulu deh. Mulai dari front-end, baru deh ke backend. Mana yang paling bikin bergairah dan lupa waktu saat belajar, itu yang harus dikejar!`.

Nasihat itulah yang membuat saya seperti sekarang ini. Ya sekarang saya telah menjadi front-end engineer di perusahaan tempat saya bekerja sekarang. Di waktu senggang, saya menyisihkan sedikit waktu saya untuk mempelajari back-end dan cloud computing.

Sekarang ko Wendy telah menjadi instruktur Full-Stack Javascript di Hacktiv8 yang didirikan oleh Riza Fahmi. Walaupun saya sudah lulus, ko Wendy masih memberikan rekomendasi di LinkedIn saya sewaktu saya mencari kerja.


# Lebih dari Sekedar Project Leader
Time skip ke tahun 2021 ini, di mana saya telah bekerja sebagai front-end engineer. Di suatu malam setelah saya selesai makan malam, saya menerima chat dari seorang senior lama, sebut saja ko CW (inisial), seorang asisten manager di salah satu e-commerce enabler di BSD. Saya ditawari sebuah project freelance atau side project olehnya.

Awalnya saya ragu untuk menerimanya. Mengingat saya sudah terbiasa dengan kodingan berbasis Javascript dan Typescript, agak butuh waktu apabila ingin mempelajari bahasa pemrograman lain. Rupanya, project yang ditawarkan kepada saya ini menggunakan framework PHP, yaitu Laravel.

Meskipun saya sempat menggunakan Laravel, tetapi itu sudah cukup lama dan perlu waktu untuk kembali mempelajarinya. Akhirnya, saya pun mengiyakan ajakannya karena saya juga ingin menambah pengalaman mengerjakan proyek freelance.

Sejak minggu pertama, saya dikenalkan dengan metode Agile Development menggunakan Scrum dan Kanban board. Walaupun saya sudah familiar dengan istilah ini sejak kuliah, namun ini adalah kali pertama saya menerapkan prinsip ini secara real di project ini.

Saat sprint planning, semua task dipecah-pecah secara detail dan bahkan dideskripsikan secara jelas. Mulai dari judul task, struktur direktori, hingga penamaan file pun sudah ditentukan sejak awal. Terasa melelahkan saat planning, tetapi semuanya worth it karena hari-hari berikutnya saya dan rekan saya yang lain bisa fokus untuk develop tanpa pusing yang lainnya.

Ketika daily sprint, saat ada yang mengalami hambatan, ko CW menyempatkan dirinya untuk melakukan pair programming untuk membantu mencarikan solusi. Saya pun jadi terlatih untuk membuat clean code, walaupun tidak terlalu clean tapi setidaknya saya belajar menerapkan best practice-nya menggunakan Laravel. Bahkan rekan saya yang masih pemula tidak mengalami hambatan yang berarti saat proses development karena dibimbing oleh ko CW.

Prinsip yang beliau ajarkan sampai-sampai saya terapkan juga di pekerjaan utama saya yang sekarang. Bahkan, saya sampai mengusulkan kepada Project Manager di tempat saya bekerja untuk menerapkan metode Agile ini agar proses development bisa lebih fleksibel dan adaptif.


# Kesimpulan
Memiliki senior yang saya jadikan panutan bahkan mentor sangat mempengaruhi karir saya sebagai programmer hingga sekarang. Dari awalnya saya yang masih buta terhadap bidang yang ingin saya tekuni, hingga sekarang saya bisa bekerja sebagai fulltime front-end engineer, itu juga tak lepas karena saya pernah bertemu, bekerja bersama, bahkan belajar bersama mereka.

Dari para senior inilah saya terdorong untuk menjadi advisor di Bangkit Academy untuk Cloud Computing Path. Walaupun saya belum menguasai bidang Cloud secara mendalam, hanya bagian web development-nya saja, setidaknya saya bisa menemani para mahasiswa yang bergabung saat mereka belajar dan sharing berdasarkan apa yang pernah saya alami.

Secara garis besar, inilah dampak yang saya alami ketika memiliki mentor:
* Sangat terbantu saat menentukan arah

Seperti yang ceritakan di atas, sampai semester 5 sewaktu kuliah, saya masih bingung spesialisasi apa yang harus saya dalami. Beruntunglah saya kenal dengan ko Wendy. Beliaulah yang mengenalkan dunia web development pertama kali kepada saya secara mendetail, mulai dari **best practice hingga bidang spesialisasi apa saja yang ada di sana.** Padahal saat itu hanya ngobrol-ngobrol biasa.

* Melatih diri untuk menerapkan clean code

Sejak saya pernah freelance bersama ko CW, saya jadi mulai terbiasa dengan clean code. Saat minggu pertama bekerja dengannya, kodingan saya hampir selalu kena komentar saat di-review. Tetapi, justru itulah yang akhirnya membuat saya tahu untuk **membuat kode yang lebih efektif dan efisien, sehingga bisa lebih maintainable ke depannya.**

* Mengasah kemampuan berkomunikasi

Tanpa saya sadari, saya cukup sering datang kepada para senior saya ini walaupun hanya sekedar minta bantuan saat project saya mengalami kendala dan itu membuat saya berani untuk speak up dan mendorong saya untuk menjelaskan apa yang telah saya buat dengan bahasa yang mudah dimengerti. Hal inilah yang akhirnya membuat saya sadar, **menjelaskan masalah kepada orang lain dengan bahasa yang sederhana akan sangat membantu dalam menentukan solusi yang diinginkan.**


---
Bagaimana jika belum atau tidak memiliki mentor? Ini sedikit tips dari saya:
* Mulai dari orang terdekat.

Dalam circle pertemanan seseorang, pasti setidaknya ada satu orang yang bisa dijadikan panutan. Entah itu, teman sebaya, senior, bahkan atasan di kantor. **Jaga relasi dengan mereka. Tirulah kebiasaan positif dari mereka yang biasa mereka lakukan.** Itu akan sangat membantu membuat perubahan dalam hidup.

Jika beruntung, sesekali nongkrong atau bercengkramalah dengan mereka. Pasti suatu saat akan ada obrolan yang belum pernah tersingkapkan sebelumnya, karena **orang yang terpelajar dan berpengalaman tidak akan menghabiskan waktu untuk hal yang sia-sia.**

* Temukan orang yang dapat dijadikan panutan.

Apabila belum atau tidak mendapatkan panutan dari orang terdekat, bisa juga lewat **media sosial, komunitas, atau bahkan kanal seperti Youtube**. Mungkin tidak perlu sampai menjalin pertemanan karena rasanya agak sulit. Tetapi setidaknya, **tirulah hal-hal positif dari mereka, misalnya gaya kodingnya atau hasrat problem solving-nya.**


Setidaknya itulah sharing dari pengalaman dan tips dari saya. Mereka memang bukan dosen saya secara langsung, tetapi berkat nasihat dan bimbingan merekalah saya bisa seperti yang sekarang ini. Terima kasih para senior yang sekaligus saya anggap sebagai mentor. 

Semoga bisa menginspirasi anda semua yang membaca. Selamat menemukan sosok mentor atau panutan yang diimpikan.

Benarlah seperti yang Benjamin Franklin pernah katakan,
> "Tell me and I forget.  Teach me and I may remember.  Involve me and I learn.” 

Apabila ada hal yang ingin didiskusikan, bisa berikan komentar pada kolom yang tersedia supaya bisa mendapatkan insight baru. Terima kasih.

Salam koding;