Seperti yang dikatakan dalam tulisan ini, kemampuan untuk melakukan "dokumentasi" memang sangat penting.
Kemampuan ini tidak hanya berguna untuk menonjolkan kekuatan diri dan menyampaikan pencapaian, tetapi juga membantu mempermudah pekerjaan dan memberi arahan kepada orang lain.
Tidak perlu langsung membuat materi atau dokumen yang keren sejak awal. Meski sederhana, yang penting adalah membiasakan diri untuk merapikan dan menuliskannya dalam bentuk dokumen.
Saya sendiri paham ini secara teori, tetapi belum terlalu bisa mempraktikkannya... Ini benar-benar topik yang sulit.
Saya mungkin tidak tahu sampai ke fondasi yang sangat dalam, tetapi saya pernah melihat bahwa ketika tidak memahami dasar-dasarnya, orang bisa menghasilkan hal yang benar-benar absurd dan sama sekali sulit dibayangkan.
Contohnya, mengimplementasikan pencarian dengan memasukkan semua record di DB ke memori terlebih dahulu lalu mencari di memori.
Saat record masih sedikit, semuanya berjalan baik, tetapi ketika record bertambah banyak, memori pun jebol.
Mereka menulisnya seperti ini karena sama sekali tidak memahami perbedaan antara memori dan DB.
Ini hanya salah satu contoh, dan setiap kali mereka mengimplementasikannya ke arah yang benar-benar tak terbayangkan.
Programmer biasa(?) benar-benar tidak bisa membayangkannya.
Saya juga setuju dengan tulisan ini
Saya melihat bahwa mendefinisikan masalah dengan nilai-nilai keadaan yang sudah diabstraksikan itu berguna untuk menemukan masalah, dan saya sedang mencoba membuat alat manajemen keadaan yang jelas secara visual dan eksplisit, seperti visualisasi keadaan dengan diagram, Unreal Blueprint, atau workflow.
Sepertinya saya perlu melihat bahasanya terlebih dahulu
Bagaimanapun, praktik kerja software engineering akan banyak berubah. Para "mesin pembuat kode" akan kehilangan daya saing, tetapi saya bertaruh bahwa para engineer yang benar-benar bisa membangun produk secara end-to-end akan tetap bertahan.
Saya pernah mengerjakan pekerjaan pengembangan, lalu sempat beberapa tahun mencoba pekerjaan perencanaan, dan pesan bahwa kita harus bisa "menjual (Sell)" dalam artikel ini benar-benar terasa mengena.
Sehebat apa pun produk yang sudah dipersiapkan dan direncanakan dengan sangat keras, jika kita tidak bisa meyakinkan dan menjualnya secara efektif kepada rekan-rekan di sekitar, kita tidak akan mendapatkan dukungan,
dan pada akhirnya tugas tersebut tidak akan bisa berjalan maju dengan lancar.
Jika ada ide yang kita pikirkan, saya belajar bahwa aktivitas seperti menyampaikannya secara efektif kepada orang-orang di sekitar untuk mendapatkan dukungan juga merupakan hal yang esensial.
Aduh huhu ini akan saya perbaiki nanti.
Kalau begitu, apakah
<selectlist>jadi tidak diperlukan lagi?Show GN: Game web battle/peringkat pengaturan karakter
Ngomong-ngomong, judul
<select>ternyata tidak ditampilkan di Slackbot, hahaKemarin waktu lihat saya tidak sadar, ternyata ini punya Microsoft, waduh, harus saya coba.
Sepertinya para blogger yang memprediksi fitur baru sambil memantau commit-commit baru bakal kecewa.
Saya paham..!
Seperti yang dikatakan dalam tulisan ini, kemampuan untuk melakukan "dokumentasi" memang sangat penting.
Kemampuan ini tidak hanya berguna untuk menonjolkan kekuatan diri dan menyampaikan pencapaian, tetapi juga membantu mempermudah pekerjaan dan memberi arahan kepada orang lain.
Tidak perlu langsung membuat materi atau dokumen yang keren sejak awal. Meski sederhana, yang penting adalah membiasakan diri untuk merapikan dan menuliskannya dalam bentuk dokumen.
Saya sendiri paham ini secara teori, tetapi belum terlalu bisa mempraktikkannya... Ini benar-benar topik yang sulit.
Saya mungkin tidak tahu sampai ke fondasi yang sangat dalam, tetapi saya pernah melihat bahwa ketika tidak memahami dasar-dasarnya, orang bisa menghasilkan hal yang benar-benar absurd dan sama sekali sulit dibayangkan.
Contohnya, mengimplementasikan pencarian dengan memasukkan semua record di DB ke memori terlebih dahulu lalu mencari di memori.
Saat record masih sedikit, semuanya berjalan baik, tetapi ketika record bertambah banyak, memori pun jebol.
Mereka menulisnya seperti ini karena sama sekali tidak memahami perbedaan antara memori dan DB.
Ini hanya salah satu contoh, dan setiap kali mereka mengimplementasikannya ke arah yang benar-benar tak terbayangkan.
Programmer biasa(?) benar-benar tidak bisa membayangkannya.
https://id.news.hada.io/topic?id=4138
Ada juga yang namanya Coolify.
Saya juga setuju dengan tulisan ini
Saya melihat bahwa mendefinisikan masalah dengan nilai-nilai keadaan yang sudah diabstraksikan itu berguna untuk menemukan masalah, dan saya sedang mencoba membuat alat manajemen keadaan yang jelas secara visual dan eksplisit, seperti visualisasi keadaan dengan diagram, Unreal Blueprint, atau workflow.
Sepertinya saya perlu melihat bahasanya terlebih dahulu
Ini mengingatkan saya pada kelas mata kuliah teori komputasi! Saya merekomendasikan orang-orang yang melakukan pemrograman untuk mempelajarinya.
Bagus banget, ya? Sampai hal seperti ini pun ada versi open source-nya, hehe.
Yang lebih buruk itu lebih baik!
Bagaimanapun, praktik kerja software engineering akan banyak berubah. Para "mesin pembuat kode" akan kehilangan daya saing, tetapi saya bertaruh bahwa para engineer yang benar-benar bisa membangun produk secara end-to-end akan tetap bertahan.
Saya juga merasa OpenAPI function calling mungkin lebih baik. Membuat ulang ini dengan protokol MCP juga butuh kerja.
Saya pernah mengerjakan pekerjaan pengembangan, lalu sempat beberapa tahun mencoba pekerjaan perencanaan, dan pesan bahwa kita harus bisa "menjual (Sell)" dalam artikel ini benar-benar terasa mengena.
Sehebat apa pun produk yang sudah dipersiapkan dan direncanakan dengan sangat keras, jika kita tidak bisa meyakinkan dan menjualnya secara efektif kepada rekan-rekan di sekitar, kita tidak akan mendapatkan dukungan,
dan pada akhirnya tugas tersebut tidak akan bisa berjalan maju dengan lancar.
Jika ada ide yang kita pikirkan, saya belajar bahwa aktivitas seperti menyampaikannya secara efektif kepada orang-orang di sekitar untuk mendapatkan dukungan juga merupakan hal yang esensial.
Di era ketika Docker Desktop pun sudah memakai Kubernetes, agak disayangkan kalau hanya mendukung Docker Swarm.
> ERROR: Unsupported distribution 'manjaro'
Saya sempat ingin mencobanya. Ternyata Manjaro tidak didukung. Agak disayangkan, tetapi ya sudahlah.
Anthropic membuka Model Context Protocol sebagai open source
Cara mengembangkan Model Context Protocol (MCP)
Penjelasan perbandingan MCP dan API
Awesome MCP Servers - Daftar server yang mendukung Model Context Protocol