Siapa "Insinyur 10x"?

Apakah seseorang yang menulis ribuan baris kode setiap hari? Apakah seseorang yang mendorong fitur-fitur produk baru dalam semalam sambil mengonsumsi banyak kafein? Juga, mengapa ide "Insinyur 10x" ini mendorong lebih banyak orang untuk mengalami Sindrom Palsu di tempat kerja?

Dalam artikel ini, kita akan menghilangkan prasangka mitos "Insinyur 10x" dan berbicara tentang Sindrom Impostor yang terkenal itu.

(Untuk pemikiran lebih lanjut tentang "10x Engineer", lihat artikel Codementor sebelumnya dengan pendiri Moz Rand Fishkin di sini.)

Kicauan Twitter

Saya menemukan sebuah Untaian Twitter Suatu hari yang lain benar-benar membuat saya penasaran. Utas ini berbicara tentang seperti apa "Insinyur 10x" seharusnya. 🤔

Begini caranya:

Yang lebih menggelitik saya adalah melihat berapa banyak insinyur berpengalaman, Pakar Pengembang Google, tenaga ahli teknik, dan profesional lain di Twitter yang semakin terpesona dengan gagasan "Insinyur 10x", menurut utas khusus ini.

Mari kita cari tahu mengapa, perhatikan lebih dekat 11 poin yang dibuat di utas Twitter ini, dan diskusikan mengapa gagasan "Insinyur 10x" dapat memiliki efek berbahaya bagi pengusaha dan karyawan. Saya juga akan berbicara tentang beberapa takeaways kunci dalam artikel ini.

Penolakan tanggung jawab: Artikel ini hanya memuat pandangan saya tentang "Insinyur 10x" dan sama sekali tidak dimaksudkan untuk tidak menghormati siapa pun atau pandangan mereka.

Banyak keputusan penting dibuat dalam pertemuan. Sebagai seorang insinyur, penting untuk berada dalam tim lintas fungsi, di mana Anda tidak hanya berinteraksi dengan insinyur lain, tetapi Anda juga berbicara dengan desainer, pengembang backend, manajer produk, dan pemangku kepentingan lainnya di perusahaan. Ini memungkinkan Anda untuk mendapatkan ide yang lebih baik tentang produk yang sedang Anda kerjakan dan arah kemana arahnya.

Saya tidak melihat mengapa ini dilihat sebagai hal yang negatif. Seorang insinyur harus memiliki pengetahuan produk yang bagus. Jelas tidak disarankan untuk hanya mendorong ribuan baris kode dan menyebutnya sehari.

Saya tahu semua orang membenci rapat, tetapi itu tidak berarti rapat itu tidak produktif. 👨‍💻

Takeaway: Menghadiri rapat. Tidak semua dari mereka akan produktif, tetapi untuk yang ada, Anda akan belajar banyak dari orang-orang di departemen perusahaan lain. Ambil semuanya dan serap sebanyak mungkin.

Ini berpotensi memberi "10x engineer" alasan untuk tidak tepat waktu. Saya pribadi bekerja sampai jam 2 pagi di malam hari, tapi saya tidur 6 jam dan saya di kantor jam 10 pagi. Juga, saya suka bekerja dengan orang lain. Saya bisa belajar banyak dari orang-orang dengan pengalaman kerja lebih banyak daripada saya.

Karena menggoda bagi beberapa insinyur untuk memerlukan privasi saat bekerja, itu tidak berarti semua insinyur seperti itu. Jika itu adalah kasus ini, kami akan memiliki banyak kantor kosong di siang hari. 🤷‍♂️

Takeaway: Bersikap terbuka untuk mempelajari hal-hal dari kolega Anda adalah sesuatu yang tidak boleh diabaikan oleh siapa pun di tempat kerja. Jangan membatasi diri di meja Anda di kantor. Berusahalah tepat waktu, tetapi yang terpenting, pertahankan keseimbangan kerja dan tidur yang baik. Pengkodean larut malam tidak baik untuk Anda jika Anda tidak memenuhi persyaratan tidur pribadi Anda.

Sebagai permulaan, apa latar belakang layar laptop saya harus lakukan dengan apa pun? Beginilah tampilan layar utama di laptop saya sekarang:

