Apa yang harus saya katakan di resume saya jika saya dipromosikan karena menurunkan kualitas kode untuk memenuhi tenggat waktu?
Saya sedang dalam kontrak 12 bulan (saya tinggal di negara di mana hal ini tidak biasa bagi pengembang baru) sampai beberapa minggu yang lalu ketika manajemen di perusahaan saya memberi saya tawaran dan kenaikan gaji untuk menjadi karyawan tetap bagi mereka. Saya ingin selalu memperbarui resume saya (terutama karena COVID) jadi saya mencari tahu tentang mencantumkannya di resume saya.
Saran yang saya temukan adalah saya harus mencantumkan prestasi apa yang mendorong perekrutan tersebut. Cukup adil.
Masalahnya adalah, prestasi itu selalu memberikan tenggat waktu klien yang ketat dan terus terang, saya melakukannya dengan memutuskan bahwa tekniknya bisa kurang dari bintang dalam kasus yang ditargetkan (yang disetujui manajemen).
Saya adalah dev yang relatif junior dalam tim yang terdiri dari 6 developer. Namun, saya dengan cepat menjadi salah satu dev yang paling dipercaya manajemen untuk mengirimkan barang ketika saya mengatakan bahwa saya akan mengirimkannya dan memberi mereka informasi tentang trade-off relatif untuk sampai ke sana. Dalam waktu saya yang diakui singkat di sini, saya selalu dapat mengirimkan sesuatu ketika saya mengatakan bahwa saya dapat mengirimkannya.
Saya memiliki beberapa kasus seperti ini, tetapi ini adalah kasus yang saya lakukan tepat sebelum saya ditawari pekerjaan permanen. Salah satu produk kami adalah API batch yang dipanggil sekali sehari oleh satu klien. API ini tidak perlu mengembalikan apa pun kecuali CSV dari entri yang gagal melalui email. Mereka menginginkan fitur baru ditambahkan dan tenaga penjual telah secara kontrak setuju untuk memilikinya untuk mereka pada akhir bulan. Karena berbagai alasan, permintaan fitur itu tidak sampai kepada kami hingga hari Senin di minggu terakhir bulan itu.
Pengembang senior mengatakan kepada manajer bahwa pengembangan tidak dapat dilakukan dengan baik dan untuk memberi tahu klien bahwa hal itu tidak dapat dilakukan. Saya tidak membantah para pengembang senior dalam rapat perencanaan sprint, tetapi mungkin jelas bahwa saya tidak setuju dengan orang senior. Bukan tidak setuju, tetapi ada pilihan dengan trade off tertentu. Dev yang lain juga cukup pasif, jadi tidak ada orang lain yang membantahnya. Manajer tidak senang dengan hal ini karena klien sudah marah kepada kami karena tidak memberikan hasil ketika kami berjanji untuk melakukannya. Manajer kemudian memanggil saya ke kantornya setelah rapat untuk menanyakan apakah saya melihat alternatif lain. Saya mengatakan kepadanya bahwa saya bisa membuat sesuatu untuk bekerja, tetapi mungkin akan melipatgandakan waktu pemrosesan API (yang akan menambah 4 menit) karena saya tidak memiliki keterampilan SQL khusus. Manajer setuju dan rupanya klien bahkan tidak menyadarinya.
Saya tidak yakin apa konsekuensi dari melewatkan tenggat waktu, tetapi cukup berat sehingga CEO dari perusahaan kami yang terdiri dari 1000 orang mengirimkan email terima kasih kepada saya karena telah mengirimkannya.
Kasus lain tidak menarik banyak perhatian, tetapi ada proses yang perlu kami jalankan pada database. Cara yang benar untuk melakukannya adalah dengan menulis proses batch yang tepat dalam sistem mega Java yang kami gunakan, mengirimkannya melalui semua proses QA reguler, dan membiarkannya keluar dua minggu kemudian. Saya menawarkan kepada manajer sebuah skrip Python yang perlu dijalankan secara manual dan akan sangat tidak efisien (harus menjalankannya dalam semalam), tetapi jika dipicu sebulan sekali, akan menjaga masalah tetap ada sampai perbaikan permanen tiba. Ini adalah masalah produksi, jadi dia setuju untuk itu sebagai tindakan sementara. Ini pada dasarnya hanya sebuah loop for murah yang memeriksa baris untuk jenis data tertentu yang salah dan memformat ulang.
Apakah ada cara untuk mencantumkan hal-hal semacam ini di resume saya yang tidak membuat saya terlihat seperti programmer hack yang merongrong dev senior? Saya akui bahwa solusi saya secara teknis tidak baik, tetapi solusi tersebut baik untuk kebutuhan bisnis pada saat itu dan trade off inefisiensi sebagian besar tidak relevan dalam banyak kasus.
Anda menemukan beberapa cara yang efektif (bukan efisien) untuk memecahkan masalah tanpa merekayasa secara berlebihan dan "Selesai lebih baik daripada sempurna &"
Menemukan solusi yang cukup baik adalah kemampuan penting bagi seorang insinyur karena jika tidak, Anda akan menghabiskan banyak waktu untuk mengoptimalkan sesuatu yang tidak layak dioptimalkan. Jika sesuatu tidak sering digunakan, sering kali tidak ada gunanya untuk mengoptimalkannya. Ada sebuah XKCD-Comic yang bagus dengan tabel yang memberitahu Anda berapa banyak waktu yang harus Anda investasikan dalam sesuatu.
Sebuah solusi hanya bernilai sesuatu jika (atau dapat) digunakan, jadi dengan hack Anda memungkinkan pelanggan untuk terus bekerja sampai Anda memiliki solusi.
Tidak ada alasan untuk memberi tahu siapa pun bahwa Anda tidak setuju dengan supervisor Anda. Cukup gunakan sesuatu seperti "Mampu menghasilkan solusi yang efektif di bawah tekanan waktu".
Anda memiliki satu pekerjaan: "menemukan solusi yang berjalan dalam batas waktu yang menyelesaikan pekerjaan ". Dan itulah yang Anda lakukan.
Seperti kata pepatah " Sempurna adalah musuh kebaikan &" - membuat kompromi teknis untuk memenuhi kebutuhan bisnis cukup banyak de rigueur. Devs/programmer/engineer yang baik adalah mereka yang dapat mengidentifikasi trade-off yang dapat diterima yang dapat dibuat.
Dalam contoh API Anda, pelanggan jelas lebih bersedia menerima penundaan 4 menit dalam pemrosesan untuk sesuatu yang berfungsi dan dikirimkan tepat waktu.
Idealnya, Anda harus meminimalkan utang teknis saat membuat kompromi ini - tetapi itu semua adalah bagian tak terpisahkan dari pengalaman dan mengetahui di mana Anda dapat menghemat waktu dan kapan Anda perlu memastikan bahwa sesuatu dilakukan dengan benar untuk menghemat lebih banyak waktu dalam jangka panjang.
Pertanyaan mendasar saya adalah, apakah ada cara untuk mencantumkan hal-hal seperti ini di resume saya yang tidak membuat saya terlihat seperti programmer hack yang meremehkan dev senior?
Ketika berada di atas CV Anda, tidak perlu membahas solusi Anda secara spesifik - Anda cukup mengatakan bahwa Anda memiliki rekam jejak yang baik dalam memenuhi tenggat waktu pada proyek-proyek yang sensitif terhadap waktu dan menyebutkan contoh-contohnya tanpa detail implementasi yang sebenarnya.
Apa yang Anda lakukan BUKAN "hacking &", itu adalah "mencari solusi &".
Saya bekerja sebagai pengembang dan konsultan sejak 20 tahun sekarang, dan keterampilan inilah yang dicari oleh pemberi kerja: Jangan tinggalkan itu dari resume Anda, tetapi tekankan hal itu: Anda mencoba mencari solusi bahkan jika itu berarti menempuh jalur yang tidak biasa.
Jangan menulis bahwa Anda melakukan itu di belakang punggung pengembang senior tetapi Anda melakukannya setiap kali diminta solusi bahkan jika orang yang lebih berpengalaman tidak setuju / mengatakan itu tidak mungkin.
Ada kutipan bagus yang dikatakan berasal dari Albert Einstein yang persis menggambarkan situasi Anda:
Semua orang tahu itu tidak mungkin, sampai orang bodoh yang tidak tahu datang dan melakukannya.
Saya bekerja sama dengan banyak pengembang dan saya tahu setiap aspek dari hal ini:
Saya bekerja dengan seorang pengembang yang termasuk di antara 1% ahli JavaScript teratas di stackoverflow. Dia adalah seorang jenius dan saya sangat mengagumi setiap baris kode yang ditulisnya. Tetapi seringkali dia tidak menyelesaikan proyeknya: Dia lebih suka tidak menyelesaikan sesuatu daripada menyelesaikannya ketika dia tidak puas dengan keindahan kodenya.
Dan saya bekerja dengan pengembang yang sangat efisien, tetapi karena itu mengambil banyak jalan pintas yang membuat solusinya hampir tidak dapat dipertahankan (jalur hardcoded, angka ajaib, dll.).
Dan saya selalu lebih suka "done" daripada "beautiful" dan pada akhirnya pelanggan saya juga begitu: Mereka lebih suka memiliki "sesuatu &" ketika tenggat waktu ada daripada "tidak ada apa-apa tetapi akan menjadi indah dalam beberapa waktu lagi X &"
Hanya satu hal: Solusi / jalan pintas / "hacks &" perlu dimengerti, didokumentasikan dan dipelihara, maka tidak ada yang menentang solusi seperti Anda