Ada banyak perdebatan tentang apa itu layak belajar bahasa pemrograman untuk berkarir di bidang pengembangan. Tetapi saya sangat yakin bahwa bahasa pengetahuan yang diperlukan tidak terbatas. Sayangnya, tidak semua orang mengerti hal ini.
Dalam diskusi tentang tugas, bisnis dan pengembang berbicara berbagai bahasa.
Dari sudut pandang bisnis, tidak masalah sama sekali bahasa mana tugas mereka akan diselesaikan. Bisnis tidak berpikir, dan bahkan mungkin tidak tahu tentang java, go, ruby dan bahasa serta teknologi lainnya. Ini bagus untuk pengembang, tentu saja, ketika proyek berskala besar dan menarik dimulai dari awal dan tumpukan teknologi dipilih oleh tim. Tetapi di dunia nyata, jauh lebih sering hal ini tidak terjadi. Biasanya, perusahaan sudah memiliki keahlian dalam tumpukan tertentu, yang tidak ingin ditolak oleh eksekutif TI. Alasannya bisa sangat berbeda, dari larangan “kebun binatang teknologi” hingga preferensi pribadi pembuat keputusan. Ada beberapa faktor tambahan, seperti kebutuhan akan teknologi yang menarik bagi tim, untuk menarik dan mempertahankan personil yang berkualitas.
Untuk bagian mereka, pengembang sering menyatakan keinginan untuk berkembang dalam tumpukan teknologi tertentu. Niat ini diperkuat oleh perbedaan besar antara gaji untuk beberapa bahasa. Jadi ada orang yang hidup keras, misalnya, dalam kerangka Java atau Python (Go, Kotlin, Scala ... daftarnya berjalan terus dan hampir tanpa henti) dan bahkan Delphi, tanpa mencoba melihat apa lagi yang ada.
Menurut pendapat saya, keinginan untuk masuk lebih dalam adalah berjasa. Tetapi kadang-kadang "hutan hilang di balik pohon" - dalam proses penyelaman ini, spesialis hanya lupa bahwa teknologi hanyalah alat untuk menyelesaikan masalah bagi bisnis. Akibatnya, kebutaan pada satu tumpukan teknologi lengkap dengan perfeksionisme bawaan ("mari kita lakukan refactoring selama enam bulan untuk proyek yang tidak memiliki rencana pembangunan yang serius, hanya karena itu akan indah") tidak mencerminkan dengan cara terbaik pada kualitas keputusan yang dibuat.
Maksud saya adalah bahwa bahasa pemrograman tertentu adalah sekunder. Pemahaman utama tentang prinsip-prinsip pengembangan dan kemampuan untuk memecahkan masalah bisnis adalah primer - pengetahuan tentang pendekatan dan pola yang membantu mensistematisasikan kerja keseluruhan, pengalaman menggunakan berbagai teknik, termasuk yang tim. Dengan bagasi seperti itu, satu bahasa lagi yang diperlukan dalam proyek khusus ini tidak sulit untuk dikuasai. Di depan mata saya ada banyak contoh tentang bagaimana orang melatih kembali ke tumpukan lain selama sebulan - dua pelatihan intensif. Tentu saja, lebih sulit untuk beralih antar bahasa dengan paradigma yang berbeda, misalnya, dari fungsional ke berorientasi objek, tetapi di sini tidak ada yang mustahil jika seseorang tidak menentang peralihan semacam itu "pada tingkat keyakinan".
Mengetahui beberapa bahasa, untuk setiap tugas bisnis tertentu, Anda dapat memilih pendekatan Anda sendiri untuk menyelesaikan - yang tidak hanya cocok, tetapi akan optimal dalam kasus khusus ini. Dan semakin banyak arsenal pengembang memiliki basis dari pendekatan ini (bahasa), semakin luas masalah yang dilihat dan semakin dimotivasi tumpukan yang dipilih. Inilah yang dibutuhkan oleh bisnis - untuk mendapatkan solusi yang paling cocok untuk tugas-tugas mereka.
Tetapi dengan pengetahuan yang mendalam tentang satu bahasa, tetapi tanpa kemampuan untuk memecahkan masalah bisnis, seorang spesialis akan mendapat manfaat jauh dari tim mana pun. Tentu saja, dalam proyek-proyek individual, pengetahuan mendalam tentang "keping" bahasa membantu tim secara keseluruhan mencapai kinerja yang lebih besar. Tetapi lebih sering anggota tim yang tahu satu bahasa, tetapi tidak dapat mendengarkan bisnis, hanya akan memperlambat rekan. Dan omong-omong, "panduan berjalan menuju peluang yang tidak jelas" seperti itu sering, jika dibutuhkan dalam tim tertentu, hanya satu (kami menarik kesimpulan tentang permintaan untuk spesialis sekecil itu di pasar tenaga kerja).
Kemampuan untuk memecahkan masalah bisnis sebenarnya adalah bagian dari esensi yang lebih global - pengalaman kerja yang komprehensif. Anda bisa mendapatkan keduanya dengan majikan, dan sebagai bagian dari proyek rumah. Benar, menurut saya, hanya proyek bisnis (di mana ada pelanggan, anggaran, tenggat waktu) yang dapat memberikan umpan balik yang sangat diperlukan dalam situasi seperti itu, mengevaluasi kualitas solusi. Yaitu, ini menentukan kedalaman pengalaman yang didapat. Tidak ada orang yang mendapat umpan balik dari proyek rumah: Anda sendiri melakukan sesuatu dan pada saat tertentu memutuskan sendiri bahwa Anda melakukannya dengan baik. Di sinilah semuanya berakhir. Tetapi ketika proyek diimplementasikan untuk bisnis, solusi yang dikembangkan tidak memadai akan dikirim untuk revisi,
lagi dan lagi, jika perlu. Dan dalam perjalanan iterasi ini, Anda pasti akan belajar beberapa pendekatan untuk masalah ini - Anda akan mendapatkan pemahaman tentang tingkat yang lebih tinggi.
Salah satu komponen kemampuan untuk memecahkan masalah bisnis adalah memahami tugas ini. Dan karena cukup sering pengembang Rusia berpartisipasi dalam proyek asing, pengetahuan bahasa Inggris diperlukan untuk pemahaman ini. Dalam hal ini, Anda tidak selalu dapat mengandalkan analisis bisnis, karena tidak ada cukup spesialis yang baik di bidang ini di pasar.
Pemahaman yang lebih baik tentang bisnis membantu perendaman dalam suatu industri. Ketika Anda tidak hanya membuat modul abstrak yang menerima, memproses dan mengirim paket data ke tujuan yang tidak diketahui, tetapi menerapkan, katakanlah, bagian dari sistem penagihan yang kompleks atau sistem perbankan, di mana terdapat berbagai jenis pengguna, standar, dan fitur lainnya. Mengetahui detail ini sangat berharga. Perendaman semacam itu mengajarkan Anda untuk tertarik pada apa yang terjadi di sekitar bagian tugas Anda. Ini membantu menemukan solusi terbaik. Saya kenal spesialis yang tidak akan pernah mengerjakan tugas yang tidak jelas sebabnya. Dan di beberapa bidang pengembangan bisnis untuk pengembang, pelatihan internal wajib disediakan, karena tanpa pencelupan, pada prinsipnya, kerja yang efektif tidak akan berhasil.
Sebagai tambahan kecil untuk pemahaman yang lebih baik tentang masalah bisnis, saya sarankan menghadiri konferensi khusus industri. Di sana, pembicara berbagi pengalaman mereka tentang bagaimana mereka memecahkan masalah bisnis menggunakan teknologi IT. Seringkali dari sana Anda bisa mendapatkan informasi berguna tentang arah mana yang harus dipindahkan. Meskipun, tentu saja, tidak ada yang perlu mengulangi pengalaman orang lain secara detail.
Saya tidak mengatakan bahwa setiap pengembang harus mengurus tugas bisnis. Juni hanya masuk ke dalam lingkaran ini, pada tahap awal dibutuhkan terlalu banyak waktu untuk berkomunikasi dengan kolega dan belajar bagaimana menyelesaikan masalah tertentu. Tidak ada waktu untuk memperluas wawasan. Tetapi mulai dari tengah, pengalaman sebelumnya membentuk pemahaman tentang sisi mana yang mendekati tugas dari jenis tertentu. Pada tahap ini, pertanyaan tentang ekosistem pengembangan tidak lagi muncul - kapan dan status apa yang harus ditetapkan, bagaimana menanggapi ulasan kode, dll. Spesialis mulai mengatasi bahkan dengan tugas-tugas asing lebih cepat - inilah saatnya untuk "menarik" komponen bisnis. Bahkan, senior dari tengah dibedakan oleh pemahaman tentang pendekatan untuk memecahkan masalah bisnis yang umum. Dan keinginan untuk pemahaman seperti itu membantu untuk bergerak ke tingkat berikutnya lebih cepat.
Karena itu, saya mendesak untuk menetapkan tujuan pengembangan secara bersamaan dalam dua arah. Di satu sisi, pelajari bahasa, dan di sisi lain, dapatkan pengalaman dalam memecahkan masalah bisnis tertentu. Dan dalam perkembangan ini perlu untuk menjaga keseimbangan, jika tidak akan cukup sulit untuk menemukan tempat di dunia senior. Tetapi di mana tepatnya untuk berkembang - ke arah arsitek, pengembang atau pemimpin tim yang sangat kuat - tergantung pada ambisi dan kualitas pribadi (kerja tim, tanggung jawab, kemampuan bersosialisasi, dll.) Dari spesialis tertentu.
Apa yang Anda pikirkan tentang ini?
Penulis artikel: Sergey Marina
PS Kami menerbitkan artikel kami di beberapa situs Runet. Berlangganan ke halaman kami di
VK ,
FB atau
saluran Telegram untuk mencari tahu tentang semua publikasi kami dan berita Maxilect lainnya.