5 keterampilan penting dan terlewatkan yang dibutuhkan oleh pengembang terbaik

Kata Pengantar

Anda telah melihat artikel ini ribuan kali:

• "10 hal yang perlu Anda ciptakan untuk menjadi pengembang yang lebih baik."
• "Kerangka kerja terbaik untuk dipelajari pada 2019."
• "Lakukan untuk menjadi pengembang Rockstar."
• "Baca sepuluh buku teknis ini dan Anda akan menjadi pengembang yang sukses."

Apa yang mereka katakan adalah bahwa Anda perlu belajar reactjs atau node . Buat 1.000.000.000 aplikasi ToDo. Baca Python Crash Course dan boom, Anda adalah pengembang terbaik.

Ini semua pengetahuan teknis (teoritis). Anda membutuhkannya, tetapi apakah Anda berpikir bahwa seorang penata rambut yang tahu cara memegang gunting secara teknis itu baik? Ada lebih banyak keterampilan untuk dievaluasi dalam setiap profesi!

Mari kita bicara tentang apa yang saya anggap keterampilan diabaikan.

Berpikir abstrak

Sebagai pengembang, Anda harus mengimplementasikan fungsi yang akan digunakan seseorang. Seseorang ini mungkin Anda, klien, kolega Anda, orang-orang dari Internet yang tidak akan pernah Anda temui.

Mengetahui hal ini, tugas Anda adalah memikirkan semuanya dan membawa fungsinya pada esensinya.
Manajemen Anda ingin melihat seberapa sering orang mengklik sesuatu di situs web. Anda harus mengerti bahwa mereka adalah orang-orang dengan pemikiran tertentu .

Manajer Anda memikirkan daftar, angka, dan tabel. Saat ini, gambaran besar dari program kompleks Anda tidak menjadi perhatian mereka, dan mereka tidak memahaminya. Seharusnya tidak. Pekerjaan ini milikmu!

Mari kita kembali ke tugas "seberapa sering pengguna mengklik situs" . Saya membayangkan diri saya di kedua peran. Dalam peran pengguna, dan orang yang melihat data dan mencoba untuk mencari tahu apa yang dibutuhkan pengguna.

Untuk pengguna akhir, semuanya harus sama. Mungkin disclaimer akan muncul, yang dia tekan sekali. Dan itu dia. Fitur-fitur ini seharusnya tidak terlihat oleh pengguna akhir. Yah, itu mudah. Selalu pikirkan pengguna akhir Anda terlebih dahulu! Selalu!

Sekarang, mari kita pikirkan siapa yang diuntungkan dari data. Jadi apa yang ingin dilihatnya? Hanya sebuah angka. Bagaimana dengan 42 ? Tapi apa artinya angka ini? Mungkin cara terbaik untuk mengukur bukan frekuensi klik, tetapi tujuan klik? Anda kembali ke tim pengembangan atau pemegang saham Anda dan memberi tahu mereka bahwa mungkin lebih baik memiliki statistik tentang seberapa sering kita mengklik dan tindakan apa yang mengikuti klik? Mungkin Anda mendengar sesuatu seperti, “Oh, bisakah Anda melakukan itu? Ya, mari kita lakukan . " Anda dapat terus mempelajari abstraksi, tetapi saya pikir Anda menangkapnya.

Menulis pertanyaan yang tepat

Saya melihat ini sepanjang waktu, dari Pengembang Junior hingga Senior. Anda mendapatkan tugas, dan menyelesaikannya. Saya memanggil orang-orang ini Code Monkeys .

Bagian dari menjadi pengembang adalah mengajukan pertanyaan dan memahami apa yang perlu kita capai (ini kembali ke pertanyaan abstraksi).
Satu pernyataan dapat ditafsirkan dalam 1000 cara.
Anda harus mengerti mengapa Anda menerapkan fungsi ini. Jadi, Anda lebih baik melihat masalah dan risiko di masa depan.

Pertanyaan “mengapa” di sebuah perusahaan sering dianggap sebagai masalah kepercayaan .
Anda akan mendengar pernyataan seperti:

• Kita perlu mempercayai tim pengembangan.
• Mari kita percayai mereka, mereka tahu apa yang terbaik untuk perusahaan.
• Apakah kamu tidak percaya padaku?
• Mari kita coba dulu, dan karena itu ajukan pertanyaan.