Selain itu, tombol yang usang pada laptop saya adalah kontrol dan Tab, karena fitur peralihan tab di macOS dan Chrome, yang sering saya gunakan ke Google untuk jawaban ketika saya terjebak dengan tantangan pengkodean. (Saya seorang Insinyur 1x. 😉)

Takeaway: Siapkan perangkat Anda dan optimalkan untuk Tujuan produktivitas tertinggi. Abaikan semua norma lainnya, dan "Anda harus menggunakan ini" dan "mengapa Anda tidak menggunakan ini?" saran. Ikuti nasihat yang baik, tetapi pada akhirnya, cari tahu apa yang paling cocok untuk Anda kamu.

Sebagian besar insinyur yang saya kenal mengandalkan keterampilan memecahkan masalah dan keterampilan "berpikir sambil berjalan", daripada mengandalkan kekuatan ingatan mereka. Tweet ini menyiratkan bahwa Insinyur 10x memiliki kekuatan memori yang luar biasa.

Ketika QA tidak memperingatkan mereka tentang suatu masalah, para insinyur biasanya memecahkan masalah menggunakan keterampilan mereka dan pengetahuan yang mereka miliki tentang basis kode. Beberapa masalah bisa memakan waktu berjam-jam, beberapa bisa memakan waktu berhari-hari. Tetapi tidak setiap masalah dapat diperbaiki dalam hitungan jam; itu tidak layak dalam kehidupan nyata.

Takeaway: Ketahuilah basis kode Anda dengan baik, tetapi jangan terlalu memaksakan diri untuk mengetahuinya setiap baris kode. Anda akan lebih terbiasa dengannya seiring waktu. Memperbaiki bug dan kesalahan juga merupakan sesuatu yang Anda akan menjadi lebih baik seiring berjalannya waktu.

Kami tidak akan memiliki insinyur front-end, insinyur UX, atau siapa pun yang berspesialisasi dalam mengubah desain yang baik menjadi kode UI jika semua "Insinyur 10x" adalah insinyur full-stack. Tentu, insinyur full-stack sangat hebat, dan saya tahu beberapa dari mereka yang ahli dalam banyak hal dalam suatu produk, tetapi gagasan "Insinyur 10x" ini jarang melakukan pekerjaan UI apa pun tidak berhasil di organisasi mana pun.

Pekerjaan UI sama pentingnya dan dilengkapi dengan tantangannya sendiri.

Takeaway: Jika Anda seorang insinyur penuh, maka itu fantastis. Kerjakan semua hal yang Anda sukai untuk dikerjakan. Jika Anda seorang insinyur front-end, itu luar biasa juga. Fokus pada keterampilan pengkodean UI Anda dan jadilah hebat. Terserah kamu apakah Anda ingin menjadi spesialis dalam satu set keterampilan tertentu, atau ingin bereksperimen dan bekerja dengan beberapa set keterampilan.

Gagasan bahwa seseorang dapat mengubah "pemikiran" menjadi "kode" dapat mendemotivasi para insinyur junior, yang baru memulai di bidangnya. Ini adalah jenis tekanan yang harus dihindari oleh para insinyur.

Selain itu, meskipun merupakan keterampilan yang baik untuk dapat membangun fitur produk dengan cepat, penting juga untuk diingat bahwa keterampilan semacam ini diasah selama bertahun-tahun bekerja sebagai insinyur. Seluruh gagasan "minum banyak kopi dan membuatkan saya fitur ini dalam empat hingga enam jam" adalah cara beracun untuk menekan para insinyur agar pekerjaan dilakukan lebih cepat.

Selain itu, terlalu banyak kafein berdampak buruk bagi kesehatan Anda! 🙅‍♂️

Takeaway: Anda tidak akan melakukan bantuan apa pun kepada siapa pun jika Anda kafein dan kelelahan; yang hanya memperlambat produktivitas Anda. Hancurkan tugas membangun fitur menjadi bit yang lebih kecil, bicarakan dengan manajer Anda dan tetapkan beberapa harapan nyata tentang batas waktu fitur produk. Melakukan hal ini tidak hanya meningkatkan rasa hormat yang dimiliki orang kepada Anda di tempat kerja, tetapi juga memastikan bahwa Anda tidak menetapkan harapan yang tidak realistis tentang tenggat waktu.

