Kenapa Senior Engineer Selalu Bilang 'It Depends': Konteks di Balik Klise
"It depends." Dua kata yang mungkin paling sering diucapkan oleh senior engineer. Bagi junior, jawaban ini terasa frustrasi. "Saya tanya pilih database, jawabannya 'it depends.' Saya tanya arsitektur microservices atau monolith, jawabannya juga 'it depends.' Apa iya mereka tidak tahu jawabannya?"
Sebaliknya, jawaban "it depends" justru menandakan kedalaman pemahaman. Ini bukan ketidakmampuan menjawab — ini pengakuan bahwa dalam software engineering, jawaban benar sangat bergantung pada konteks.
Mengapa Konteks Begitu Penting
Bayangkan pertanyaan: "Apa bahasa pemrograman terbaik?" Seorang junior mungkin menjawab Python, JavaScript, atau Go berdasarkan pengalaman pribadi yang terbatas. Seorang senior akan menjawab dengan serangkaian pertanyaan balik:
- Apa domain masalahnya? Web backend, data science, embedded systems, atau mobile?
- Siapa yang akan memelihara kode ini? Tim 3 orang atau 50 orang?
- Berapa skala yang ditargetkan? 100 pengguna atau 10 juta?
- Apa kendala non-fungsional? Kecepatan eksekusi, kemudahan hiring, ekosistem library, atau biaya infrastruktur?
Jawaban yang benar untuk satu konteks bisa menjadi jawaban yang buruk di konteks lain. Richard Hamming, matematikawan terkenal, pernah berkata: "The purpose of computing is insight, not numbers." Dalam konteks kita: tujuan engineering bukan menemukan jawaban absolut, melainkan memahami problem dengan cukup baik untuk memilih trade-off yang tepat.
Trade-off: Inti dari Engineering
Software engineering pada dasarnya adalah ilmu tentang trade-off. Setiap keputusan teknis memiliki konsekuensi yang harus dipertanggungjawabkan.
- Microservices memberikan skalabilitas dan isolasi tim, tetapi membawa kompleksitas operasional (networking, observability, deployment) yang tidak ada di monolith.
- NoSQL memberikan skalabilitas horizontal dan fleksibilitas skema, tetapi kehilangan konsistensi transaksional dan kemampuan join yang dimiliki relational database.
- Event-driven architecture memberikan decoupling dan reakbilitas, tetapi menyulitkan debugging dan membuat alur data tidak langsung terlihat.
- TypeScript memberikan type safety dan tooling yang lebih baik, tetapi menambah langkah kompilasi dan kompleksitas konfigurasi.
Senior engineer tidak mengatakan "it depends" karena mereka tidak tahu. Mereka mengatakan itu karena mereka tahu terlalu banyak — mereka melihat 20 pendekatan yang berbeda, masing-masing dengan 10 trade-off, dan tidak ada satu solusi yang mendominasi yang lain di semua dimensi.
Pola Pikir yang Dewasa
Perkembangan seorang engineer bisa dilihat dari bagaimana mereka merespons pertanyaan terbuka:
- Tahap 1 — Dogmatis: "Always use X." Engineer baru cenderung mengadopsi satu pendekatan dan menerapkannya di mana saja.
- Tahap 2 — Relativis: "It depends... I guess?" Mereka mulai memahami adanya variabel, tetapi belum bisa mengartikulasikannya.
- Tahap 3 — Pragmatis: "It depends on A, B, and C. If A, use X. If B, use Y. If C, let's test first." Mereka bisa menjelaskan trade-off dan memilih berdasarkan konteks.
Tahap 3 adalah tempat senior engineer beroperasi. Mereka tidak mencari satu kebenaran — mereka mencari solusi yang cukup baik untuk konteks spesifik yang dihadapi.
Cara Memanfaatkan Jawaban "It Depends"
Sebagai junior atau mid developer, reaksi terbaik terhadap "it depends" bukanlah frustrasi, melainkan rasa ingin tahu:
- Tanyakan variabel yang relevan. "Apa faktor yang membuat X lebih baik dari Y?" Ini mengubah percakapan dari mencari jawaban menjadi memahami trade-off.
- Tawarkan konteks Anda. "Untuk use case spesifik kami — 50 ribu pengguna, tim 4 orang — apa yang Anda rekomendasikan dan mengapa?"
- Pelajari pola pikir, bukan aturan. Alih-alih mengingat "pakai PostgreSQL untuk semua," pahami kapan dan mengapa dokumen store lebih baik daripada relational database.
Pada akhirnya, kemampuan untuk mengatakan "it depends" dengan percaya diri dan menjelaskan trade-off di baliknya adalah salah satu ciri utama engineer berpengalaman. Ini bukan klise — ini sinyal kedalaman pemahaman.
Referensi
- Hamming, R. W. (1962). Numerical Methods for Scientists and Engineers. McGraw-Hill.
- Fowler, M. (2015). Making Architecture Matter. martinfowler.com.
- Hunt, A., & Thomas, D. (1999). The Pragmatic Programmer. Addison-Wesley.
- Ford, N., Richards, M., & Sadalage, P. (2020). Software Architecture: The Hard Parts. O'Reilly Media.