Isi
- 01. Coding tidak memotongnya lagi
- Luas dan dalam
- 02. Peringatan besar
- 03. Apa kata internet
- Pahami medianya
- 04. Hal-hal yang kita bangun
- 05. Devops
- Pahami tumpukan
- Pekerjaan misterius
- Alat yang berguna
- 06. Dev akan memperbaikinya ... mungkin
- Debugging
- 07. Apa yang diinginkan pengguna
- Pasar yang kompetitif
- 08. Menggambar dan menulis
- 09. Nikmati diri Anda sendiri
- 10. Tetap tajam
- Suka ini? Baca ini!
Pengembang harus lebih dari sekadar pekerja kasar yang menghasilkan kode. Kami mengharapkan lebih banyak dari kehidupan digital kami dan orang-orang inilah yang membangunnya, jadi apa yang perlu diketahui oleh developer terbaik? Berikut adalah hal-hal yang saya lihat hilang dari terlalu banyak pengembang. Ini tidak lengkap, tetapi kualitas inilah yang mengubah pembuat kode yang masuk akal menjadi pengembang yang luar biasa.
Tapi ini bukan satu hal, dan terutama kemampuan untuk mengurai XML atau mengoptimalkan kode. Ini adalah kumpulan keterampilan mengejutkan yang tidak diajarkan dalam buku tentang menulis kode. Mereka adalah sesuatu yang ekstra.
Mengapa curhat seperti ini? Karena pengembangan itu penting, tetapi pengembang terlalu sering diserahkan ke dunia yang berbeda, tidak selalu buatan mereka. Ini tidak pernah berhasil. Pengembangan - apa pun yang bersifat teknis - selalu berkembang pesat ketika mereka yang tahu caranya memahami lebih dari sekadar kode.
01. Coding tidak memotongnya lagi
Kita berada di dunia di mana pengkodean menjadi kurang mengesankan. Semua orang membuat situs, beberapa di antaranya berkode, tetapi Anda tidak perlu melakukannya. Bukan lagi kutu buku yang dapat membuat situs, aplikasi, dan fitur.
Sejak web datang dan orang-orang bisa belajar sendiri, ada pengembang otodidak. Tetapi bahkan para lulusan pun terancam. Saya mendapatkan CV dari orang-orang dengan gelar ilmu komputer, kursus AI, berbagai media, dan pengkodean, tetapi masih ada yang kurang. Terkadang banyak yang hilang.
Saya bukan orang pertama yang mengatakan ini. 'Coding jangan potong lagi' adalah judul bab 3 dari Programmer yang Bergairah, yang disertai dengan buku-buku seperti Berpikir dan Belajar Pragmatis mendorong pemrogram untuk memperbaiki diri mereka sendiri di luar kode; untuk menjadi anggota tim yang bertanggung jawab dan sepenuhnya manusiawi.
Luas dan dalam
Pengembang perlu menjadi lebih baik dalam dua cara: luas dan mendalam. Mereka perlu memahami luasnya interaksi manusia dalam tim mereka dan dengan hal-hal yang mereka bangun. Mereka perlu memahami kedalaman sistem tempat mereka bekerja, hingga ke O / S.
Dan bukan hanya pengembang yang harus membaca artikel ini. Jika Anda bekerja dengan pengembang, saya rasa Anda harus mengharapkan lebih banyak dari mereka. Buat mereka membuat sketsa apa yang mereka bicarakan. Buat mereka menjelaskan dengan gambar, objek, dan (cara kerjanya) memotong orang dengan tepat seperti apa sistem itu bagi manusia yang menggunakannya.
02. Peringatan besar
Saya akan berbicara negatif tentang pengembang, tetapi saya pikir saya diizinkan karena saya adalah salah satunya. Juga karena setidaknya satu hal yang saya bicarakan di sini berlaku untuk banyak pengembang yang saya temui. Meskipun pekerjaan mereka bagus dan mereka tahu kode mereka, waktu sangat kompetitif. Anda harus memiliki keunggulan, dan ini adalah:
- jadilah lebih techy
dan
- menjadi banyak lebih manusiawi
03. Apa kata internet
Mencari 'keterampilan pengembangan web yang penting' di Google menampilkan apa yang Anda harapkan. Pengetahuan kerangka kerja, x-browser, CSS dan JS. Mereka mencantumkan kerangka kerja yang harus Anda ketahui, platform yang harus Anda tulis, dan tren baru yang harus Anda perhatikan.
Ini adalah media kami. Mereka adalah barang yang kami bangun, tetapi bukan itu yang membuat proyek berhasil. Pengembang dapat memahami setiap detail sistem, memberi tahu Anda setiap fitur API dan teknologi CSS baru, tetapi masih menghasilkan sesuatu yang tidak dapat digunakan.
Pahami medianya
Pengembang, seperti semua orang, perlu memahami media mereka - tetapi mereka juga harus memahami audiensnya, baik itu pengguna, tim, atau pengembang lain. Mereka perlu memahami bagaimana media mereka cocok dengan dunia (dengan kata lain, lingkungan produksi) dan apa pengaruhnya (bagaimana orang menggunakannya).
Saya telah melihat ini digambarkan sebagai orang yang 'lebar dan dalam'. Luas, karena Anda perlu memahami dunia sebagai manusia yang bekerja dengan manusia lain. Jauh karena Anda membutuhkan pengetahuan teknis yang menyeluruh di bawah level bagian proyek Anda. Pengembang ini memberi proyek Anda dorongan besar dan mengubah kecepatan proyek, tanpanya Anda akan menemukan staf non-teknis terjebak dalam detail membosankan yang meluap dari tim teknologi.
04. Hal-hal yang kita bangun
Baru-baru ini saya menulis daftar semua yang kami gunakan untuk membangun situs, mengelola hosting, dan menyelesaikan pekerjaan sehingga orang yang bergabung dapat memiliki lembar contekan tentang teknologi untuk dipelajari dalam beberapa minggu pertama mereka. Kami menganggapnya sebagai telah dibaca bahwa orang-orang mengetahui hal-hal ini, jadi sebagai permulaan bagi anggota baru, kami akan mencantumkan semua yang kami gunakan setiap hari.
Saya mengharapkan setengah lusin teknologi tetapi berakhir dengan jauh lebih banyak. Daftar ini - 'apa yang kami gunakan' - termasuk CMS biasa, bahasa pemrograman, dan teknologi browser, tetapi juga sekumpulan alat yang bahkan tidak ingat pernah digunakan oleh tim tersebut. Itu semua adalah memori otot. Mengetik 'git', 'phing', 'thor' pada baris perintah, kami bahkan tidak berpikir bahwa seseorang mungkin tidak melakukannya.
Bangun alat; CI; git untuk kontrol versi dianggap biasa, tetapi melihat kembali CV ini hampir tidak muncul. Yang trendi akan muncul (dan apakah itu sinis bahwa menurut saya agensi tertentu menambahkannya ?!) tetapi seringkali tanpa pengalaman konkret.
Alat-alat ini penting untuk mempercepat pengembangan proyek, jadi pastikan Anda memiliki seperangkat alat yang jauh lebih kaya daripada bahasa Anda, CMS, dan beberapa kerangka kerja. Anda memerlukan penerapan, pengujian, CI, kontrol versi yang kuat (dalam tim - bukan Anda sendiri), dan Anda perlu memahami konsep inti dari ini, bukan hanya beberapa tutorial.
05. Devops
Alat dan trik tambahan ini sangat cocok dengan apa yang disebut orang sebagai 'devops'. Devops berhadapan dengan dua silo tradisional: produksi, yang membuat segala sesuatunya tetap berjalan, dan pengembangan, yang membuat barang baru (dan seringkali menghentikan jalannya sesuatu). Silo menghasilkan dua kubu dengan sedikit simpati satu sama lain.
Pengembang tanpa pengetahuan produksi lebih sering menghasilkan kode yang tidak sesuai untuk produksi, dengan menggunakan konfigurasi atau fitur yang belum ada di tumpukan produksi. Karena mereka tidak menyadari masalah lingkungan produksi, mereka membuat kode untuk menyelesaikan fitur daripada menerapkannya ke produksi.
Detail kecil ini dapat membuat penundaan yang menyakitkan, diperburuk oleh tren pengiriman manajemen server ke luar negeri.
Pahami tumpukan
Devops sendiri merupakan bidang yang sangat besar, mencakup penerapan berkelanjutan dan banyak otomatisasi. Ini adalah ringkasan singkat, tetapi hal utama yang perlu dipahami pengembang adalah tumpukan yang mereka jalankan. Tidaklah cukup untuk mendelegasikan ini ke admin server, Anda harus memahami implikasi platform terhadap kode Anda.
Jika Anda bekerja di Rails, baca kode Rails dan ketahui bagaimana Ruby dijalankan oleh Apache. Jika Anda bekerja di Java, ketahui tentang opsi konfigurasi. Jika Anda menggunakan Perl, pahami cara menginstal modul Perl dan mengkonfigurasinya.
Pekerjaan misterius
Daftar 'apa yang kami gunakan' berisi banyak hal ini, dan pengembang yang baik melompat ke sana untuk memahami bagaimana semua pekerjaan misterius ini dilakukan. Dan begitu mereka mendapatkannya, penerapan berjalan lebih cepat, pekerjaan diterapkan dengan lebih lancar, dan semua orang menjadi lebih bahagia.
Penerapan berkelanjutan dan praktik pengembang terkait menjadi sangat standar sehingga pengembang atau perusahaan mana pun yang tidak mempraktikkan hal ini menyiapkan diri mereka untuk diambil alih. Orang lain akan mulai melakukannya dan kemudian mereka akan lebih cepat dari Anda.
Alat yang berguna
Mencari Google untuk 'devops' memberi Anda gambaran tentang alat yang digunakan orang-orang ini. Ini bukan tentang PHP dan MySQL, atau Rails. Ini tentang pengiriman perangkat lunak dan menjaga agar proyek-proyek kecil yang berisiko bebas risiko. Mereka berkonsentrasi pada penerapan, otomatisasi, dan menjaga jalur pipa dari pengembang ke lingkungan produksi berjalan secepat mungkin.
Anda akan menemukan bahwa gaya pengembangan ini memberi Anda pengembang yang bekerja lebih baik satu sama lain dan dengan departemen dan perusahaan lain. Jika mereka bekerja dengan API dari pihak ketiga, mereka akan memahami masalah yang mungkin muncul di sisi lain. Saat bekerja dengan admin server, mereka akan memahami apa yang perlu dipasang dan mengetahui bagaimana situs perangkat lunak mereka di server produksi. Kebalikan dari ini bisa menyakitkan ...
06. Dev akan memperbaikinya ... mungkin
Penelusuran untuk 'keterampilan pengembang web yang penting' itu memberikan jawaban yang bagus dari Michael Greer (CTO The Onion) di Quora:
- Kemalasan: Menolak untuk melakukan apa pun dua kali: menulis naskah atau melupakannya.
- Pengecut: Berpikir untuk menguji, khawatir akan beban dan dampak kode
- Kecerobohan: Terus mencoba hal baru, meluncurkan ide di hari yang sama
Kepengecutan adalah cara yang bagus untuk mengungkapkan 'perhatian terhadap detail'. Debugging dan pengujian adalah 99 persen dari kehidupan pengembang yang tidak disebutkan oleh siapa pun ketika mereka memasuki W3Schools atau memulai kursus komputasi 101.
Kemampuan untuk memperbaiki aplikasi membutuhkan keterampilan pemecahan masalah yang sangat baik, tetapi tidak hanya kode debug. Terkadang solusi bagi pengguna yang tidak dapat mengunduh faktur mereka adalah dengan membuat halaman dapat dicetak, daripada menghabiskan satu hari untuk membuat PDF. Terkadang tautan dapat menggantikan pengembangan selama seminggu, tetapi solusi elegan itu tidak akan terjadi jika pengembang memecahkan masalah hanya dengan menulis banyak baris kode.
Pengujian adalah titik buta yang luar biasa bagi banyak pengembang, meskipun ada banyak alat di luar sana. Gunakan pengujian unit, selenium, pengujian beban, dan alat pembuatan profil seperti xhprof. Analisis dari hal-hal seperti New Relic untuk menjaga footprint aplikasi Anda tetap kecil. Dan anggap ini semua adalah bagian dari pekerjaan pengembang: ini adalah kode Anda, pastikan Anda mengetahuinya berfungsi sebagaimana mestinya, bukan semoga berhasil.
Debugging
Debugging juga merupakan hal yang sulit. Bukan cara menggunakan debugger, tetapi cara men-debug masalah - jadi saya akan menambahkan ke daftar Michael Greer:
- Ketidaksabaran: mengabaikan informasi yang tidak relevan secara agresif untuk menemukan dan memecahkan masalah yang sebenarnya
Ini adalah dasar dari semua teknik debugging. Mengabaikan yang tidak relevan dan menemukan makna yang relevan. Sayangnya, banyak yang cenderung memukuli hal-hal yang tidak relevan selama berjam-jam atau berhari-hari, memperbaiki masalah dengan mencoba hal yang sama 10 kali.
Ada banyak buku (sayangnya, bukan yang saya tawarkan ke penerbit yang tidak akan saya sebutkan) tentang debugging dan setiap pengembang harus membaca semuanya. Pengembang yang sangat hebat dapat men-debug masalah pada sistem tanpa melihat baris kode.
07. Apa yang diinginkan pengguna
Pahami apa yang orang-orang di sekitar Anda coba lakukan. Nikmati kodenya - suka seni membuat indentasi file CSS dengan sempurna, atau mengoptimalkan aplikasi rel - tetapi ingat bahwa itu semua untuk suatu tujuan.
Pengembang perlu memahami bisnis, operasi, dan proses bisnis karena barang-barang mereka membantu menjalankannya. Pengembang dengan pengetahuan ini dapat membuat perangkat lunak dan aplikasi yang membantu pengguna, tetapi mereka sering kali terlihat sangat produktif. Ini mungkin karena pencahayaan mereka yang cepat mengetik atau pengetahuan tumpukan yang luar biasa, tetapi kemungkinan besar karena pengetahuan mereka tentang apa yang diinginkan pengguna.
Pasar yang kompetitif
Kembali ke poin awal saya, bahwa pengembangan menjadi lebih mudah dan pasar untuk pengembang hebat lebih kompetitif, pengembang mana pun yang mampu memahami persyaratan bisnis dan membawa sesuatu yang sangat baik untuk memenuhinya akan memiliki keunggulan. Memahami pasar, pelanggan, dan mengapa mereka berpisah dengan uang semuanya membantu.
Pahami data dan bagaimana data itu akan berubah dari waktu ke waktu. Dalam benak pengembang, mereka harus menyelaraskan teknologi baru dengan tantangan yang Anda hadapi saat ini atau yang akan datang. Dengan cara ini, saat Anda menyarankan ide baru yang keren kepada MD atau klien, hal itu akan didasarkan pada apa yang benar-benar diinginkan pelanggan dan Anda akan mendapatkan anggaran / waktu untuk itu. (Sebaliknya, hal terburuk untuk disaksikan adalah pengembang menjajakan teknologi favorit baru mereka sebagai solusi untuk semua penyakit kita.)
Pengembang memiliki banyak kendali - apakah mereka perlu mengetahui arti setiap bidang dalam database bagi pengguna akhir? Jika kami mengubah data, apa yang akan dilihat pengguna? Adakah cara yang lebih baik untuk membantu pengguna? Terlalu sering pandangan admin DB adalah dunia adalah cerminan buruk dari database mereka daripada database mereka sebagai representasi buruk dari dunia nyata. Dunia ini berantakan dan secara mengejutkan penuh dengan kasus tepi. Atasi itu, admin DB.
08. Menggambar dan menulis
Menggambar adalah cara paling langsung untuk mengkomunikasikan seperti apa benda itu nantinya. Pengembang harus dapat menggambar idenya di papan tulis, kertas, dan alas bir.
Pengembang harus dapat membuat prototipe di atas kertas, mencetak tangkapan layar, dan mencoret-coretnya hanya untuk mengomunikasikan niat mereka. Jangan mempercayai pengembang yang mengangguk, mengatakan bahwa mereka memahami dan membuka editor mereka.
Gagal dengan murah: pengkodean terbaik dimulai dengan menggambar sebagai prototipe cepat. Lebih sering gagal dan pastikan semua developer di sekitar Anda melakukan hal yang sama karena kemungkinan besar Anda akan berhasil dengan cara itu.
09. Nikmati diri Anda sendiri
Dan bagaimana jika Anda harus menghabiskan 10 jam untuk memecahkan masalah dengan memindahkan tautan? Nikmatilah - meskipun itu hanya tantangan untuk menyelesaikan pekerjaan.
Sikap paling buruk dari pengembang (atau siapa pun) adalah sikap apatis terhadap apa yang ingin dicapai oleh tim. Sayangnya ini biasa terjadi, karena pengembang melihat diri mereka berada di luar pencapaian tim. (Programmer yang Bergairah mengajukan pertanyaan, 'seberapa menyenangkankah Anda dapat melakukan pekerjaan Anda?' - cobalah.)
Dan bersiaplah untuk menunjukkan pekerjaan Anda sebagai kebalikan dari ini: jangan memperluas setelah mencoba beberapa tutorial tentang Ruby ke 'Pengalaman Ruby'!
Pengembangan web dan aplikasi masih merupakan profesi yang masih muda, tetapi keahlian yang sangat dibutuhkan developer terus berkembang. Setiap orang harus mengharapkan lebih banyak pengembang karena semakin cepat kita semua keluar dari ruang belakang yang buruk dan terlibat dengan proses kreatif, semakin baik hasilnya.
10. Tetap tajam
Untuk membawa ini ke babak 10 yang bagus, saya akan menambahkan satu hal terakhir. Tetap tajam. Temukan persaingan. Jenis yang paling buruk adalah yang terisolasi.
"Selalu menjadi orang terburuk di setiap band yang kamu ikuti."
Yang terburuk - sungguh, sangat buruk - programmer, pembuat kode, desainer mempelajari hal-hal mereka dan berpuas diri. Tanpa alat pacu jantung, terlalu mudah untuk memperlambat dan tanpa melihat persaingan, menjadi kebiasaan untuk melihat diri Anda di atas rata-rata.
Jadi, jadilah yang terburuk dengan menemukan yang lebih baik. Bergabunglah dengan proyek di luar pekerjaan, berkontribusi dan cari umpan balik dan kritik karena semakin banyak kritik yang Anda dapatkan, semakin sedikit orang yang akan memberi Anda di masa depan. Saat Anda menebak apa yang mereka inginkan lebih baik dari yang sebenarnya, Anda adalah pengembang ninja yang diinginkan semua orang.
Dan Frost adalah direktur teknis perusahaan web layanan lengkap 3EV, mitra AWS resmi. Dia telah bekerja di CMS dan pengembangan aplikasi web selama tujuh tahun.
Suka ini? Baca ini!
- Cara membuat aplikasi
- Font web gratis terbaik untuk desainer
- Temukan apa yang selanjutnya untuk Augmented Reality
