Saya sama sekali tidak terpikir bahwa ini mirip kerja kerajinan tangan, tapi saya sangat setuju.
Saat memikirkannya dari sudut pandang ini, rasanya banyak fenomena jadi bisa dijelaskan.
Saya banyak berpikir setelah membaca komentar yang kritis itu. Ada bagian yang saya setujui, dan ada juga bagian yang saya pandang berbeda.
Saat ini mungkin ada semacam gelembung pada status pengembang, tetapi menurut saya hal yang sama juga terjadi pada profesi lain. Dari sedikit menjadi banyak. Artinya, ketika jumlah pelaku bertambah dan keberagamannya meningkat, ini adalah fenomena yang wajar. Bukan berarti arah ini pasti benar, tetapi saya juga tidak melihat bahwa hal ini hanya menonjol pada pengembang saja.
Mudah dipelajari. Saya mengakuinya, tetapi hambatan masuk yang rendah tidak berarti tingkat profesionalismenya rendah. Dibandingkan dengan industri lain, terutama jabatan teknis di manufaktur, alasan mengapa bidang ini lebih mudah dipelajari bukan karena pengembangan itu sendiri mudah, melainkan mungkin karena budaya open source dan risikonya yang rendah. Seperti yang disebut sebelumnya dalam konteks keberagaman pengembang, ada pekerjaan yang bisa dilakukan setelah belajar dengan cepat, dan ada juga pekerjaan yang harus bertumpu pada keahlian profesional.
Lingkungannya telah berubah. Saya tidak berpikir alasan mengapa ekspektasi dan kompensasi terhadap pengembang di pasar lebih besar daripada masa lalu semata-mata karena kemampuan teknis, keterampilan, atau profesionalisme mereka. Semakin dalam IT masuk ke kehidupan manusia, software menjadi semakin penting dan menopang banyak infrastruktur. Bukan karena kemampuan masing-masing pengembang meningkat lalu kompensasinya menjadi besar, melainkan karena pekerjaan itu sendiri menjadi lebih mahal. Karena kini lebih penting daripada dulu.
Apakah perbandingan langsung dengan manufaktur memang bermakna? Dari sudut pandang bahwa tingkat kematangan industrinya belum cukup tinggi, pembanding itu tampaknya adalah manufaktur. Jika kita mencoba memahami industri software dengan paradigma manufaktur, ia bisa terlihat seperti kerajinan tangan atau pengembangan sebagai hobi. Namun sebaliknya, saya pikir justru aspek-aspek inilah yang membentuk budaya pengembangan software yang lentur dan kreatif, lalu menjadi pijakan bagi pertumbuhannya.
Keterlarutan yang berlebihan itu berbahaya. Saya sangat setuju. Bukan hanya pengembangan yang perlu dipelajari di dunia ini, dan sampai sekarang pun kita tetap menulis "karyawan" di kolom pekerjaan. Hanya karena suasana sosial sedang dipenuhi gelembung, kita perlu berhati-hati agar tidak menganggap profesi ini sangat berbeda dari pekerjaan lain. Namun, ini juga berlaku untuk profesi apa pun.
Bagi Toss, UX memang berkaitan langsung dengan kelangsungan hidup.
Namun dari sisi yang berbeda dengan tulisan ini, saya tidak tahu apakah perusahaan itu pandai mengejar keuntungan.
Saya rasa jenis umpan balik seperti ini, tergantung pada kepribadian, budaya, dan perbedaan masing-masing individu, bisa terasa tidak enak didengar atau bahkan memicu kemarahan. Namun pada dasarnya, menurut saya akan lebih baik jika kita mendekatinya dengan asumsi bahwa "orang ini tidak sengaja menyiksa saya", baik dari sisi mental maupun dari sudut pandang pertumbuhan. Saat menghadapi situasi seperti itu, rasanya kita bisa mengingat tulisan ini dan berpikir, "mungkin manajer ini juga begitu?" Tulisan yang bagus.
Kalau ada yang membetulkan salah eja, cukup bilang terima kasih, saya tidak tahu; rasanya itu bukan hal yang pantas dijadikan bahan untuk marah. Menurut saya, menganggap bahwa orang lain pasti akan merasakan hal yang sama seperti yang kita rasakan adalah generalisasi yang berbahaya. Dan juga, yang benar bukan "menerima dan melakukan", melainkan "menerimanya".
Saat melihat adopsi AI, mestinya ini dipandang dari sisi perluasan cara berpikir, bukan kecepatan pengembangan, tetapi tampaknya masih ada manajer yang terus-menerus bicara soal kecepatan. Jika melihat produk-produk yang mengusung AI, kebanyakan tidak terlalu istimewa dan sesekali hanya sampai tahap validasi pasar; apakah mereka lalu menyamakan tingkat produk yang mereka buat dengan itu?
Dari sudut pandang pengguna yang telah memakai XE1 sejak masa awal hingga Rhymix selama belasan tahun, ini adalah isi yang sangat mudah saya pahami.
Menurut saya, masalah terbesar adalah bahwa sebagian besar pasar yang ditargetkan Rhymix tidak cukup memiliki kemampuan untuk mengembangkan sendiri secara langsung.
Orang-orang yang memang mampu mengembangkan sendiri biasanya lebih memilih mengadopsi Laravel dan semacamnya, daripada harus menoleransi dokumentasi XE atau Rhymix yang kurang memadai, struktur yang ambigu, dan berbagai hal legacy.
Sama seperti penulis artikel asli, saya juga
halaman admin yang terasa familier bagi banyak orang
fitur-fitur sebagai CMS yang meski ada kekurangan kecil, tetap tidak terasa kurang
tim pengembang inti yang aktif mengakomodasi usulan-usulan baru
rasa kedekatan karena sudah lama menggunakannya
Dan sebagainya, sehingga saya pun mengadopsi Rhymix di beberapa proyek baru, tetapi setiap kali saya tetap banyak berpikir apakah pilihan ini benar-benar pilihan yang tepat.
Saya pribadi juga sedang mencoba berbagai pendekatan untuk melengkapi bagian-bagian yang terasa kurang saat menggunakan Rhymix sebagai pengganti framework. https://github.com/nemorize/rx-make (branch develop / proyek PoC, tidak direncanakan untuk produksi)
Saya mencoba berbagai hal, seperti menjadikan Rhymix secara utuh sebagai framework/library, meminimalkan akses ke API legacy, dan membangun ulang API yang lebih modern dengan kompatibilitas yang kira-kira tetap terjaga dengan versi legacy, tetapi... ini benar-benar membuat saya sangat banyak berpikir haha..
Saya belum pernah merapikan kegelisahan ini dengan jelas, jadi saya rasa ini kesempatan yang bagus untuk sekali mencoba menyusunnya dengan lebih terang.
Bagi Toss, diferensiasi UX secara langsung berarti pendapatan dan kelangsungan hidup.
Jika mereka puas pada tingkat yang mirip dengan bank umum atau aplikasi fintech arus utama, itu tidak akan bisa disebut sukses.
Kecuali bagian di bawah ini:
“Cara mengejar stabilitas sambil mengerjakan hal yang bermakna
Jika pekerjaan yang ingin Anda lakukan tidak berhubungan langsung dengan profitabilitas, penting untuk bekerja di perusahaan besar yang sangat menguntungkan
Di perusahaan kecil dengan laba rendah, pekerjaan berbasis nilai lebih mudah menjadi sasaran restrukturisasi”
Bagi saya, ini terlihat lebih meyakinkan.
“Begitu perusahaan mencapai skala tertentu, menghasilkan uang menjadi konstruksi sosial. Tulisan "how to get promoted" lebih baik menjelaskan realitas organisasi besar”
Bukankah itu karena rasio konversi Toss berujung pada kinerja? Lagi pula, perusahaan itu juga belum go public, jadi untuk saat ini, selama hanya berkontribusi pada pertumbuhan, meski tidak langsung terkait dengan pendapatan pun tidak masalah.
Jadi itulah mengapa di tengah artikel dikatakan untuk melihat bagaimana perusahaan menghasilkan uang.
Kita tidak boleh menyerahkan otak kita kepada AI, tetapi tampaknya ada kecenderungan untuk percaya seolah-olah AI bisa menggantikan semua proses berpikir kita.
Memang tidak semuanya, tetapi sebagian besar adalah poin-poin yang terasa relevan.
Saya sama sekali tidak terpikir bahwa ini mirip kerja kerajinan tangan, tapi saya sangat setuju.
Saat memikirkannya dari sudut pandang ini, rasanya banyak fenomena jadi bisa dijelaskan.
Hyperlight WASM: cepat, aman, dan tanpa OS - Manajer Mesin Virtual Ringan (VMM) | GeekNews
Hyperlight WASM: cepat, aman, dan bebas OS | GeekNews
Saya banyak berpikir setelah membaca komentar yang kritis itu. Ada bagian yang saya setujui, dan ada juga bagian yang saya pandang berbeda.
Bagi Toss, UX memang berkaitan langsung dengan kelangsungan hidup.
Namun dari sisi yang berbeda dengan tulisan ini, saya tidak tahu apakah perusahaan itu pandai mengejar keuntungan.
Selamat ulang tahun. Dengarkan baik-baik kata-kata orang tua dan semoga panjang umur serta selalu sehat.
Saya rasa jenis umpan balik seperti ini, tergantung pada kepribadian, budaya, dan perbedaan masing-masing individu, bisa terasa tidak enak didengar atau bahkan memicu kemarahan. Namun pada dasarnya, menurut saya akan lebih baik jika kita mendekatinya dengan asumsi bahwa "orang ini tidak sengaja menyiksa saya", baik dari sisi mental maupun dari sudut pandang pertumbuhan. Saat menghadapi situasi seperti itu, rasanya kita bisa mengingat tulisan ini dan berpikir, "mungkin manajer ini juga begitu?" Tulisan yang bagus.
Kalau ada yang membetulkan salah eja, cukup bilang terima kasih, saya tidak tahu; rasanya itu bukan hal yang pantas dijadikan bahan untuk marah. Menurut saya, menganggap bahwa orang lain pasti akan merasakan hal yang sama seperti yang kita rasakan adalah generalisasi yang berbahaya. Dan juga, yang benar bukan "menerima dan melakukan", melainkan "menerimanya".
Saat melihat adopsi AI, mestinya ini dipandang dari sisi perluasan cara berpikir, bukan kecepatan pengembangan, tetapi tampaknya masih ada manajer yang terus-menerus bicara soal kecepatan. Jika melihat produk-produk yang mengusung AI, kebanyakan tidak terlalu istimewa dan sesekali hanya sampai tahap validasi pasar; apakah mereka lalu menyamakan tingkat produk yang mereka buat dengan itu?
Rasanya seperti tangan kanan CTO.
Selamat ulang tahun ^^
Wow.. ini cukup signifikan, ya? Urusan terkait pajak juga akan jadi jauh lebih mudah, dan akurasi statistik pun akan meningkat.
Dari sudut pandang pengguna yang telah memakai XE1 sejak masa awal hingga Rhymix selama belasan tahun, ini adalah isi yang sangat mudah saya pahami.
Menurut saya, masalah terbesar adalah bahwa sebagian besar pasar yang ditargetkan Rhymix tidak cukup memiliki kemampuan untuk mengembangkan sendiri secara langsung.
Orang-orang yang memang mampu mengembangkan sendiri biasanya lebih memilih mengadopsi Laravel dan semacamnya, daripada harus menoleransi dokumentasi XE atau Rhymix yang kurang memadai, struktur yang ambigu, dan berbagai hal legacy.
Sama seperti penulis artikel asli, saya juga
Dan sebagainya, sehingga saya pun mengadopsi Rhymix di beberapa proyek baru, tetapi setiap kali saya tetap banyak berpikir apakah pilihan ini benar-benar pilihan yang tepat.
Saya pribadi juga sedang mencoba berbagai pendekatan untuk melengkapi bagian-bagian yang terasa kurang saat menggunakan Rhymix sebagai pengganti framework.
https://github.com/nemorize/rx-make (branch develop / proyek PoC, tidak direncanakan untuk produksi)
Saya mencoba berbagai hal, seperti menjadikan Rhymix secara utuh sebagai framework/library, meminimalkan akses ke API legacy, dan membangun ulang API yang lebih modern dengan kompatibilitas yang kira-kira tetap terjaga dengan versi legacy, tetapi... ini benar-benar membuat saya sangat banyak berpikir haha..
Saya belum pernah merapikan kegelisahan ini dengan jelas, jadi saya rasa ini kesempatan yang bagus untuk sekali mencoba menyusunnya dengan lebih terang.
Bagi Toss, diferensiasi UX secara langsung berarti pendapatan dan kelangsungan hidup.
Jika mereka puas pada tingkat yang mirip dengan bank umum atau aplikasi fintech arus utama, itu tidak akan bisa disebut sukses.
Kecuali bagian di bawah ini:
“Cara mengejar stabilitas sambil mengerjakan hal yang bermakna
Jika pekerjaan yang ingin Anda lakukan tidak berhubungan langsung dengan profitabilitas, penting untuk bekerja di perusahaan besar yang sangat menguntungkan
Di perusahaan kecil dengan laba rendah, pekerjaan berbasis nilai lebih mudah menjadi sasaran restrukturisasi”
Bagi saya, ini terlihat lebih meyakinkan.
“Begitu perusahaan mencapai skala tertentu, menghasilkan uang menjadi konstruksi sosial. Tulisan "how to get promoted" lebih baik menjelaskan realitas organisasi besar”
Bukankah itu karena rasio konversi Toss berujung pada kinerja? Lagi pula, perusahaan itu juga belum go public, jadi untuk saat ini, selama hanya berkontribusi pada pertumbuhan, meski tidak langsung terkait dengan pendapatan pun tidak masalah.
Jadi itulah mengapa di tengah artikel dikatakan untuk melihat bagaimana perusahaan menghasilkan uang.
Kita tidak boleh menyerahkan otak kita kepada AI, tetapi tampaknya ada kecenderungan untuk percaya seolah-olah AI bisa menggantikan semua proses berpikir kita.
Ini postingan yang anehnya bikin semangat ya.
Saya sempat berpikir bagaimana ini bisa diterapkan, tetapi bahkan hanya menggunakan
sortataudropsaja sudah cukup bermakna.