Hai Pemrograman adalah subjek yang kompleks, dan pengembangan perangkat lunak industri sangat kompleks. Dalam industri IT kami, tidak jarang mendengar pertanyaan dari rekan-rekan junior dalam seri "Bagaimana saya berkembang?", "Apa yang harus saya lakukan untuk menjadi profesional tingkat tinggi dan secepat mungkin?", "Apa yang harus saya lakukan jika saya tidak dapat berkembang, tetapi tidak ada proyek yang menarik? "," apa yang harus diketahui tengah? ". Jika Anda memiliki dari 0 hingga 3 tahun pengalaman di bidang TI, Anda adalah seorang spesialis pemula (atau baru saja akan menjadi salah satu) dan menetapkan tujuan yang serupa untuk pertumbuhan profesional dan karier, mencari cara yang tepat untuk mencapai tujuan ini - posting ini untuk Anda, bagus mengeluh di bawah kucing. Mungkin dia juga akan menarik bagi para pemimpin tim dan manajer, secara umum, untuk semua yang terlibat dalam pelatihan dan pengembangan spesialis.
Untuk memulai, izinkan saya memperkenalkan diri. Nama saya Anatoly, dan jika saya menghilangkan posting dan pangkat, maka pertama-tama saya adalah seorang Pengembang, karena dalam arti luas kata saya telah terlibat dalam pengembangan, penelitian dan manajemen pengembang sepanjang karier saya. Pengalaman industri saya adalah 10+ tahun. Ini cukup beragam dan meluas dari sistem keuangan dan situs web ke produk, algoritma dan sistem pembelajaran mesin. Namun, hal utama yang menurut saya adalah bahwa saya sendiri berada di tempat pembaca target artikel ini dan kemudian mulai terlibat dalam berbagai aspek pengembangan programmer muda. Saat ini, total lebih dari 2 lusin pengembang junior dan magang telah melewati saya. Karena itu, saya percaya bahwa saya memiliki sesuatu untuk dibicarakan. Sejumlah besar materi tentang masalah yang sedang dibahas yang dapat ditemukan dikhususkan untuk topik-topik teknis semata, atau, misalnya, untuk hampir secara membabi buta mengikuti Scrum. (seperti - "jika Anda tidak tahu apa yang harus dilakukan, cobalah untuk mengerjakan scrum dan semuanya akan terluka" :)) Seolah-olah dari realitas dan statistik masing-masing tim dan spesialis, itu jauh dari semua hal yang membentuk praktik dan budaya pengembangan perangkat lunak. Oleh karena itu, memikirkan apa yang harus ditulis, saya memutuskan untuk tidak mengulangi informasi ini, tetapi saya akan mencoba untuk fokus pada topik yang tidak banyak ditulis atau dibicarakan. Ayo pergi!
Ya, sebagai penafian , saya ingin mengatakan bahwa yang dijelaskan adalah pendapat pribadi saya, dikonfirmasi oleh pengalaman dan pengetahuan teoritis, yang telah diuji pada pengalaman ini. Ini mungkin tidak sesuai dengan kenyataan di mana Anda menemukan diri Anda sendiri, jadi izinkan saya memberi Anda tip pertama artikel itu: pertama-tama, dalam situasi sulit apa pun perlu dianalisis desainnya sebelum menerapkan praktik dan pola yang dikenal oleh Anda seperti “jika, lalu. " Detailnya sangat penting. Sekarang ayo pergi! :)
1. Spesialisasi Luas vs Sempit
Seringkali orang yang hanya ingin belajar bagaimana memprogram bertanya pada diri sendiri teknologi apa yang harus dipilih untuk belajar, dan memang, dalam bahasa apa, secara kasar, "lebih baik menulis kode." Orang-orang yang mendapatkan pekerjaan pertama mereka berpikir tentang apakah teknologi mereka saat ini akan menjanjikan dan diminati dalam beberapa tahun ke depan. (beberapa - mereka tidak berpikir sama sekali, tetapi ini paling sering tidak baik) " Lebih baik " dan "lebih menjanjikan " di sini adalah konsep yang sangat subyektif, didefinisikan pada tingkat perasaan dan kemungkinan manfaat untuk karir lebih lanjut. Cukup cepat, mungkin menjadi jelas bagi pendatang baru di IT bahwa banyak proyek dilakukan pada sejumlah besar teknologi, dan tidak mungkin untuk mengetahui segalanya. Jadi perlukah mengejar semua kelinci?
Sebagai contoh, pada tahun pertama saya bekerja, saya menerima komentar yang berharga dari ketua tim saya bahwa perlu untuk fokus pada satu bidang tertentu, karena spesialis adalah spesialis dalam sesuatu atau, secara kasar, bukan spesialis dalam apa pun. Untuk mengetahui sesuatu pada tingkat yang cukup tinggi, Anda perlu melakukan ini secara terus-menerus dan mendalam menggali detail - kebenaran murni dan sulit untuk berdebat dengan itu. Memang, praktik menegaskan hal ini: sebagian besar spesialis yang saya tahu (yang dapat dianggap demikian) adalah spesialis yang sempit. Beberapa dari mereka hanya dengan cemerlang mengetahui Subjek mereka dan karenanya memecahkan masalah kecuraman yang belum pernah terjadi sebelumnya di dalamnya. Pada titik ini orang dapat mengatakan "Oke, itu berarti prinsipnya benar - semuanya cocok bersama", jika tidak untuk beberapa NAMUN. Faktanya adalah bahwa berbagai proyek di mana spesialis sempit akan diminati jauh lebih sempit daripada, tentu saja, di antara spesialis dari profil yang lebih luas. Lebih dari sekali saya telah bertemu proyek di mana partisipasi tidak mungkin tanpa ketersediaan pengetahuan luas dalam beberapa teknologi sekaligus. Orang yang memiliki pengetahuan ini menemukan pintu baru yang terkadang tidak dapat diakses. Dan partisipasi dalam proyek luar biasa dan unik adalah ujian karir yang sangat serius dan bermanfaat yang dapat memberi Anda banyak pengalaman berharga dan manfaat lainnya. TETAPI kedua adalah bahwa dunia teknologi terus berubah dan secara ketat membatasi diri pada pengetahuan tentang satu atau dua teknologi atau PL, Anda secara alami dapat mulai kehilangan keunggulan kompetitif Anda dan menjadi spesialis yang kurang dicari.
Singkatnya, kita dapat mengatakan ini secara singkat: jangan takut untuk mencoba teknologi yang Anda suka! Anda mungkin tidak menjadi ahli dalam 3 bahasa pemrograman sekaligus, atau dalam 5 kerangka kerja, tetapi pengetahuan tentang dasar-dasar dan struktur internal mereka adalah keunggulan kompetitif yang serius, jika, jika semuanya sama, Anda mendapatkan pekerjaan yang membutuhkan pengetahuan yang kuat tentang 1 teknologi dan dasar beberapa lainnya. Hal utama di sini adalah ukuran dan batasan. Penting untuk memprioritaskan dengan jelas teknologi apa yang paling banyak Anda habiskan untuk belajar, dan apa yang tersisa untuk mempelajari teknologi mana.
2. Area fungsional
Dari spesialisasi dalam bahasa pemrograman dan teknologi pengembangan, kami dengan lancar beralih ke hal penting berikutnya - bidang fungsional . Sangat mudah untuk memberikan contoh dari kehidupan: sama seperti dokter memiliki dokter gigi, dan ada ahli jantung, jadi ada spesialisasi di antara pengembang, dan ini bukan hanya tentang teknologi atau bahasa pemrograman yang disebutkan di atas. Pengembang mengkhususkan diri dalam berbagai cara: seseorang berurusan dengan antarmuka pengguna, seseorang memproses data pada cluster, seseorang mengenali gambar, dan seseorang menulis logika untuk bot permainan. Banyak contoh.
Mungkin dalam 2 tahun pertama kerja, atau bahkan lebih, Anda tidak akan terganggu oleh masalah spesialisasi, karena memasuki proyek dan teknologi yang Anda masuki akan memakan banyak waktu, dan masalah ini tidak akan relevan secara alami. Namun, mulai dari saat tertentu, Anda akan merasakan kemudahan dalam menyelesaikan masalah yang semakin kompleks di area tertentu, dan hasilnya akan ditentukan dalam banyak hal, bukan pada tingkat perinciannya, misalnya, Anda tahu perpustakaan standar bahasa yang dengannya Anda bekerja, atau seberapa mahir Anda memiliki sintaksis lanjutan dari PL ini, dan pengalaman Anda di bidang fungsional tertentu. Grafik komputer, linguistik komputer, pemrograman keuangan - semua ini adalah bidang khusus untuk studi ini dan mendapatkan pengalaman praktis yang memakan waktu berbulan-bulan dan bertahun-tahun. Jika Anda menetapkan tujuan untuk menjadi spesialis tingkat tinggi, temukan area yang Anda sukai. Dan jika Anda benar-benar menyukainya - kembangkan dan kerjakan dengan senang hati, dan semuanya akan berhasil!
3. Mentor dan belajar mandiri
Tidak ada dua proyek yang sepenuhnya identik. Tidak ada tim yang identik. Terkadang tidak ada solusi tunggal yang tepat, baik itu keputusan global tentang arsitektur sebagian besar sistem atau keputusan lokal tentang cara menyimpan file dalam repositori. Seorang spesialis pemula menghadapi banyak pertanyaan dan keraguan. Pertanyaan itu, karena kurangnya pengalaman, mungkin tidak segera dijawab. Anda mendapat kode yang sudah jadi dan tidak berfungsi sama sekali, meskipun rekan lain baik-baik saja; prosedur instalasi layanan dalam 1 kasus dari 6 berakhir dengan kesalahan - dan setidaknya bunuh diri, tetapi tidak jelas mengapa; Anda tidak dapat mengonfigurasi bagian jaringan dari layanan, meskipun Anda melakukan segalanya sesuai dengan instruksi dan membaca ulang 7 kali. Situasi seperti itu untuk pengembang, penguji dan admin muncul secara konstan. Tingkat kesulitan masalah dapat bervariasi dari tingkat "mungkin Anda perlu menggali di suatu tempat" hingga "di mana menggali - itu sama sekali tidak jelas." Nasihat pertama yang dikenal dan diberikan oleh para profesional yang berpengalaman (dan Anda mungkin sudah mendengar dari mereka) adalah bahwa Anda perlu belajar bagaimana menangani masalah secara mandiri mungkin ketika Anda terjebak di dalamnya. Sebagai aturan, untuk ini perlu berkonsentrasi pada hubungan sebab akibat dan belajar merumuskan pertanyaan yang tepat tentang masalah tersebut. Pertama-tama, untuk dirinya sendiri, dan kedua, ke Google. Ini bukan hanya “semuanya tidak berfungsi”, bahkan jika Anda yakin akan hal itu, cobalah untuk kembali “ke awal” untuk menemukan penyebab sebenarnya dari masalah tersebut. Dan, kemungkinan besar, Anda bukan satu-satunya dengan masalah yang sama, hanya google saja dan lihat sendiri. Selanjutnya, saran sederhana berikut: hanya setelah Anda melakukan beberapa upaya yang gagal dan menganalisis masalah Anda sendiri, setelah menghabiskan waktu yang signifikan (biasanya diukur dalam jam, kadang dalam beberapa hari), hubungi kolega senior. Jadi Anda tidak akan menghabiskan waktu berharga mereka untuk menyelesaikan masalah omong kosong, yang Anda sendiri dapat dengan mudah menyelesaikannya dengan menggunakan banyak ketekunan. Dengan cara ini, Anda akan menunjukkan bahwa Anda telah mengembangkan pendekatan yang tepat untuk menyelesaikan masalah. Banyak masalah yang tampak rumit dan tidak dapat dipahami pada pandangan pertama diselesaikan dengan googling dalam arti harfiah 5 menit.
Tetapi berbicara itu mudah, tetapi dalam kenyataannya tidak cukup pengetahuan tentang teknologi pengembangan dan kurangnya pengalaman praktis akan menjadi faktor yang sangat menyakitkan. Oleh karena itu, tugas nomor 1 yang benar adalah studi tentang teknologi pengembangan dan contoh penggunaannya dalam mode yang cukup intensif. Dan lagi: mudah untuk mengatakannya, tetapi sebenarnya ada lebih banyak bahan pelatihan, tidak semuanya dapat dipahami, tidak semuanya relevan, tidak semuanya membahas masalah yang harus dipecahkan dalam praktik pada proyek. Dan di sini lingkungan dapat membantu Anda. Untuk berada di tim "ahli" yang tidak hanya memiliki tingkat pengetahuan yang tinggi, tetapi juga bersedia untuk dengan terampil berbagi pengetahuan ini - ini adalah yang terbaik yang bisa di awal karir. Ya, itu benar, pertama-tama Anda harus fokus pada belajar mandiri, tetapi dengan satu atau lain cara, Anda akan memiliki langit-langit alami untuk kecepatan. Mentor yang kompeten akan membantu mengatasinya. Namun, sebelum Anda menoleh ke mereka, tanyakan pada diri Anda pertanyaan: apakah Anda benar-benar terjebak dan tidak bisa maju secara mandiri dalam memecahkan masalah setidaknya satu langkah?
Total: cari pekerjaan di mana ada orang yang tahu subjeknya dan tertarik untuk membuat Anda lebih mengenalnya! Ini akan memungkinkan Anda untuk secara signifikan meningkatkan tingkat keahlian Anda dalam waktu yang cukup singkat. Hindari tempat-tempat di mana Anda sama sekali tidak siap untuk berbagi pengetahuan. 4 tahun bekerja di tempat seperti itu akan sama dengan dua (atau kurang) di tempat lain.
4. Tidak ada peluru perak
Bekerja di industri TI adalah dialog yang konstan, debat, kadang-kadang perjuangan pendapat, dan kadang-kadang perang prinsip. Percayalah, Anda akan bertemu banyak orang yang akan meyakinkan Anda bahwa mereka dan hanya mereka yang memiliki keputusan atau pendapat yang paling benar, mendukung atau tidak mendukungnya dengan fakta. Terkadang perasaan ini juga akan menghancurkan Anda!
Apakah mungkin atau tidak mungkin menyelesaikan tugas tepat waktu? Mana yang lebih baik: teknologi A atau teknologi B untuk tugas C? Menurut metodologi apa layak mengembangkan proyek dan mengatur proses kerja? Apakah kode tertulis cukup baik dan apakah sudah saatnya berhenti memolesnya, atau apakah masih perlu refactoring? Apakah Anda mengambil kesempatan untuk memperluas sistem dari awal, bahkan jika ekspansi tidak diharapkan, dan Anda tidak melihat keseluruhan gambar dari tingkat pengembang junior Anda? Bagaimana cara mengevaluasi kualitas produk dan peran apa yang dimiliki pengembang dalam proses ini? Dan selusin atau dua pertanyaan serupa yang berbeda.
Seringkali, tidak mungkin untuk memberikan solusi yang jelas untuk ini dan banyak pertanyaan lain dalam situasi tertentu. Saya ingin memilikinya, tetapi kadang-kadang tidak terlihat secara objektif, karena tingkat ketidakpastian pada proyek bisa sangat tinggi. Dalam arti tertentu, ini bertentangan dengan satu budaya tak terucapkan yang diterima secara luas dalam pemrograman: pencarian terus-menerus dan menawarkan solusi yang lebih baik menggunakan teknologi yang lebih maju. Kami terus-menerus secara naluriah memaksa diri untuk mengambil keputusan berdasarkan data yang tidak lengkap.
Dan di sini, pemrograman dalam mikrokosmosnya dan pengembangan proyek-proyek TI yang sudah dalam skala besar berhenti menjadi disiplin ilmu yang sewenang-wenang dan mulai menjadi seni. Seni dibangun berdasarkan prinsip dan pendekatan, itu ditentukan oleh mereka.
Ketika menyelesaikan proyek lain atau tugas yang kurang masif, lihat kembali dan analisis: prinsip apa yang telah membantu tugas ini atau proyek ini berhasil (atau sebaliknya - zafeylyat)? Apakah itu pertanyaan tentang bahasa pemrograman mana yang dipilih dan bagaimana cara kerjanya dengan luar biasa, atau mungkin tingkat interaksi dengan pelanggan atau mitra Anda sangat baik sehingga Anda dapat menangani tugas sebagian besar waktu tanpa membuang waktu biaya komunikasi? Secara konstan menganalisis, mencari prinsip-prinsip baru dan berkonsultasi dengan mentor bagaimana melihat dan mendefinisikan prinsip-prinsip ini.
5. Tentang perusahaan besar dan kecil, tentang TI dan bukan TI
Banyak profesional muda ingin bekerja di perusahaan yang pernah mereka dengar dan produk atau produk yang mereka gunakan. Di beberapa Apple, Google, atau Microsoft (baru-baru ini istilah yang baik telah muncul - "Guyandbuk") atau rekan-rekan Rusia mereka (sebanyak mungkin). Memulai karir di perusahaan besar adalah pengalaman yang sangat, sangat berharga. (Anda memahami ini terutama pada tahun ke-11 pengalaman ini :)) Untuk melihat bagaimana sebuah perusahaan besar bekerja dari dalam dan bagaimana proses diorganisasikan di dalamnya - percayalah, itu sangat berharga. Mungkin, sulit bagi saya untuk membayangkan sesuatu yang lebih baik daripada seperangkat perusahaan IT besar dan tim cerdas di awal karir saya. Namun, selalu ada NAMUN.
NAMUN pertama adalah bahwa "perusahaan IT besar" sangat berbeda dari hanya "perusahaan besar" (terutama dalam realitas Rusia). Jika Anda punya pilihan, pergi ke perusahaan IT kecil atau menengah atau pergi ke perusahaan non-IT besar (misalnya, bank atau perusahaan keuangan atau perdagangan lainnya), Anda harus memahami konsekuensi yang mungkin terjadi. Dan konsekuensi dalam kasus terburuk adalah sebagai berikut: jika perusahaan IT tutup atau Anda ingin meninggalkannya, Anda pergi dengan pengetahuan dan prinsip-prinsip. Jika Anda ingin meninggalkan bukan dari perusahaan IT ke perusahaan IT, maka untuk sejumlah alasan ini akan membuatnya lebih sulit. Ini mungkin adalah kurangnya pengalaman yang diperlukan dan relevan, dan kekhususan proyek dan pilih-pilih perekrut dan mempekerjakan rekan untuk pekerjaan masa lalu Anda (ingat perusahaan Pearson Hardman dari seri terkenal yang hanya disewa dari Harvard. Cerita seperti itu tidak biasa dan pada kenyataannya. Jenis "kami hanya menyewa dari perusahaan makanan ", dll.). Di perusahaan di mana TI bukan jenis bisnis utama, semuanya benar-benar berputar di sekitar bisnis ini. Hasilnya sangat penting, proses mencapainya tidak terlalu penting. Tetapi itu adalah proses yang tepat yang menetapkan prinsip-prinsip yang benar, yang kemudian membantu Anda membuat keputusan dan menghasilkan sesuatu yang sangat berkualitas tinggi dan kompleks dalam hasil proyek yang agak rumit. Jika Anda menghasilkan sesuatu yang berkualitas tinggi dan berguna - ini adalah tujuan Anda, pertimbangkan ini.
6. Perusahaan makanan dan outsourcing
Salah satu topik favorit saya, karena saya bekerja di bagian pertama dan kedua. Melanjutkan topik pilih-pilih, ada pendapat tertentu di industri bahwa bekerja di perusahaan IT pangan tidak hanya lebih bergengsi, tetapi juga secara finansial, dan ini juga dilengkapi dengan serangkaian proyek paling menarik yang dapat Anda temukan. Pekerjaan outsourcing pada proyek sesuai pesanan, menurut beberapa ahli, adalah kelas yang lebih rendah. Apakah ini benar atau tidak?
Saya akan menjawab: Tidak. Tidak sesederhana itu.
Keuntungan utama dari perusahaan makanan adalah bahwa seseorang yang datang ke sana sebenarnya memiliki kesempatan untuk memilih proyek / produk atau bidang kegiatan, dengan semua konsekuensi yang mengikuti dari ini (misalnya, kemampuan untuk bekerja pada tugas yang benar-benar unik dan kompleks). Salah satu konsekuensi utama: Anda akan mengembangkan produk ANDA, menjadikannya lebih baik setiap hari. Ini tidak akan selalu berjalan sederhana dan seperti yang Anda inginkan, tetapi ini adalah produk Anda. Anda sangat memengaruhi keberhasilannya, setidaknya di level Anda.
Dalam perusahaan outsourcing, sebagai suatu peraturan, seorang karyawan tidak memiliki pilihan seperti itu, dan terlebih lagi, ia secara berkala dipaksa untuk duduk di atas jarum karena hal ini. Integrator dan agen outsourcing terlibat dalam proyek-proyek yang mereka bayar uang di sini dan sekarang. Tidak semua proyek seperti itu akan menarik bagi kelas programmer tertentu. Untuk karyawan dari perusahaan outsourcing, selalu ada risiko berada pada proyek yang sama sekali tidak menarik dan stagnan, dan, seringkali, satu-satunya cara untuk mengubah proyek adalah meninggalkan perusahaan.
— legacy ( ), . — . 5 . , , , .
7. vs
. : . , . , , . , – . , ( ) , . , , , . , . , , () () . . ? – . – . , , 2 : ) ) ( ). : , . , . , , , , , . – .
: - ( - ) , - . - , ( — , ) – .
8.
. , , - . - , . , , , . . . , . , . — . .
— , , , , . , , , , ( ), : , — , , .
? , ? .
, ? : , , , , , , , .
9.
(, ) , backend . (, Web , ). - . , ? , . , . , — . — . , . : , , . . , . , , . . , : , , UX/UI — , , , , .
10.
: . . - : , .
, , . : 1.5-2 . , , , , . . , 1-2 , - . — 4 , ? : , B. , . , , . , . , , — , , . , , , , .
: 1-3 , , . : skills 3 — 1. , — 2. — 3. , , , , 4 , , .
Kesimpulan
— , , . , . , , — . . , , ! , : ) hard skills ) c ) . , !
PS: . , , , .