Seluruh tujuan memiliki dokumentasi tentang sesuatu is bagi insinyur untuk melihatnya. Tidak masalah apakah mereka junior, menengah atau senior, setiap insinyur melihat dokumentasi dari waktu ke waktu. Mengandalkan daya memori sepenuhnya bukanlah ide yang bagus.

Takeaway: Anda seorang insinyur manusia. Anda jelas bukan insinyur robot. Anda tidak perlu memiliki dokumentasi yang dihafal. Anda dapat mencari hal-hal di internet, karena saya jamin, itulah yang dilakukan oleh para insinyur yang paling berpengalaman sekalipun. Tetapi sebagai seorang insinyur, itu selalu ide yang baik untuk tahu bagaimana membingkai pertanyaan untuk masalah Anda, daripada hanya memiliki solusi untuk masalah Anda hafal sendiri. Tahu bagaimana dan apa untuk bertanya, dan Anda akan menerima jawaban.

Tweet ini memang memiliki beberapa poin bagus. ini penting untuk dipelajari kerangka kerja dan bahasa baru, tetapi bagian di mana "Insinyur 10x" melakukan itu "di depan semua orang di perusahaan" berpotensi menumbuhkan negativitas di tempat kerja.

Alih-alih, jika ada kerangka kerja baru yang harus dipelajari oleh beberapa insinyur di organisasi, dan yang seharusnya "Insinyur 10x" ini telah mempelajarinya, itu adalah tugas "Insinyur 10x" untuk menyiapkan bengkel atau hackathon tempat ia Dia membantu melatih rekan kerja dalam mempelajari kerangka kerja.

Lagi pula, insinyur mana tidak suka hackathon? 😉

Takeaway: Majulah dan pelajari kerangka kerja atau bahasa baru yang dibicarakan semua orang, tetapi tetaplah rendah hati dan bertujuan untuk membantu melatih orang yang baru mengenalnya.

Tweet ini membawa saya kembali ke titik yang sama dengan yang saya buat untuk # 8. Pekerjaan Anda sebagai insinyur bukan hanya mendorong ribuan baris kode. Anda harus dapat berkomunikasi dengan tim Anda dengan baik. Tapi itu bukan ide bagus untuk mempromosikan kerja tim yang buruk dengan menyindir bahwa "Insinyur 10x" adalah satu-satunya tentara pria.

Saya yakinkan Anda, bukan itu masalahnya. Setiap produk bagus di organisasi besar mana pun dibangun dengan tim yang baik. Orang-orang ini memiliki kerja sama tim yang hebat dan chemistry di antara mereka sendiri.

Selain itu, jika "Insinyur 10x" adalah "pewawancara yang buruk", maka itu hanya menunjukkan mereka buruk dalam komunikasi dan menampilkan diri.

Takeaway: Jika Anda bekerja dengan seseorang yang membutuhkan bantuan Anda, Anda harus dapat membimbing mereka. Sekali lagi, ini terkait dengan gagasan untuk menjadikan tim lebih baik secara keseluruhan, daripada melakukan semuanya sendiri. Luangkan waktu untuk mendiskusikan ide dengan semua orang di tim Anda dan, saya berjanji kepada Anda, itu akan membayar Anda tepat waktu.

Walaupun merupakan ide yang bagus untuk menulis kode yang terstruktur dengan baik, Anda tidak dapat mengetahui bagaimana kode Anda berkembang. Mungkin ada kerangka kerja baru yang mungkin perlu Anda gunakan yang berpotensi mengubah seluruh struktur kode Anda. Saya semua untuk menulis kode kualitas tetapi saya tidak yakin seberapa besar saya setuju untuk mengetahui dengan pasti bagaimana kode harus berevolusi.

Pada catatan lain, menulis dokumen desain yang terperinci dengan baik adalah mutlak harus jika tim Anda berencana untuk memperluas dan menerima lebih banyak insinyur. Itu membuat pengalaman onboarding untuk insinyur baru lebih mudah.

Takeaway: Tulis kode kualitas, miliki model mental yang bagus untuk keseluruhan struktur kode Anda, tetapi bersiaplah untuk memasukkan kerangka kerja dan teknologi baru ke dalam basis kode Anda yang sudah ada. Pastikan juga Anda menulis dokumentasi yang baik untuk kode Anda sehingga insinyur baru yang pada akhirnya akan mengerjakan produk tidak memiliki masalah dalam pemahaman kode.

