Career
Proyek Sampingan Saat Bekerja Full-Time: Strategi Nyata yang Tidak Menghancurkan Hidupmu
April 202611 menit baca
Career
Setiap developer ingin mengerjakan proyek sampingan. Sebagian besar proyek sampingan mati dalam 3 minggu. Kesenjangan antara ide dan produk yang dikirim adalah di mana ambisi bertabrakan dengan realitas memiliki pekerjaan full-time (atau gelar), kehidupan, dan energi yang terbatas. Saya memiliki versi spesifik dari tantangan ini: saya menyelesaikan gelar di SGU sambil bekerja paruh waktu di Commsult Indonesia, yang menyisakan jam yang benar-benar terbatas untuk proyek pribadi. Selama setahun terakhir saya telah mengembangkan — melalui trial and error — serangkaian prinsip untuk menjaga proyek sampingan tetap hidup dan sesekali mengirimnya. Berikut ini.
Proyek sampingan tidak mati karena kurang ide atau ketidakmampuan teknis. Mereka mati karena: lingkup yang meluas melampaui apa yang bisa disampaikan upaya paruh waktu; hilangnya motivasi setelah fase awal yang menarik; perfeksionisme yang mencegah mengirim apapun yang kurang dari ideal; dan ketidakmampuan mempertahankan konteks di seluruh sesi kerja yang sporadis. Dua minggu pertama proyek sampingan mudah — idenya segar, keputusan arsitektur itu menarik, dan kamu membangun fungsionalitas inti. Kemudian kamu mencapai bagian yang membosankan: validasi form, penanganan error, dokumentasi, konfigurasi deployment, template email. Di sinilah proyek mati. Developer menambahkan fitur 'nice to have' daripada mengirim apa yang sudah ada.
Aturan paling penting untuk proyek sampingan di bawah kendala waktu: setiap ide fitur masuk ke daftar, dan tidak ada yang dari daftar itu masuk ke lingkup saat ini kecuali sesuatu yang lain keluar. Versi saat ini memiliki tepat fitur yang dibutuhkan untuk berguna bagi satu pengguna nyata. Tidak lebih. Minimum Viable Product bukan titik awal — itu adalah seluruh versi pertama. Saya telah mengirim hal-hal yang terasa memalukan sederhana yang ternyata persis yang diinginkan pengguna. Saya juga telah meninggalkan proyek yang tumbuh menjadi spesifikasi rumit yang tidak pernah dikirim. Sederhana dan terkirim mengalahkan kompleks dan ditinggalkan, setiap saat.
Diberikan komitmen kerja dan studi full-time, anggaran waktu proyek sampingan yang realistis adalah 5–10 jam per minggu — tidak lebih. Ini perlu dijadwalkan secara eksplisit, bukan 'apapun yang tersisa'. Saya menggunakan pagi akhir pekan (jam 6–9 pagi sebelum kewajiban keluarga dimulai) dan satu atau dua malam hari kerja (jam 7–9 malam). Wawasan kuncinya: 5 jam per minggu terakumulasi secara signifikan selama 6 bulan (sekitar 130 jam kerja terfokus). Aplikasi web sederhana namun dipoles bisa dibangun, diuji, dan di-deploy dalam 100–150 jam. Matematikanya berhasil jika kamu melindungi waktu tersebut dan tidak scope-creep proyek.
Side Project Time Math (part-time dev + full-time student)
──────────────────────────────────────────────────────────
Available hours/week: ~8–10 hrs (protected weekend mornings)
Hours over 6 months: ~130–160 hrs of focused work
What 130 focused hours can produce:
- Simple but polished SaaS MVP
- Production-quality portfolio app (deployed, CI/CD, docs)
- Open source library with tests and README
- Technical blog (12–15 well-researched posts)
Rule: 5 hrs/week compounding beats 30 hrs one weekend then nothing
Session structure (2-hour blocks):
0:00–0:05 Read end-of-last-session notes
0:05–1:45 Focused implementation (no context switching)
1:45–1:55 Write end-of-session notes (plain English)
1:55–2:00 Commit, push, close laptop
──────────────────────────────────────────────────────────Tulis 'project brief' sebelum memulai proyek sampingan apapun: satu paragraf mendeskripsikan apa yang dilakukannya, untuk siapa, apa metrik keberhasilannya (pengguna, pendapatan, atau hanya potongan portofolio), dan apa yang secara eksplisit TIDAK termasuk dalam versi pertama. Baca brief ini di awal setiap sesi kerja. Ini mencegah pergeseran lingkup bertahap yang membunuh proyek dan membantu kamu membuat keputusan 'dalam lingkup / di luar lingkup' dengan cepat ketika ide fitur baru muncul selama pengembangan.
Pembunuh produktivitas terbesar untuk proyek sampingan paruh waktu bukan waktu — tapi biaya context switching. Kembali ke proyek setelah 3–4 hari pergi berarti menghabiskan 20–30 menit pertama mengingat di mana kamu tinggalkan, apa kondisi kode saat ini, dan apa langkah selanjutnya. Overhead ini, dikalikan di setiap sesi, bisa menghabiskan 30–40% dari waktu proyek efektifmu. Solusinya: tulis catatan akhir sesi (bukan komentar kode — catatan bahasa biasa seperti 'Saya sedang mencoba memperbaiki X, menemukan error Y, langkah selanjutnya adalah Z'). Saya menyimpan file markdown scratch per proyek untuk catatan-catatan ini. 5 menit yang dihabiskan menulisnya menghemat 25 menit disorientasi di awal sesi berikutnya.
Ketika waktu terbatas, gunakan teknologi yang membosankan dan familiar untuk proyek sampingan. Proyek sampingan adalah untuk mengirim, bukan untuk mempelajari framework baru. Simpan eksperimen teknologi baru untuk prototipe sekali pakai, bukan proyek yang ingin kamu kirim. Saya menggunakan stack kerja saya (Next.js + TypeScript + PostgreSQL) untuk proyek pribadi karena saya bekerja dengannya setiap hari dan tidak ada waktu ramp-up. Satu pengecualian: jika seluruh tujuan proyek adalah mempelajari teknologi tertentu — dalam kasus itu, secara eksplisit time-box-lah dan jangan pasang ekspektasi pengiriman.
# Project Brief Template (fill before writing a single line of code)
PROJECT_BRIEF = """
Name: [Project name]
What: [One sentence — what does it do?]
Who: [Specific target user — not "everyone"]
Goal: [Portfolio piece | Real product | Learning experiment]
Success: [Metric: deployed URL | 10 users | learned X tech]
Version 1.0 INCLUDES:
- [Feature A — must have]
- [Feature B — must have]
- [Feature C — nice to have, included if time allows]
Version 1.0 DOES NOT INCLUDE:
- [Feature D — backlog]
- [Feature E — v2]
- [Feature F — maybe never]
Tech: [Use boring familiar stack — no framework experiments]
Deadline: [Specific date — 6 weeks from today]
Kill condition: [If not shipped by X date, project is archived]
"""
# Read this at the start of every session.
# Add new ideas to the "does not include" list, not to scope.
Akuntansi jujur: proyek yang telah saya kirim atau berkontribusi secara bermakna: situs portofolio ini (di-deploy, diinternasionalisasi, berkelanjutan); posting blog yang mendokumentasikan topik teknis (berkelanjutan); utilitas kecil dan skrip yang dibagikan di GitHub. Proyek yang telah saya mulai dan tidak saya kirim: dua ide SaaS yang tumbuh melampaui lingkup paruh waktu; prototipe aplikasi mobile yang terhambat oleh keputusan desain; pelacak keuangan pribadi yang digantikan oleh aplikasi gratis. Pola dalam kegagalan saya konsisten: lingkup melampaui waktu yang tersedia, atau saya mencoba memoles ke 100% daripada mengirim pada 80%. Pola dalam keberhasilan saya: lingkup ketat, tech yang familiar, kebutuhan pribadi yang mendorong (saya membangun hal-hal yang saya butuhkan secara pribadi, bukan kebutuhan yang dibayangkan).
Mode kegagalan proyek sampingan yang paling berbahaya adalah proyek yang mulai sukses dan berkembang melampaui apa yang bisa ditopang upaya paruh waktu. Pengguna muncul, permintaan fitur masuk, bug perlu diperbaiki pada timeline yang terasa seperti kewajiban. Jika kamu memiliki pekerjaan full-time, ini menciptakan dinamika pekerjaan kedua yang pada akhirnya akan merusak salah satu dari dua komitmen tersebut. Buat rencana sebelum ini terjadi: baik proyek sampingan menjadi fokus utamamu (kamu mengurangi atau berhenti dari pekerjaan harian), atau secara eksplisit batasi lingkupnya pada apa yang bisa ditangani pemeliharaan paruh waktu. Membangun sesuatu yang membutuhkan perhatian penuh waktu sambil kamu memiliki pekerjaan full-time akan berakhir buruk.
Klarifikasi tujuanmu sebelum memulai: apakah kamu membangun karya portofolio (untuk menunjukkan skill kepada employer) atau produk nyata (untuk mendapat pengguna dan berpotensi menghasilkan pendapatan)? Ini adalah proyek yang berbeda dengan kriteria keberhasilan yang berbeda. Karya portofolio perlu menunjukkan skill teknis, kode yang bersih, dan arsitektur yang menarik — tidak membutuhkan pengguna. Produk nyata perlu memecahkan masalah nyata bagi orang nyata — tidak perlu secara teknis mengesankan. Mencampuradukkan tujuan-tujuan ini menghasilkan karya portofolio dengan kompleksitas yang tidak perlu dan produk nyata dengan optimisasi prematur. Ketahui mana yang kamu bangun.
Mengetahui kapan membunuh proyek sama pentingnya dengan mengetahui kapan memulainya. Tanda-tanda proyek sampingan harus dibunuh atau dijeda: kamu belum mengerjakannya selama 3+ minggu meskipun memiliki waktu; kamu takut daripada mengantisipasi untuk mengerjakannya; lingkup telah meluas ke titik di mana pengiriman terasa bertahun-tahun jauhnya; atau keadaan hidupmu telah berubah dan anggaran waktu tidak lagi ada. Membunuh proyek bukan kegagalan — itu adalah higienitas portofolio. Dokumentasikan apa yang kamu bangun dan pelajari (README atau posting blog post-mortem), kemudian lanjutkan. Pelajarannya berpindah ke proyek berikutnya. Jam yang dihabiskan tidak terbuang hanya karena proyek tidak dikirim.