Saya juga pernah berkontribusi pada sisi manajemen memori di kernel Linux, dan merasa punya pemahaman tertentu tentang cara kerja level rendah, tetapi kalau dipikir-pikir pada akhirnya saya justru bekerja di bidang yang tanpa saya inginkan cukup jauh dari pengembangan, jadi saya merasa untuk menjadi insinyur yang sukses justru harus bertindak kebalikan dari tulisan ini.
Cepat mengikuti teknologi baru
Memikirkan pasar daripada rasa ingin tahu pribadi
Lebih pandai membungkus diri daripada mengkritik diri sendiri
Berfokus pada tes coding daripada prinsip/pertumbuhan
Setelah kembali, saya merasa pasar di Korea terlalu kecil dan persaingannya terlalu ketat, sehingga hanya ada sedikit perusahaan atau posisi yang memungkinkan seseorang fokus pada pengembangan; dan karena semua orang berebut tempat yang sedikit itu, pada akhirnya tampaknya Anda harus fokus pada hal-hal yang mudah terlihat agar bisa melakukan pengembangan yang benar-benar ingin Anda kerjakan.
"Kita tidak membutuhkan siswa A+ yang bisa menjawab semua pertanyaan
Yang kita inginkan adalah siswa B yang bisa melihat dan mengajukan pertanyaan tentang hal-hal yang terlewat oleh orang lain"
Melihat ini, saya langsung merasa bahwa sayalah siswa B itu, tetapi perusahaan besar hanya melihat siswa A+ saat merekrut.
Beberapa waktu lalu, saya pernah mengadakan seminar di perusahaan untuk studi bahasa Kotlin. Saat saya menjelaskannya dengan membandingkannya dengan bahasa C++ yang paling sering digunakan di divisi, saya ingat responsnya cukup bagus. Padahal saya sendiri hampir tidak pernah memakai C++, dan anggota divisi juga baru pertama kali mengenal Kotlin, tetapi rasanya dalam banyak hal hal itu membantu perkembangan kami semua.
Terjemahan ringkasan opini Hacker News untuk poin terakhir tampaknya keliru, yaitu "anggapan bahwa produktivitas software tidak meningkat 5–10 kali lipat mungkin salah". Jika melihat teks aslinya, ringkasan yang lebih wajar tampaknya adalah kira-kira: "mengatakan bahwa produktivitas software meningkat 5–10 kali lipat didasarkan pada asumsi yang keliru tentang peningkatan produktivitas".
Ya, saya setuju. Orangnya sendiri juga perlu lebih terlihat, dan sepertinya akan bagus kalau para giver saling sering memberi shout-out. Budaya organisasi itu sendiri juga mendorong hal tersebut.
> Sebagian besar programmer tidak tahu cara menggunakan alat LLM secara efektif atau tidak tertarik padanya
Banyak developer di sekitar saya ternyata tidak begitu tertarik pada teknologi. Mereka menghabiskan sebagian besar waktunya untuk menonton YouTube Shorts yang baru atau berulang secara mekanis.
Sepertinya tweet-nya tidak ada, entah karena versi aslinya sudah dihapus.
Saya ingin mencobanya, tetapi meskipun masih masa pratinjau, ini berbayar dan juga tidak ada masa uji coba, huhu.
Kalau dicari-cari, ada yang bilang beberapa kali kueri saja sudah menghabiskan $5, jadi sepertinya tergantung pada ukuran kode proyeknya.
Ada banyak hal menarik, baik dari sudut pandang HR maupun budaya organisasi.
Karena saya kurang paham, saya cari tahu dan ternyata backdoor reference check adalah pemeriksaan reputasi tidak resmi. Saya tinggalkan catatan ini karena mungkin ada juga yang seperti saya.
Ini tampaknya bisa menjadi salah satu metode konkret dari latihan mendalam yang dibahas dalam buku The Talent Code. Terima kasih untuk tulisan yang bagus ini.
https://id.news.hada.io/topic?id=19168
Ini riset yang rasanya AI tidak akan pernah terpikirkan.
Saya setuju dengan inti pembahasan di artikel.
Saya rasa di Korea juga ada banyak engineer yang hebat, tetapi saya juga merasa ada banyak bagian yang disayangkan karena ukuran pasarnya.
Saya jadi berpikir, seandainya tempat seperti FuriosaAI bisa berhasil dengan baik.
Saya membacanya dengan antusias dan merasa tulisan ini sangat bagus.
Wah... ada seseorang yang sangat mirip dengan isi tulisan ini, sepertinya harus saya bagikan kepadanya.
Terima kasih untuk tulisan yang bagus ini.
Saya setuju dengan itu. Saya sendiri cenderung menasihati junior agar bekerja dengan cara yang terlihat.
Agak relate juga ya.. wkwk
Mungkin memang cuma pasar Korea yang seperti itu...
Saya sangat tertarik dengan React-Native, jadi yang ini juga bikin penasaran.
Konten di atas diambil dari Lynx: Unlock Native for More, yaitu artikel perkenalan resmi.
Saya juga pernah berkontribusi pada sisi manajemen memori di kernel Linux, dan merasa punya pemahaman tertentu tentang cara kerja level rendah, tetapi kalau dipikir-pikir pada akhirnya saya justru bekerja di bidang yang tanpa saya inginkan cukup jauh dari pengembangan, jadi saya merasa untuk menjadi insinyur yang sukses justru harus bertindak kebalikan dari tulisan ini.
Setelah kembali, saya merasa pasar di Korea terlalu kecil dan persaingannya terlalu ketat, sehingga hanya ada sedikit perusahaan atau posisi yang memungkinkan seseorang fokus pada pengembangan; dan karena semua orang berebut tempat yang sedikit itu, pada akhirnya tampaknya Anda harus fokus pada hal-hal yang mudah terlihat agar bisa melakukan pengembangan yang benar-benar ingin Anda kerjakan.
"Kita tidak membutuhkan siswa A+ yang bisa menjawab semua pertanyaan
Yang kita inginkan adalah siswa B yang bisa melihat dan mengajukan pertanyaan tentang hal-hal yang terlewat oleh orang lain"
Melihat ini, saya langsung merasa bahwa sayalah siswa B itu, tetapi perusahaan besar hanya melihat siswa A+ saat merekrut.
Menurut saya, MCP bukanlah spesifikasi untuk komunikasi data sehingga tidak cocok dijadikan JSON, dan menurut saya ini juga terlalu rumit.
Beberapa waktu lalu, saya pernah mengadakan seminar di perusahaan untuk studi bahasa Kotlin. Saat saya menjelaskannya dengan membandingkannya dengan bahasa C++ yang paling sering digunakan di divisi, saya ingat responsnya cukup bagus. Padahal saya sendiri hampir tidak pernah memakai C++, dan anggota divisi juga baru pertama kali mengenal Kotlin, tetapi rasanya dalam banyak hal hal itu membantu perkembangan kami semua.
Terjemahan ringkasan opini Hacker News untuk poin terakhir tampaknya keliru, yaitu "anggapan bahwa produktivitas software tidak meningkat 5–10 kali lipat mungkin salah". Jika melihat teks aslinya, ringkasan yang lebih wajar tampaknya adalah kira-kira: "mengatakan bahwa produktivitas software meningkat 5–10 kali lipat didasarkan pada asumsi yang keliru tentang peningkatan produktivitas".
Ya, saya setuju. Orangnya sendiri juga perlu lebih terlihat, dan sepertinya akan bagus kalau para giver saling sering memberi shout-out. Budaya organisasi itu sendiri juga mendorong hal tersebut.
Terminal memang benar-benar...
> Sebagian besar programmer tidak tahu cara menggunakan alat LLM secara efektif atau tidak tertarik padanya
Banyak developer di sekitar saya ternyata tidak begitu tertarik pada teknologi. Mereka menghabiskan sebagian besar waktunya untuk menonton YouTube Shorts yang baru atau berulang secara mekanis.
Saya penasaran apakah MCP bisa menjadi JSON.
Sepertinya tweet-nya tidak ada, entah karena versi aslinya sudah dihapus.
Saya ingin mencobanya, tetapi meskipun masih masa pratinjau, ini berbayar dan juga tidak ada masa uji coba, huhu.
Kalau dicari-cari, ada yang bilang beberapa kali kueri saja sudah menghabiskan $5, jadi sepertinya tergantung pada ukuran kode proyeknya.
Ada banyak hal menarik, baik dari sudut pandang HR maupun budaya organisasi.
Karena saya kurang paham, saya cari tahu dan ternyata backdoor reference check adalah pemeriksaan reputasi tidak resmi. Saya tinggalkan catatan ini karena mungkin ada juga yang seperti saya.
Ini tampaknya bisa menjadi salah satu metode konkret dari latihan mendalam yang dibahas dalam buku The Talent Code. Terima kasih untuk tulisan yang bagus ini.