Ide Proyek Coding yang Mengajarkan Anda Membaca Kode Nyata

Ide Proyek Coding yang Mengajarkan Anda Membaca Kode Nyata

Sebagian besar daftar ide proyek coding memberikan aplikasi to-do kepada Anda dan berharap semoga berhasil. Proyek yang benar-benar membuat Anda dapat dipekerjakan adalah proyek di mana Anda membaca kode yang tidak Anda tulis, menemukan file yang tepat dalam waktu kurang dari sepuluh menit, dan mengubahnya tanpa merusak build. Itulah keterampilan yang diuji oleh manajer perekrutan, dan proyek sampingan dengan folder kosong jarang melatihnya.

Di bawah ini adalah ide proyek coding yang disortir berdasarkan apa yang mereka ajarkan, ditambah cara untuk memilih satu sehingga Anda menyelesaikannya alih-alih meninggalkannya di minggu ketiga.

Mengapa sebagian besar ide proyek coding mandek di minggu ketiga?

Anda memulai dengan folder kosong. 40 baris pertama terasa hebat. Kemudian aplikasi memerlukan autentikasi, skema database, dan target deploy, dan Anda menyadari bahwa Anda menghabiskan Sabtu membaca dokumen alih-alih membangun hal yang Anda bayangkan.

Tiga mode kegagalan muncul berulang-ulang:

• Ruang lingkup adalah produk, bukan proyek. "Bangun klon Netflix" adalah perusahaan. "Bangun fungsi yang memilih episode berikutnya dari riwayat tontonan" adalah proyek.

• Tidak ada pembaca. Tidak ada yang meninjau kode Anda, jadi tidak ada yang memaksa Anda membuatnya dapat dibaca.

• Proyek tidak pernah menyentuh kode yang ada. Hari pertama Anda di pekerjaan adalah 95 persen membaca. Proyek sampingan Anda adalah 95 persen menulis. Ketidaksesuaian inilah mengapa junior dengan portofolio solid masih membeku di sprint pertama mereka.

Pilihan alat penting kurang dari yang dipikirkan orang. Lewati akhir pekan yang dihabiskan membandingkan framework dan pilih yang dapat Anda jalankan "hello world" dalam waktu 20 menit.

Ide proyek coding mana yang layak mendapat waktu Anda sebagai pemula?

Pilih proyek dengan status akhir yang jelas yang dapat Anda demonstrasikan dalam satu kalimat. Berikut adalah lima yang dapat diskalakan dengan baik dari mahasiswa tahun pertama hingga pengalihan karir:

1. Pelacak pengeluaran CLI dengan ekspor CSV. Anda belajar parsing argumen, file IO, dan cara menyusun program dengan lebih dari satu modul. Kirimkan dengan README yang bisa diikuti orang asing.

2. Pemeriksa tautan untuk folder dokumen. Jelajahi direktori file markdown, ekstrak URL, laporkan yang mati. Kecil, berguna, dan mengajarkan Anda rekursi dan kode status HTTP.

3. API pribadi dengan satu sumber data nyata. Tarik data Anda sendiri (latihan, buku, komit) ke SQLite dan paparkan melalui tiga endpoint. Di sinilah Anda bertemu pagination dan penanganan error untuk pertama kalinya.

4. Alat text-diff. Bandingkan dua file dan cetak apa yang berubah. Terlihat sepele sampai Anda mencoba menangani baris yang dipindahkan, yang merupakan tempat Anda belajar mengapa algoritma Myers menjadi default di Git.

5. Bot kecil untuk alat chat yang sudah Anda gunakan. Pengingat, ringkasan standup, ping status build. Pengguna nyata (Anda) memberikan umpan balik instan.

Lewati ini kecuali Anda memiliki alasan khusus: aplikasi cuaca (setiap tutorial berakhir di sini, jadi repo Anda menghilang dalam tumpukan), daftar to-do tanpa persistensi, dan "chatbot AI" apa pun yang merupakan pembungkus tipis di sekitar panggilan API tanpa data Anda sendiri.

Proyek mana yang mengajarkan Anda cara kerja sistem nyata?

Setelah Anda dapat menyelesaikan hal-hal kecil, bangun versi miniatur dari sesuatu yang Anda gunakan setiap hari. Tujuannya bukan untuk menggantinya. Tujuannya adalah untuk mengetahui mengapa yang asli dibangun dengan cara itu.

