Mengapa Matthews memilih bekerja di tiga domain sekaligus alih-alih berspesialisasi lebih awal?

Ini bukan sepenuhnya pilihan yang disengaja — menyelesaikan gelar di Swiss German University sambil bekerja paruh waktu sebagai engineer DevOps dan membangun aplikasi web serta sistem ERP di sela-selanya menciptakan situasi multi-domain secara organik. Pintu masuknya adalah DevOps melalui mata kuliah Linux dan Docker, yang kemudian mengarah ke peran DevOps paruh waktu, lalu pekerjaan ERP menyusul. Keluasan ini muncul karena mengikuti minat dan peluang nyata, bukan strategi yang direncanakan sebelumnya.

Apa tantangan kognitif terbesar dari pergantian konteks antara tiga domain ini setiap hari?

Bagian tersulitnya bukan kedalaman teknis — melainkan pergeseran mode mental yang dibutuhkan antar domain. DevOps menuntut pola pikir sistem yang fokus pada mode kegagalan dan pemantauan, ERP memerlukan pola pikir logika bisnis seputar hierarki persetujuan dan integritas data, sedangkan pengembangan web membutuhkan pola pikir produk yang berpusat pada UX dan performa. Beralih antara mode-mode ini di tengah hari memang secara kognitif mahal, dengan beban overhead terkonsentrasi di awal sesi, bukan pada pekerjaan itu sendiri.

Bagaimana Matthews mengelola beban kognitif pekerjaan multi-domain secara praktis?

Kebiasaan kunci adalah menulis tiga poin peluru di akhir setiap sesi kerja yang merangkum di mana Anda berhenti dan apa langkah selanjutnya — ritual yang hanya memerlukan 2 menit namun menghemat 20 menit waktu pemanasan pada sesi berikutnya. Secara lebih luas, manajemen waktu bergantung pada pemblokiran waktu berdasarkan domain (bukan per tugas), catatan konteks di setiap akhir sesi, dan pembatasan lingkup yang tanpa ampun pada proyek sampingan. Lever terbesar adalah mengatakan tidak pada hal-hal menarik yang tidak sesuai fokus saat ini.

Bagaimana ketiga domain saling memperkuat satu sama lain alih-alih hanya bersaing untuk waktu?

Pengetahuan DevOps memperkuat pengembangan web — memahami cara Nginx melayani Next.js, cara mengonfigurasi header cache, dan cara menyiapkan lingkungan staging. Pekerjaan ERP membangun kemampuan berpikir sistem yang lebih baik karena logika bisnis memiliki invariant dan kasus tepi yang lebih kompleks dari kebanyakan contoh tutorial. Pengembangan web pada gilirannya menjadikan engineer DevOps lebih baik saat membangun alat internal yang menghadap pengguna, karena persyaratan UX sudah dipahami dengan baik.

Menyeimbangkan DevOps, ERP, dan Web Dev Saat Kuliah

Q: Apa risiko jangka panjang terbesar dari bekerja di banyak domain, dan bagaimana cara mengatasinya?

Risiko nyatanya bukan kelelahan — melainkan tetap dangkal secara permanen di semua domain dan tidak pernah membangun solusi yang benar-benar baru di bidang mana pun. Langkah penanggulangan yang disarankan adalah menetapkan tujuan kedalaman triwulanan di satu domain untuk melampaui tingkat pemahaman permukaan. Prinsip dasarnya adalah bahwa keluasan multi-domain membuka pintu, tetapi kedalaman di setidaknya satu area adalah yang membuat seorang engineer layak dipekerjakan untuk peran-peran serius.

Refleksi jujur tentang mengelola tiga domain teknis sekaligus — biaya kognitifnya, sinergi yang mengejutkan, dan apa yang ingin saya katakan pada diri sendiri di masa lalu.

Ringkasan Utama

Menyeimbangkan DevOps, pengembangan ERP, dan pengembangan aplikasi web sekaligus sebagai mahasiswa bisa dijalani asal dilakukan dengan sengaja: alokasikan waktu berdasarkan domain, bukan tugas, tulis catatan konteks singkat di akhir setiap sesi kerja, dan tetapkan target kedalaman triwulanan di satu domain agar keluasan di ketiganya tidak membuat Anda tetap dangkal selamanya di semua bidang.

Kebanyakan saran karir mengatakan untuk berspesialisasi lebih awal, mendalami satu area, dan membiarkan keluasan datang kemudian. Saya pergi ke arah lain — tidak sepenuhnya karena pilihan. Pada tahun terakhir saya di Swiss German University, sambil bekerja paruh waktu sebagai engineer DevOps dan membangun aplikasi web dan sistem ERP kustom di sela-selanya, saya terus-menerus beralih konteks antara tiga domain teknis yang berbeda. Itu lebih sulit dari yang saya duga dan lebih memuaskan dari yang saya perkirakan. Ini adalah catatan jujur tentang bagaimana semuanya benar-benar berjalan.

Bagaimana Saya Berakhir di Tiga Domain Sekaligus

Semuanya dimulai dengan DevOps. Saya masuk ke Linux dan Docker melalui mata kuliah universitas, membangun beberapa proyek sampingan di DigitalOcean, dan menemukan bahwa saya benar-benar menikmati infrastruktur. Itu mengarah ke peran DevOps paruh waktu.

Realitas Harian Pergantian Konteks

Bagian tersulit bukan kedalaman teknis — melainkan pergeseran mode mental. Pekerjaan DevOps memerlukan pola pikir sistem. Pengembangan ERP memerlukan pola pikir logika bisnis. Pengembangan web memerlukan pola pikir produk. Beralih antara mode-mode ini di tengah hari memang secara kognitif mahal.

