5 mitos di industri software development Indonesia
Sejarah mencatat
kalau penggunaan komputer di Indonesia dimulai di sekitar tahun 1970-an dan
cabang ilmu komputer atau teknik informatika mulai berkembang di Indonesia
sekitar akhir tahun 1970-an. Bila memang benar cabang ilmu komputer masuk di
Indonesia di tahun tersebut, berarti hampir 40 tahun industri software
development di Indonesia tidak mengalami banyak kemajuan yang berarti. Kenapa
demikian? Karena selama satu dekade belakangan, tingkat turnover di industri software development di
Indonesia masih tergolong tinggi dibandingkan di industri lainnya,delivery date yang tidak sesuai perencanaan dan
fitur-fitur yang tidak sesuai permintaan kostumer.
Namun walaupun
dengan semua permasalahan pelik tersebut, masih banyak saja praktisi IT di
Indonesia yang melakukan hal yang sama seolah-olah kegagalan dalam 40 tahun
belakangan belum menjadi cukup bukti kuat untuk mereka merubah cara berpikir
dan cara berperilaku dalam software development. Seharusnya orang yang telah gagal berkali-kali langsung
belajar dari kegagalan dan tidak melakukan hal yang telah menyebabkan ia gagal
untuk kedua kalinya, namun hal tersebut seolah-olah tidak berlaku di Indonesia
karena banyak orang Indonesia yang menggunakan kaca mata kuda yang tidak
memperhatikan perkembangan dan perubahan di belahan dunia lain.
“A problem can’t be solved from the same
state of mind that created it. — Einstein”
Pada hari ini, pada
saat anda sedang membaca artikel ini, di Indonesia ada proyek software
development yang sebentar lagi akan gagal dan pada saat yang bersamaan ada
beberapa software developer yang baru saja bekerja di perusahaan selama kurang
dari satu bulan berniat untuk mengundurkan diri dari perusahaan dimana ia
bekerja. Banyak manajer dan petinggi perusahaan yang masih memiliki pola pikir
dari teori manajemen dari tahun 1900-an dalam mengelola proyek software
development di abad 21. Oleh karena itu banyak dari manajer IT ini yang
perlu diganti karena mereka belum menyesuaikan diri dengan perkembangan
jaman. Apakah ini hanya merupakan kesalahan mereka saja? Tidak juga, perilaku
mereka yang tradisional ini juga banyak dipengaruhi oleh atasan mereka yang
berlagak tidak mau tahu dan sebuah departemen yang sering disebut Human
Resource Department (HRD) yang masih menggunakan teori-teori jaman kuda yang
sudah banyak disangkal oleh ilmuwan dan psikolog. Saya menyebut orang-orang
yang duduk di Manajemen dan HRD sebagai partners in crime to demotivate people
in the workplace. Saya menyebut teori jaman kuda yang mereka anut tersebut sebagai mitos.
mitos
(n).
sebuah pemikiran mengenai pengelolaan software development berdasarkan teori
dari jaman kuda yang tidak manusiawi dan sudah tidak relevan lagi di abad 21.
1. Software Developer = Resource
Di
setiap training yang saya jalankan, selalu ada saja yang
mengkorelasikan software developer sebagai resource.
“Pak, bagaimana apabila resource kami terbatas? Apakah Scrum … ?”
Pertanyaan seperti
itu selalu langsung saya potong karena resource yang dikorelasikan dengan software
developer sangat mengganggu kuping saya. Menurut kamus bahasa inggris, arti
dari kata resource adalah:
resource
(n). a
place or thing that provides something useful and can be used whenever it is
needed.
Sayangnya manusia
bukanlah a
thing (benda) yang bisa
dimanfaatkan sewaktu-waktu bila dibutuhkan. Manusia memiliki pemikiran dan
perasaan.
Apa itu manajemen?
Banyak teori
manajemen yang dianut di Indonesia didasari oleh teoriScientific Management,
yang berkembang di sekitar tahun 1910-an. Teori ini berkembang dari lingkungan
produksi di pabrik. Oleh karena itu teori ini lebih banyak menekankan pada
efisiensi dan produktifitas karyawan pabrik. Teori ini sangat menekankan posisi
manajer yang bertugas untuk mengatur karyawan pabrik (labor). Peran manajer dipandang sebagai peran
yang sangat penting oleh karena itu manajer haruslah orang-orang yang pintar.
Tapi sayangnya Scientific Management ini tidak relevan di industri software development di abad 21.
“Manager’s responsibility is not to make
people work, but to make it possible for people to do their work.”
Sifat pekerjaan
dalam lini development tentunya sangat berbeda dengan lini
produksi di pabrik. Programmer bukanlah buruh yang menulis kode seperti buruh
pabrik. Hal ini dikarenakan kode yang ditulis oleh programmer sifatnya tidak
selalu sama dan algoritma yang ditulis oleh programmer memerlukan tingkat
kecerdasan yang tinggi. Paradigma dimana software developer adalah resource didasari oleh pemikiran kalau
software developer adalah spare part yang dapat digantikan. Pola pikir tersebut membuat
banyak perusahaan di Indonesia menekan biaya software developer serendah
mungkin karena software developer hanya dipandang sebagai spare part (resource).
People are NOT Resource
Dalam ilmu
akuntansi, resource atau sumber daya seperti mesin
fotokopi, komputer, alat tulis, kendaraan kantor maupun gedung dilihat sebagaiexpense dikarenakan seiring dengan
waktu resource ini akan mengalami penyusutan atau
depresiasi nilai. Buruh-buruh pabrik pun di dalam pembukuan akuntansi dianggap
sebagai expense. Karena buruh dipandang sebagai expense, di banyak perusahaan di Indonesia,
software developer pun dilihat sebagai expense. Software developer diperlakukan sebagai
“sumber daya” yang harus digunakan semaksimal mungkin daripada diperlakukan
seperti manusia yang potensinya perlu dikembangkan.
Cara berpikir bahwa
software developer adalah resource dan expense ini memiliki kejanggalan karena
software developer sebenarnya adalah sebuahcapital investment untuk perusahaan. Software developer tidak
akan mengalami penyusutan, namun sebaliknya seiring dengan waktu mereka akan
menjadi semakin pintar karena mereka adalah mereka adalahknowledge
worker yang menggunakan otaknya untuk bekerja bukan ototnya. Ilmu yang ada
di dalam kepala software developer tidak akan usang, kecuali mereka tidak mau
terus menerus belajar dan up-to-date dengan perkembangan jaman lagi. Dan bila mereka semakin
pintar, maka software yang mereka kembangkan akan semakin berkualitas tinggi.
Software developer
bukanlah resource yang perlu dimanage. When software developers are
over-managed, they will under-manage themselves. Mereka adalah manusia. Mereka
adalah knowledge worker. Mereka adalah capital investmentdimana capital utama mereka adalah pengetahuan.
2. Software development = pekerjaan prediktif
Chaos
theory adalah sebuah bidang ilmu yang mempelajari sebuah dinamika sistem
yang sangat sensitif terhadap keadaan di awal yang menyebabkan keadaan di akhir
tidak dapat diprediksi. Lorenz system adalah salah satu contoh dari
chaotic system dan sebagai kontras gravitasi dapat dikatakan sebagai sebuah
sistem yang memiliki tingkat kepastian yang tinggi.
Adik saya yang
sekarang masih duduk di bangku SMA saat ini bekerja paruh waktu di sebuah rumah
makan saji cepat yang makanan utamanya adalah burger. Salah satu kebiasaan dari
rumah makan saji cepat ini adalah mencari tenaga kerja yang masih duduk di bangku
SMA dikarenakan gaji harian seseorang yang masih duduk di bangku SMA jauh lebih
murah dibandingkan seseorang yang sudah berkeluarga. Hal ini tidaklah aneh dan
bisa diterima oleh akal sehat karena proses untuk membuat burger sifatnya
repetitif dan tidak rumit, bahkan seseorang yang masih duduk di bangku SMA pun
dapat diberi pelatihan singkat mengenai pembuatan burger kurang dari sehari.
Kalau proses mengembangkan software sama dengan proses membuat burger, mungkin
cara berpikir bahwa pengembangan software adalah pekerjaan prediktif dapat
diterima.
Sayangnya pekerjaan
mengembangkan software bukanlah pekerjaan prediktif seperti membuat burger
karena software developer tidak pernah membuat software yang sama lebih dari
satu kali. Mengembangkan software bukanlah sebuah proses produksi. Bila kita
ambil contoh industri otomotif, kita dapat melihat disana ada sebuah divisi
R&D (Research & Development) dan ada bagian factory yang bertugas memproduksi mobil yang
didisain oleh divisi R&D. Keahlian orang-orang yang berada di divisi
R&D berbeda dengan orang-orang yang berada di factory. Orang-orang yang berada di divisi R&D
berisi para inovator yang kreatif berbeda dengan orang-orang yang ada di
factory yang cukup mengikuti prosedur standard. Para inovator di divisi R&D
tidak pernah mendisain mobil yang sama lebih dari satu kali namun orang-orang
yang bekerja di lini produksi dapat membuat tipe mobil yang sama berkali-kali
dalam sehari. Bila kita ingin menghubungkan sifat pekerjaan software
development, maka lebih cocok untuk dihubungkan dengan divisi R&D daripada
dengan lini produksi di pabrik. Software developer adalah inovator, bukan buruh
pabrik.
Namun sangat
disayangkan sekali banyak manajer proyek yang masih menganggap kalau tipe
pekerjaan di software development adalah pekerjaan yang dapat diprediksi dari
awal seperti pekerjaan membuat burger. Manajer proyek akan berusaha semaksimal
mungkin untuk membuat work breakdown structure (WBS) yang mendekati
sempurna supaya proyeknya tidak gagal. Dan ketika proyeknya gagal, di proyek
berikutnya mereka akan berusaha untuk menghabiskan lebih banyak waktu untuk
membuat WBS-nya semakin mendekati sempurna lagi dan kalau perlu kali ini
tambahkan buffer. Cara berpikir seperti ini sangat tidak
relevan di software development karena kebanyakan teori manajemen proyek yang
dianut manajer proyek banyak dilandaskan oleh teori manajemen proyek konstruksi
yang sifatnya memang cenderung prediktif. Proses konstruksi bangunan yang
banyak menggunakan teori teknik sipil dan teori fisika membuatnya cenderung
prediktif. Kalau saja mengembangkan software didasari oleh rumus-rumus fisika,
mungkin kita bisa menggunakan WBS dan kita tidak perlu memiliki software
developer yang cerdas, cukup yang sekelas kuli bangunan saja. Andaikan saja
manajer proyek ini memiliki kerendahan hati untuk mengakui kalau ilmu manajemen
proyek mereka tidak relevan di software development, mungkin lebih banyak
software developer saat ini yang bahagia dan tidak menyesali kenapa dirinya
adalah seorang software developer.
“Coercing people into commitments that
didn’t come out of their mouth then blaming them for not meeting those
commitments is an abuse.”
Mitos ini semakin
diperparah oleh salesman yang memberikan janji palsu kepada klien hanya agar
dia mendapatkan proyek dari kostumernya. Si salesman akan mendapatkan bonus
dari perusahaan karena sudah menggolkan proyek, sedangkan software developer
harus menderita karenadeadline yang dijanjikan oleh salesman kepada
kostumer sering kali tidak masuk akal. Bukankah ini adalah proses pemanipulasian
yang sangat kejam? Banyak salesman di perusahaan software yang berpikir kalau
membuat software sama seperti membuat mi instan goreng telur. Dan jangan
salahkan bila software yang dikembangkan oleh software developer menjadi
berkualitas rendah.
“Software developers don’t work effectively
when they’re pushed into a no-win situation.”
Untuk tipe
pekerjaan yang memiliki banyak ketidakpastian seperti software development,
metode empiris lebih tepat untuk digunakan. Manajer proyek yang
mengira kalau tipe pekerjaan software development sifatnya prediktif
kemungkinan tidak pernah terlibat atau sudah lama tidak terlibat dalam software
development atau memang timnya mengembangkan software sederhana dengan
teknologi sederhana yang jumlah penggunanya hanya satu orang.
3. Sukses = On-Time, On-Budget dan On-Scope
Di awal tahun ini,
dalam sebuah perjalanan pulang dari outing kantor dimana saya pada waktu itu
menjadi trainer untuk tim di perusahaan tersebut, menuju Jakarta salah seorang
dari peserta outing mendapatkan sebuah pesan singkat dari atasannya yang isinya
kira-kira adalah:
“Jangan lupa ya
John, target kita tahun ini adalah Always On”.
Pemikiran yang
menekankan kalau sukses adalah On-Time, On-Budget dan On-Scope berasal dari
teori manajemen proyek tradisional. Tiga kriteria sukses ini seringkali disebut
dengan Project Management Iron Triangle. Kalau tipe proyek atau tipe
pekerjaan yang dilakukan adalah prediktif seperti membuat burger maka pemikiran
ini dapat diterima oleh akal sehat. Namun mengembangkan software tidak sama
dengan membangun sebuah mall.
Solusinya adalah lembur
Di banyak
perusahaan di Indonesia, overtime sering kali dijadikan solusi agar software
yang telah dijanjikan oleh pihak manajemen ke kostumer bisa selesai tepat
waktu. Seolah-olah kalau software yang sedang dikembangkan tersebut tidak
selesai tepat waktu maka dunia akan kiamat. Namun dilihat dari sisi manapun
juga, lembur sangatlah tidak efektif.
“Overtime” will always be followed by an equal period of
“undertime” where people trying to catch up with their lives.
Setiap jam software
developer lembur, setiap jam juga mereka akan kehilangan waktu dengan keluarga
dan teman-temannya. Semakin banyak mereka lembur, semakin mereka tidak memiliki
kehidupan. Lembur adalah sebuah solusi jangka pendek namun dampak jangka
panjangnya lebih menyakitkan.
Kualitas tidak penting
Berdasarkan kamus
perusahaan, definisi dari lembur adalah penambahan waktu untuk
meningkatkan kuantitas pekerjaan bukan untuk meningkatkankualitas software yang sedang dikembangkan. Bagi
manajemen, men-deliversoftware lebih cepat walaupun dengan kualitas
yang rendah itu lebih penting karena mereka beranggapan bahwa nantinya masih
ada waktu di Post
Implementation Review (PIR) atau User
Acceptance Test (UAT) untuk memperbaiki software. Namun liciknya adalah manajemen akan tetap
melaporkan kepada stakeholder dan kostumer kalau proyeknya sudah diselesaikan
dengan sukses karena mereka sudah memenuhi kriteria on-time, on-scope dan
on-budget, walaupun dengan kualitas rendah.
Menganggap bahwa
software berkualitas rendah yang diselesaikan sesuai waktu, ruang lingkup
pekerjaan dan dana yang ditetapkan sebagai sebuah kriteria kesuksesan bagaikan
sebuah ilusi. Software development adalah sebuah seni, menulis kode yang bagus
memerlukan kehati-hatian ekstra dan waktu yang relatif lebih lama dibandingkan
menulis kode serabutan. Kode yang berkualitas rendah akan semakin memperlambat
penambahan fitur baru dan semakin meningkatkan biaya untuk maintenance software
di jangka panjang. Saya sudah sering melihat software developer yang
mengundurkan diri dari sebuah perusahaan karena software yang ia kelola
berkualitas rendah.
4. Produktifitas = kuantitas waktu bekerja
“Kualitas waktu tinggi = kualitas software tinggi”
Dalam dunia
software development, waktu untuk berpikir/melamun adalah sesuatu yang sangat
penting karena software berkualitas dibuat olehknowledge worker yang menggunakan otaknya bukan
ototnya. Di mayoritas perusahaan di Indonesia, seorang software developer
dikatakan produktif apabila ia duduk dan mengetik kode dalam jangka waktu yang
lama. Bahkan ada perusahaan di Indonesia yang mengukur produktifitas programmer
berdasarkan jumlah baris kode yang ditulis oleh programmer dalam sehari. Bila
software developer sedang melamun atau sedang jalan-jalan di taman, maka mereka
dianggap tidak bekerja dan merugikan perusahaan. Bagaimana apabila pada saat
mereka melamun mereka sedang memikirkan sebuah algoritma yang dapat membuat
kode menjadi lebih efisien dan bersih (clean code)? Bagaimana apabila lamunan tersebut menghasilkan pemikiran
yang membuat user
experience software
menjadi semakin bagus? Software developer itu bagaikan seorang seniman lukis,
ketika mereka sedang melamun mereka sebenarnya sedang produktif.
Interupsi tiada henti
Wired-in adalah sebuah keadaan dimana
software developer terhubung ke kode yang sedang mereka tulis sama seperti saat
seseorang melakukan meditasi tanpa menyadari apa yang telah terjadi di
sekitarnya dan berapa banyak waktu yang terlalu ketika ia sedang menulis kode
tersebut. Kalau anda adalah seorang software developer, tentunya anda tahu apa
yang sedang saya maksud.
“For knowledge workers like software developer, being in the
flow is important because only when they are in the flow their work goes well.”
Namun sayangnya
berdasarkan pengamatan, software developer sering kali mendapatkan interupsi
yang terlalu banyak sehingga menyebabkan kualitas waktu yang mereka miliki
selama mereka berada di kantor sangat rendah. Jumlah waktu yang habis dalam
satu hari karena jumlah meeting dan teleconference yang harus mereka hadiri
lebih banyak dari jumlah waktu yang mereka dedikasikan untuk menulis kode.
Belum lagi ditambah interupsi tidak penting dari atasan dan dari pengguna.
Akhirnya mereka baru bisa benar-benar berkonsentrasi penuh untuk menulis kode
yang cantik setelah jam kantor selesai. Oh iya, belum lagi ditambah beberapa
proyek yang harus dikerjakan secara paralel oleh software developer membuat
waktu berkualitas mereka menurun.
“The quality of software developer’s time is important, not
just its quantity.”
Interrupsi membuat
kualitas waktu software
developer menjadi
rendah, dan dengan keadaan tersebut perusahaan masih mengharapkan pekerjaan
untuk selesai tepat waktu? Sungguh tidak masuk akal bukan?
Manajemen gaya feodal
Sejarah mencatat
kalau pada sekitar abad 17-an Spanyol dan Inggris memiliki cara yang cukup
berbeda untuk memperkaya dirinya. Menurut sudut pandang Spanyol, kekayaan di
bumi itu berjumlah tetap, sehingga cara mereka untuk memperkaya dirinya adalah
dengan mengambil sebanyak mungkin emas dari negara yang mereka jajah dan
membawa semuanya kembali ke Spanyol. VOC dapat dikatakan juga memiliki cara
berpikir yang sama dengan penjajah Spanyol. Sedangkan Inggris berpikir kalau
teknologi dan inovasi adalah cara yang efektif untuk mereka dapat memperkaya
dirinya. Oleh karena itu pada masa itu Inggris mengalami revolusi
industrisedangkan Spanyol mengalami inflasi karena mereka memiliki terlalu
banyak emas di negaranya namun tidak cukup banyak pembeli.
Gaya manajemen di kebanyakan
perusahaan software di Indonesia menggunakan cara feodal ala penjajah Spanyol
atau VOC. Perusahaan ingin menyedot waktu yang sebanyak-banyaknya dari software
developer untuk menyelesaikan pekerjaan sebanyak-banyaknya agar perusahaan
tidak merugi sama sekali, persis dengan gaya Spanyol menjajah. Kalau pekerjaan
belum selesai tepat waktu, maka software developer harus lembur. Kalau software
developer tidak kelihatan sibuk dan kelihatan sering melamun mereka akan
diberikan proyek untuk dikerjakan secara paralel sebanyak mungkin. Lagi-lagi
ini juga ditambah oleh pemikiran kalau software developer adalah sebuah resource yang perlu dioptimalkan bukan seorang
manusia.
5. Coach — bukan peran yang dianggap penting
Often the answers to many questions are already within us. We just need the help from someone to bring them out. — Mae Jamison
Orang tidak menjadi
lebih hebat karena di-manage, tetapi karena mereka di-coaching. Paradigma software developer harus
di-manage berasal dari sudut pandang kalau software developer pada dasarnya
tidak bisa diatur, tidak dewasa dan tidak cukup kompeten untuk mengatur diri
mereka sendiri, oleh karena itu perlu ada seseorang untuk mengatur mereka.
Paradigma software developer harus di-coaching berasal dari sudut pandang kalau software developer itu baik
adanya yang memiliki potensi untuk dapat mengelola dirinya sendiri tanpa
diperintah di kemudian hari.
Competent
adults don’t need to be managed.
Karena software
developer dianggap tidak kompeten maka mereka perlu dimanage bagaikan bidak
catur oleh orang lain yang dianggap lebih pintar, dalam hal ini manajer proyek
dan kadang ditambah beberapa lapisan lagi seperti Technical Leader, System Analyst, Solution
Architect dan Business Analyst. Cara berpikir seperti ini secara tidak
langsung membuat software developer berada pada hirarki paling bawah struktur
organisasi sama seperti kuli bangunan yang berada di hirarki paling bawah.
Performance appraisal tahunan manipulatif
Rather than have a yearly performance
evaluation, how about making course correcting info available all year long?
Ritual tahunan yang
dilakukan oleh perusahaan yang bernama performance appraisal diharapkan dapat memotivasi software
developer di tahun berikutnya. Namun ini sebenarnya adalah tipu muslihat yang
sebenarnya bertujuan untuk memanipulasi motivasi software developer karena
sifatperformance
appraisal yang men-judge kinerja software developer selama
satu tahun ke belakang. Men-judge software developer dianggap lebih
penting daripada memberikan coaching terus menerus yang dapat memperbesar
kapasitas dan kapabilitas software developer. Yang lebih parah lagi kalau
kriteria kinerja tinggi software developer yang digunakan pada saat performance
appraisal adalah iron triangle — on-time, on-budget dan on-scope — yang
tidak masuk akal itu. HRD adalah salah satu pihak yang diharapkan untuk dapat
memberikan coaching kepada software developer mengingat banyak dari mereka yang
memiliki latar belakang psikologi, namun berapa banyak dari HRD yang paham
mengenai Agile Coaching dan memberikan coaching secara aktif kepada software
developer di Indonesia? Hampir tidak ada.
“Leadership is the process of creating an
environment in which people become empowered.”
Perusahaan sering
kali bermimpi untuk mendapatkan software developer yang mature dan self-organising, namun pada saat yang bersamaan perusahaan tidak menempatkan
investasi yang cukup untuk sebuah peran yang bertugas untuk mendewasakan
software developer. Perusahaan berharap ada sebuah mukjizat dari surga yang
dapat mendewasakan software developer dalam sekejap. Walaupun peran seperti
Agile Coach danScrum Master sudah dirasakan manfaatnya dan dianggap
penting di belahan dunia lain, tetapi peran ini belum dianggap penting sama
sekali di Indonesia. Kenapa demikian? Karena seorang Agile Coach atau Scrum
Master dilihat sebagai seseorang yang lemah dan tidak memiliki otoritas. Orang
Indonesia ingin memerintah orang lain, karena hanya dengan demikian ia
dipandang sebagai seseorang pemimpin yang hebat dan memiliki otoritas. Top-downapproach gaya penjajah lebih digemari oleh
perusahaan-perusahaan di Indonesia daripada bottom-up approach yang memaksimalkan collective intelligence.
Top
down solutions ignore the knowledge & wisdom that exists throughout an
organization.
Seseorang tidak
secara otomatis menjadi dewasa, bahkan sampai saat ini pun saya masih memiliki
mentor pribadi yang secara terus menurus membantu saya dalam karir saya.
Kepemimpinan bukanlah mengenai mengambil semaksimal mungkin dari orang-orang di
perusahaan kita namun justru mengenai pelayanan terhadap orang-orang kita.
Software developer pada dasarnya adalah orang-orang yang cerdas. Orang cerdas
perlu di-coaching agar potensi yang ada di dalam diri
mereka dapat dikeluarkan. Bottom up approach dengan model Scrum lebih tepat
untuk lingkungan software development yang berisi banyak knowledge worker.
Apabila anda adalah
seorang software developer yang menginginkan agar HRD, atasan, manajer proyek,
analis bisnis, user, kostumer, sales, marketing memahami bahwa
apa yang anda kerjakan sebagai software developer itu kompleks silahkan
sebarkan artikel ini. Kalau anda ingin memperbaiki ekosistem software
development di Indonesia dan menyelamatkan lebih banyak lagi software developer
yang saat ini sedang di-abuse dengan manajemen gaya feodal, silahkan
sebarkan artikel ini. Silahkan retweet, share, like, reblog, recommend, repath,
sebar ke milis kantor, sebar ke forum diskusi tanpa harus meminta ijin terlebih
dahulu dari saya.
Ini adalah
peperangan melawan cara berpikir feodal di dalam industri software development
di Indonesia yang sudah mencapai tingkat akut. Mari kita bersama
memanusiawikan software developer di Indonesia. Bila semakin banyak
orang Indonesia yang teredukasi mengenai proses kerja software development yang
seharusnya dan bisa keluar dari cara berpikir kuno yang tidak bisa dibuktikan
secara ilmiah, maka ekosistem software development di Indonesia akan semakin
sehat dan semakin banyak software developer yang menjadi lebih bahagia dan
tidak perlu merenungi nasib kenapa dirinya adalah seorang software developer.
Sumber : medium.com
Post A Comment
No comments :