CodeCrafters memelihara daftar dari 73 proyek build-it-yourself. Proyek-proyek yang paling menguntungkan bagi insinyur yang bekerja berbagi ciri: spesifikasi publik yang dapat Anda periksa pekerjaan Anda terhadapnya. Beberapa yang layak untuk akhir pekan Anda:

• Git Anda sendiri. Init, commit, log, dan branching menggunakan content-addressed storage. Write Yourself a Git berjalan melalui bagian dalamnya. Setelah ini, konflik merge berhenti terasa seperti cuaca.

• Key-value store. Makalah Bitcask cukup pendek untuk dibaca dalam satu duduk, dan desainnya menunjukkan kepada Anda sebagian besar dari apa yang mesin penyimpanan berdagang.

• Server HTTP dari soket mentah. Parse request line, layani file statis, kembalikan 404. Tiga ratus baris, dan Anda tidak akan pernah lagi memperlakukan web framework sebagai black box.

• Interpreter kecil. Tokenizer, parser, evaluator. Ini adalah proyek tunggal yang mengubah cara Anda membaca semua kode lain sesudahnya.

Masing-masing proyek ini memakan waktu dua hingga empat minggu, bukan dua hingga empat jam. Alokasikan waktu dengan sesuai, dan tuliskan di awal apa artinya "selesai".

Mengapa berkontribusi pada repo yang ada adalah ide proyek terbaik yang tidak ada yang cantumkan?

Karena itulah yang cocok dengan pekerjaan. Membuka repo dengan 200 file dan tanpa peta adalah pengalaman sehari-hari yang sebenarnya dari insinyur yang bekerja, dan hampir tidak ada artikel "ide proyek" yang mengirim Anda ke sana.

Mekaniknya lebih sederhana dari yang terlihat. Open Source Guide mencatat bahwa setiap proyek GitHub memiliki halaman /contribute yang mencantumkan isu-isu ramah pemula, dan ini menunjukkan bahwa 28 persen dari kontribusi kasual adalah dokumentasi: perbaikan typo, pemformatan ulang, terjemahan. Mulai dari sana. Perbaikan docs mengajarkan Anda fork, branch, siklus PR dengan hampir tanpa risiko.

Kemudian naik ke bug kecil. Berikut adalah rutinitas yang berhasil:

1. Pilih proyek yang sudah Anda gunakan, sehingga Anda tahu apa perilaku yang benar.

2. Filter isu berdasarkan "good first issue" dan baca lima sebelum memilih satu.

3. Reproduksi bug secara lokal sebelum Anda menyentuh kode apa pun.

4. Temukan titik masuk. Ini adalah bagian yang sulit, dan tempat sebagian besar orang berhenti.

5. Buat perubahan terkecil yang memperbaikinya, tambahkan tes, dan buka PR sebagai draft awal.

Langkah 4 adalah yang tidak ada yang peringatkan kepada Anda. Anda akan grep untuk string error, mendarat di file, mengikuti panggilan fungsi ke tiga file lainnya, dan kehilangan utas. Anda telah melakukan ini sebelumnya: grep, Ctrl+F, blame, kemudian minta seseorang. Masalah yang sebenarnya bukanlah kecerdasan. Itu waktu membaca.

Bagaimana alat AI dapat mempersingkat fase membaca tanpa melakukan pekerjaan untuk Anda?

Di sinilah alat yang menyadari codebase mendapatkan bayaran mereka. Pertanyaan yang benar-benar Anda tanyakan adalah "di mana X terhubung di repo ini", dan alat yang telah mengindeks kode dapat menjawabnya dengan jalur file dalam hitungan detik bukan 40 menit grep.

Aturan yang membuat Anda belajar: minta peta, kemudian baca kode sendiri. "File mana yang menangani kedaluwarsa sesi dan apa yang memanggilnya?" adalah prompt yang baik. "Perbaiki bug ini untuk saya" adalah bagaimana Anda mengakhiri pengiriman PR yang tidak dapat Anda pertahankan dalam review. Open Source Guide mengatakannya langsung: kontributor tetap bertanggung jawab atas perubahan yang mereka kirimkan, dan pekerjaan yang dibantu AI perlu diverifikasi terhadap konvensi proyek.