Universitas dalam Campuran

Swiss German University menjalankan kurikulum yang lebih luas dari kebanyakan universitas Indonesia, dengan mata kuliah dalam sistem operasi, komputasi awan, rekayasa perangkat lunak, dan proyek capstone akhir. Pekerjaan akademis saat itu adalah beban sekaligus hadiah — beban karena bersaing dengan waktu untuk pekerjaan berbayar dan proyek sampingan, dan hadiah karena memaksa saya memformalkan pengetahuan yang diperoleh secara informal.

BREADTH  (general software engineering)
  ◄──────────────────────────────────────────────────────►

  Linux │ Git │ SQL │ REST APIs │ TypeScript │ Bash │ Docker
  ──────┼─────┼─────┼───────────┼────────────┼──────┼───────
        │                 DEPTH                           │
        ▼                                                 ▼

 ┌──────────────┐   ┌──────────────┐   ┌──────────────────┐
 │   DevOps /   │   │    ERP /     │   │   Web App Dev /  │
 │  Cloud Infra │   │  Business    │   │   Next.js        │
 │              │   │  Systems     │   │                  │
 │ GCP, Docker  │   │ Workflows,   │   │ React, next-intl │
 │ Nginx, CI/CD │   │ Approvals,   │   │ TypeScript,      │
 │ Monitoring   │   │ NestJS APIs  │   │ Tailwind, SEO    │
 └──────┬───────┘   └──────┬───────┘   └────────┬─────────┘
        │                  │                     │
        └──────────────────┴─────────────────────┘
              Each domain REINFORCES the others:
         DevOps → deploy web apps & ERP in production
         ERP → teaches real business logic for web apps
         Web Dev → builds UIs for ERP & monitoring tools

Tulis tiga poin peluru di akhir setiap sesi kerja yang merangkum di mana Anda tinggalkan dan apa langkah selanjutnya. Ritual ini memerlukan 2 menit dan menghemat 20 menit waktu pemanasan pada sesi berikutnya.

Di Mana Domain-Domain Saling Memperkuat

Manfaat tak terduga dari pekerjaan multi-domain adalah penyerbukan silang. Pengetahuan DevOps membuat saya menjadi pengembang web yang lebih baik. Pekerjaan ERP membuat saya menjadi pemikir sistem yang lebih baik. Pengembangan web membuat saya menjadi engineer DevOps yang lebih user-aware.

T-Shape dalam Praktik

Saat ini saya lebih seperti bentuk M: kedalaman sedang di tiga area yang terhubung, dengan keluasan bersama di bawahnya. Keluasan bersama di semua tiga domain mencakup: TypeScript, PostgreSQL, desain REST API, Linux, Git, Docker, dan jaringan dasar. Investasi dalam hal-hal ini tidak pernah sia-sia.

# My rough weekly rhythm during my final year of university (not always this clean, but aspirational)

MON–TUE  │ DevOps / Infra work
         │ → VPS provisioning, CI/CD pipeline fixes,
         │   monitoring alerts, cloud cost review

WED–THU  │ ERP feature development
         │ → NestJS backend: approval workflows,
         │   invoice generation, RBAC, email triggers

FRI      │ Web app / portfolio / side projects
         │ → Next.js, Tailwind, SEO, performance tuning

WEEKEND  │ Study: Swiss German University coursework
         │ → Operating systems, cloud computing,
         │   software engineering capstone

# Context-switching tricks I actually use:
# 1. End each block by writing 3 bullet notes: "where I left off"
# 2. Keep separate terminal workspaces per domain (tmux sessions)
# 3. Short 5-min "warm-up" re-read before diving in
# 4. Never mix domains mid-flow — finish the task first

Apa yang Ingin Saya Katakan pada Diri Saya di Masa Lalu

Rangkul keluasan, tetapi bersikap disengaja tentang hal itu. Jangan menyebar diri terlalu tipis secara tidak sengaja — lakukan secara desain, dengan rencana kapan dan bagaimana Anda akan mendalami. Dokumentasikan semua yang Anda pelajari untuk diri Anda di masa depan.

Risiko nyata dari pekerjaan multi-domain bukan kelelahan — melainkan tetap dangkal secara permanen. Tetapkan tujuan kedalaman triwulanan di satu domain untuk melawan drift ini. Keluasan multi-domain membuka pintu; kedalaman adalah apa yang membuat Anda dipekerjakan.

Bagaimana Saya Mengelola Beban Kerja secara Praktis

Manajemen waktu bergantung pada beberapa kebiasaan yang tidak bisa dikompromikan: pemblokiran waktu berdasarkan domain, catatan konteks di setiap akhir sesi, dan pembatasan lingkup yang tanpa ampun pada proyek sampingan. Lever terbesar adalah mengatakan tidak pada hal-hal menarik yang tidak sesuai fokus saat ini.

Ke Mana Ini Menuju

Saya tidak berencana untuk tetap multi-domain selamanya. Strateginya adalah menggunakan keluasan sebagai fondasi dan berkumpul pada spesialisasi utama saat peluang mengkristal. Tiga domain secara alami berkumpul menuju membangun sistem perangkat lunak produksi yang berjalan dengan andal.

Update: Saya telah lulus dari Swiss German University dan kini bekerja penuh waktu sebagai AI Forward Deployed Engineer. Tulisan ini adalah potret tahun terakhir saya, saat saya masih menyeimbangkan gelar dengan peran paruh waktu — kebiasaan tiga-domain yang dijelaskan di atas masih persis seperti cara saya bekerja hari ini.

Menyeimbangkan DevOps, ERP, dan Web Dev sebagai Mahasiswa Teknik Tingkat Akhir