Mengatur pertanyaan dan mencoba memahami mengapa - tidak ada hubungannya dengan kepercayaan. Sebagai pengembang, Anda tahu cara kerja internal sistem. Anda dapat melihat masalah teknis dan titik keluar, apa yang mungkin berhasil dan apa yang tidak. Jika Anda pernah mendengar perkataan di atas, mengulangi yang berikut selalu berhasil:

• "Aku percaya padamu, dan aku tahu ini penting."

Komunikasi dengan orang tanpa pengetahuan teknis

Seberapa sering ini terjadi pada obrolan seperti Slack:
Anda membuka saluran untuk seluruh perusahaan, dan Anda melihat beberapa tautan ke pos di blog super teknis tentang mengapa "forEach" lebih cepat daripada "peta" dalam JavaScript.

Atau Anda berkata: "Tidak, kami tidak bisa melakukan ini" dan mulai menjelaskan bahwa ReactJS tidak memiliki fungsi ini dan Anda harus memuat paket npm.

Jika manajer produk Anda bukan dari mantan pengembang, maka dia tidak akan mengerti sepatah kata pun dari apa yang Anda bicarakan.

Sebagai gantinya, Anda harus mencoba menemukan analogi yang baik di area di mana semua orang memahami segalanya. Demikian pula, seperti yang saya lakukan di awal dengan penata rambut. Seseorang tanpa basis teknis dapat memahami hal ini dan menyimpulkan bahwa Anda benar.

Sabar

Anda melihat panduan ini di YouTube, di mana orang membuat sesuatu dalam video dalam 15 menit, dan kemudian Anda mencoba mengulanginya, dan itu membutuhkan banyak, banyak, jauh lebih lama!

Anda kesal karena Anda tidak dapat mengimplementasikan daftar tugas ini. Ini juga pertama kalinya Anda menyentuh kode. Yutuber sudah memiliki sepuluh tahun pengalaman praktis dan, terlebih lagi, dipersiapkan sebelum merekam video dan mengimplementasikan daftar tugas ini setidaknya sekali, dan sekarang ia hanya mengulangi skripnya.

Anda tahu - dari mana klise ini berasal, bahwa pengembang adalah makhluk malam? Karena kita menyukainya? Karena kita antisosial? Ini hanya bisa berlaku untuk sebagian kecil. Alasan utamanya adalah menulis kode membutuhkan waktu! Banyak waktu jika Anda mencoba mempelajari sesuatu yang baru!

Pendapat tegas

Saya seorang pria dengan sindrom opini pendapat yang kuat ketika datang ke pengembangan web, dan saya memberi tahu orang-orang pendapat saya bahkan jika saya tahu mereka tidak menyukainya. Saya tidak melakukan ini untuk mengganggu orang atau menjatuhkan mereka. Bagaimana pendapat saya bisa begitu signifikan secara emosional sehingga setelah mendengar Anda meragukan keberadaan Anda sendiri? Maaf, tetapi ada banyak masalah yang lebih signifikan di sekitar, dan Anda harus mencari cara untuk menghadapinya, karena jika tidak, itu hanya mengarah pada satu hal: Stagnasi. Anda akan sama di usia 18, 25 dan 50 tahun. Saya tahu ini lebih mudah untuk ditulis daripada melakukannya, tetapi penting bagi Anda untuk mengetahui: "Cara Anda bersikap sekarang adalah satu-satunya hal yang telah membawa Anda ke kejauhan"

Hal terburuk yang dapat terjadi pada tim pengembangan adalah ketika semua orang memiliki pendapat, tetapi tidak ada yang mengungkapkannya! Jika ini terjadi, Anda sudah mati. Inilah awal dari akhir. Jika Anda bukan kode monyet, maka Anda merasa kurang termotivasi dan lebih kesal setiap hari, dan itu tidak hanya akan bersama Anda. Suatu hari, tanpa diduga, orang-orang yang bekerja selama beberapa tahun untuk sebuah perusahaan akan pergi - karena mereka tidak tahan lagi.

Saya tidak mengatakan bahwa Anda perlu mengatakan, "Saya tidak suka itu." Anda harus mengatakan alasannya dan memberikan beberapa contoh. Jangan f * ck, tapi jangan terlalu kesal setiap hari. Karena itu tidak membantu siapa pun. Jadi, ungkapkan pendapat Anda, atau tidak memiliki opini dan jadilah kode monyet, atau tinggalkan perusahaan untuk mencari pekerjaan yang lebih baik atau menjadi pekerja lepas. Saya tidak tahu mana yang benar, tetapi jangan mandek.

Terima kasih sudah membaca!