Cursor sangat kuat ketika repo sudah terbuka di editor Anda dan Anda ingin jawaban inline tentang file di depan Anda. Itu berjuang ketika jawabannya mencakup beberapa repositori, yang umum setelah Anda berkontribusi ke proyek dengan paket terpisah.

Chat GitHub Copilot paling dekat dengan alur kerja pull request, yang membantu ketika Anda meninjau diff orang lain. Jawabannya bergantung pada file yang Anda buka, jadi Anda perlu menarik file yang tepat ke konteks terlebih dahulu.

Aider bekerja dari terminal dan mengedit file langsung melalui komit git. Itu sangat baik untuk pelajar yang menginginkan riwayat bersih dari setiap perubahan, dan berisiko jika Anda menerima edit yang belum Anda baca.

Continue.dev adalah sumber terbuka dan memungkinkan Anda menunjuknya ke model pilihan Anda, sehingga Anda mengendalikan biaya dan ke mana kode Anda pergi. Pertukaran itu adalah waktu setup: harapkan menghabiskan malam untuk konfigurasi.

Tidak satupun dari ini menggantikan langkah 4 dari rutinitas di atas. Mereka memperkecilnya dari sore hari menjadi jeda kopi, dan Anda masih harus memahami apa yang Anda temukan.

Seperti apa proyek ketika Anda ingin itu mendapatkan pekerjaan?

Manajer perekrutan tidak mengklon repo Anda. Mereka menghabiskan sekitar dua menit di dalamnya. Apa yang mereka periksa konkret: apakah README mengatakan apa yang dilakukannya dan cara menjalankannya, apakah ada folder tes, apakah komit dapat dibaca, dan dapatkah Anda menjelaskan keputusan desain dengan suara keras.

Bangun untuk pembaca itu:

• Tulis README terlebih dahulu. Jika Anda tidak dapat menggambarkan proyek dalam empat kalimat, cakupannya salah.

• Jaga komit tetap kecil dan diberi nama berdasarkan niat. "Tangani baris CSV kosong" mengalahkan "perbaikan".

• Tambahkan satu tes yang akan menangkap bug nyata yang Anda tekan. Satu tes jujur mengalahkan lencana cakupan.

• Catat satu hal yang tidak bekerja. Bagian "apa yang saya coba dan lepas" yang pendek memberi sinyal kematangan lebih banyak daripada cerita tanpa cacat.

PR yang digabungkan dalam proyek sumber terbuka yang dikenal sering mengungguli tiga aplikasi solo, karena membuktikan Anda dapat bekerja dalam batasan orang lain. Jika Anda mengelola tim, logika yang sama berlaku sebaliknya: junior yang telah mengirim PR ke repo luar ramp lebih cepat, karena mereka telah melakukan langkah "cari titik masuk" di bawah tekanan.

Bagaimana Anda memilih satu proyek dan menyelesaikannya?

Gunakan filter alih-alih perasaan. Nilai setiap ide dari 1 hingga 3 pada empat pertanyaan:

• Dapatkah Anda menunjukkannya dalam 60 detik? 3 berarti satu perintah dan satu hasil yang terlihat.

• Apakah itu menggunakan kode yang tidak Anda tulis? 3 berarti perpustakaan, spesifikasi, atau repo yang sudah ada.

• Akankah Anda menggunakannya sendiri? 3 berarti Anda punya alasan untuk membukanya minggu depan.

• Dapatkah Anda selesai dalam empat minggu? 3 berarti Anda dapat menamakan tugas terakhir hari ini.

Apa pun di bawah 9 kembali ke rak. Kemudian atur blok kalender, bukan tingkat motivasi. Dua sesi tetap per minggu selama empat minggu mengalahkan akhir pekan heroik yang diikuti oleh kesunyian.

Ambil: berhenti mengumpulkan ide. Pilih satu proyek yang membangun, dan satu yang membaca. Bangun interpreter kecil atau CLI untuk membuktikan Anda bisa menulis, lalu buka PR docs di repo yang Anda gunakan untuk membuktikan Anda bisa membaca. Bersama-sama mereka mencakup dua bagian pekerjaan, dan bagian kedua adalah yang hampir tidak ada yang praktikkan.