Insinyur yang terampil, lebih sering daripada tidak, adalah orang-orang yang mencari pekerjaan atau pindah dari perusahaan. Mengapa? Ini bisa karena salah satu dari alasan berikut:

• Pekerjaan mereka saat ini tidak cukup menantang dan mereka ingin mengeksplorasi tantangan baru di organisasi lain yang mungkin membantu mereka tumbuh sebagai insinyur
• Mereka tidak senang dengan cara mereka diberikan kompensasi untuk keterampilan mereka dan mencari paket gaji yang lebih tinggi yang mencerminkan keterampilan mereka
• Mereka mungkin menemukan tempat kerja saat ini beracun, yaitu, mereka mungkin memiliki bos yang ingin mereka menjadi "Insinyur 10x" 😉

Juga, jika Anda seorang manajer perekrutan dan Anda kebetulan bertemu seorang insinyur yang tidak menyukai rapat, pelatihan, atau apa pun yang berkaitan dengan membantu timnya, larilah ke arah yang berlawanan. Ini adalah tanda seseorang dengan kepentingan pribadi yang begitu dalam sehingga keterampilan mereka tidak akan menguntungkan siapa pun selain mereka sendiri dalam jangka panjang.

Tetapi dalam keadaan apa pun Anda tidak boleh "memeganginya" atau "merayakannya". 🙅‍♂️

Takeaway: Jika kamu bahagia di organisasi Anda saat ini, itu luar biasa, tetapi jika salah satu dari alasan yang disebutkan di atas tampaknya beresonansi dengan Anda, saya sarankan mencari pekerjaan dan mencari pekerjaan di mana Anda akan lebih bahagia dan lebih puas. Temukan pekerjaan yang tepat untuk diri Anda sendiri, berpartisipasi dalam rapat dan pelatihan, dan tumbuh sebagai seorang insinyur sambil juga membantu tim Anda tumbuh bersama Anda.

Sekarang saya telah berbicara tentang utas Twitter khusus ini, mari kita beralih ke masalah lain yang dihadapi banyak insinyur setidaknya sekali dalam karir mereka.

“Sindrom Palsu”

Jika Anda seorang insinyur junior, dan Anda baru saja memulai peran baru Anda di perusahaan Anda, saya yakin beberapa pemikiran berikut mungkin menggerogoti Anda di beberapa titik:

• "Saya tidak cukup bagus."
• "Saya disewa secara tidak sengaja!"
• "Bagaimana aku bisa sebagus kolega saya di sini?"

Tebak apa? Saya juga merasakan hal itu dalam peran insinyur pertama saya, dan Anda tidak sendirian. Faktanya, penelitian menunjukkan bahwa bahkan insinyur senior pun merasakan hal itu, bahkan setelah pengalaman bertahun-tahun! Mengejutkan, bukan?

Sekarang, saya tidak yakin mengapa sebagian besar insinyur, termasuk saya sendiri, merasa seperti ini - tetapi saya tahu bagaimana saya mengatasinya. Solusinya cukup sederhana: jangan biarkan diri Anda terobsesi apakah Anda direkrut secara tidak sengaja atau apakah Anda cukup baik untuk pekerjaan itu. Biarkan orang yang mempekerjakan Anda melakukan itu.

Apa artinya ini dengan kata-kata yang lebih sederhana: jika Anda dipekerjakan untuk pekerjaan itu, Anda cukup baik untuk pekerjaan itu. Sama sekali tidak perlu merenungkan apakah Anda "dipekerjakan secara tidak sengaja". Manajer perekrutan melihat sesuatu dalam diri Anda yang dia sukai dan memutuskan Anda cocok untuk peran itu, titik.

Tetap fokus pada melakukan pekerjaan Anda dengan baik, dan Anda akan melakukan yang terbaik. Ada banyak ruang untuk dipelajari ketika Anda baru di bidang pekerjaan Anda, terutama ketika Anda bekerja dengan insinyur yang lebih berpengalaman di bidang tersebut.

Namun, ini seharusnya tidak menjadi pintu gerbang untuk keraguan diri, tetapi harus dilihat sebagai kesempatan untuk mengembangkan keterampilan Anda dalam peran baru Anda.

"Jika kamu adalah orang terpintar di ruangan itu, kamu mungkin berada di ruangan yang salah."

Sumber: https://www.codementor.io/blog/10x-Engineer-Not-N Diperlukan-7do0ivvl3r