Kebiasaan adalah kekuatan yang mengerikan. Itu membuat Anda menolak perubahan, menghambat perkembangan. Namun di bidang TI, kami senang berada di garis depan teknologi, kami menyukai tantangan, kami senang menerapkan apa yang akan menyebar ke bidang lain hanya dalam beberapa tahun.
Kami siap untuk yang baru dan mungkin tidak menunggu sampai masa depan datang, dan kami harus beradaptasi dengannya. Kita bisa maju, hanya tahu ke arah mana.
Egor Bugaenko tahu apa yang perlu dilakukan sekarang untuk tetap menjadi programmer yang dicari dalam 5-10 tahun. Gagasannya, seperti biasa, mungkin tampak kontroversial. Anda tidak perlu menyetujui tanpa syarat dengan mereka, tetapi untuk berpikir, misalnya, tentang proyek hewan peliharaan tidak akan sakit lagi. Dan fakta bahwa programmer membutuhkan bahasa Inggris, hampir tidak ada pendapat yang berbeda. Tetapi pada poin yang tersisa akan menarik untuk mengetahui pendapat masyarakat dalam komentar.
Berikutnya adalah versi teks dari laporan Egor di
AppsConf , tetapi ia merujuk tidak hanya dan tidak begitu banyak pada pengembangan ponsel, tetapi juga pada industri secara keseluruhan. Egor Bugaenko, pendiri Zerocracy, pengembang Cactoos, Takes Framework, JCabi dan proyek sumber terbuka lainnya. Dia menulis serangkaian buku yang disebut "Benda Elegan", memelihara
blog yang provokatif
, dan memberikan laporan yang membangkitkan pemikiran seperti ini.
Saya akan mulai dengan sebuah cerita tentang bagaimana belum lama ini saya memutuskan untuk mulai mengembangkan perangkat lunak untuk perangkat seluler dan dengan cepat bertabrakan sehingga saya tidak tahu bagaimana melakukannya. Karena itu, saya memutuskan untuk meminta bantuan dari seseorang yang akan memberi tahu saya cara membuat aplikasi dalam bentuk yang sangat lengkap. Artinya, buat aplikasi yang akan tersedia di Apple Store.
Saya bertanya-tanya bagaimana cara merakit aplikasi dalam satu paket, yaitu, tidak hanya menggambar beberapa tombol di layar, tetapi untuk membuat
seluruh aplikasi . Jelas, kode, misalnya, pada Swift dan produk di ponsel, adalah dua hal yang sangat berbeda: yang pertama sangat kecil, dan yang kedua sangat besar dan mencakup pertanyaan-pertanyaan seperti:
- Tes unit
- analisis statis;
- Integrasi berkelanjutan
- manajemen ketergantungan;
- Pengiriman terus menerus;
- Lingkungan Pementasan;
- Aplikasi menyetujui proses di Apple Store
- proses merakit cacat dari produksi, dll.
Cara mengatur tombol-tombol di layar mudah dibaca di Internet. Saya membutuhkan seorang spesialis, seorang ahli yang akan membantu saya mengumpulkan seluruh pipa. Bagi saya, sebagai seorang programmer, ini lebih penting daripada mengatur tombol di layar.
Saya menemukan spesialis seperti itu, tetapi dia memberi tahu saya, “Mengapa kamu memikirkan hal ini? Gambar dulu aplikasinya. Apa itu Integrasi Berkelanjutan? Tunggu sampai dengan tes Unit - membuatnya bekerja. Apa itu pipa pengiriman? Mengapa TestFlight - gunakan simulator. "
Tentunya, dia adalah programmer yang baik, tetapi di kepalanya, menurut saya,
semuanya terbalik . Menurutnya kode itu penting dan sisa kemasannya adalah nomor dua. Menurut pendapat saya, ini adalah masalah besar, dan saya ingin membicarakan hal ini.
Untuk beberapa alasan, banyak pengembang percaya bahwa
kode itu sendiri adalah penting, dan perakitan adalah apa yang dilakukan oleh insinyur DevOps atau orang lain. Biasanya, ketika Anda datang ke tim, itu sudah dilakukan dan dikonfigurasi. Anda menemukan diri Anda dalam proyek di mana Anda menulis kode, tidak tahu bagaimana semuanya berakhir dalam produksi. Saya percaya bahwa fakta bahwa programmer tidak melihat siklus perakitan lengkap, tidak tahu cara kerjanya, adalah masalah.
Pertama menyebarkan, lalu kode
Saya menulis buku tentang pemrograman, dan saya tahu sendiri bahwa sebuah
buku akan bekerja dengan baik jika Anda mendesainnya terlebih dahulu dengan indah . Yaitu, saya mendesain buku sebelum saya menulis. Pertama saya membuat makefile, yang langsung dari baris perintah mengumpulkan seluruh buku dari file di LaTeX, menyiapkan teks, gambar, sampul depan. Saya menghabiskan banyak waktu dan membuatnya sehingga dengan satu perintah untuk mengumpulkan seluruh buku menjadi file PDF. Saya sangat memperhatikan bagaimana tampilannya, di mana indentasi, blok teks mana dan jarak di antara mereka, bagaimana halaman akan diberi nomor. Ketika saya menyukai semua ini, saya melihat bahwa semuanya telah dirangkai dengan indah dan semua yang ada dalam produk ini selesai, bahkan jika hanya satu halaman yang ditulis sejauh ini, baru kemudian saya mulai menulis buku, dan baru kemudian itu memberi saya kesenangan.
Paling sering, programmer melakukan yang sebaliknya: mereka menulis, menjalankan pada simulator, memeriksa pekerjaan. Saya percaya bahwa lebih tepat
untuk menggunakan pertama, lalu kode .
Saya akan memberikan satu contoh lagi. Salah satu pengembang pemula mengajukan diri untuk melakukan proyek open source dengan kami. Dia memilih Flutter, membuat iterasi pertama, memulainya, mengatakan bahwa semuanya keren dan keren, dan menawarkan untuk melihat. Kami bertanya: “Bagaimana cara mencoba sesuatu? Inilah iPhone - ke mana harus mendorong? " Apa yang mulai dia jelaskan, ke mana harus pergi, apa yang harus diunduh, adalah proses yang panjang.
Ini terasa tidak nyaman bagi kami, dan pada akhirnya, ia setuju bahwa aplikasi benar-benar perlu diunggah ke TestFlight. Setelah beberapa waktu, ia menunjukkan aplikasi pada TestFlight. Saya menekan tombol, dan melihat beberapa cacat. Saya tidak bekerja dengan Flutter dan tidak benar-benar ingin, tetapi saya ingin segera memperbaiki apa yang saya perhatikan. Saya bertanya bagaimana melakukan ini, di mana dan bagaimana mengirim permintaan tarik. Saya membuka repositori, readme-file: "Ini adalah aplikasi keren ... klik unduh ...".
Petunjuknya rumit dan tidak bisa dipahami, saya kembali bertanya bagaimana cara menyebarkan semua ini di komputer saya. Saya hanya ingin memodifikasi kode orang lain dengan mengklik sederhana beberapa tombol di komputer saya, mulai simulator dan mengirim permintaan tarik. Orang itu pergi untuk menggambarkan semuanya, dan tidak pernah kembali.
Situasi ini menggambarkan bahwa kualitasnya sebagai seorang programmer baik - ia mampu menjalankan aplikasi. Tetapi kualitasnya, sebagai orang yang melihat keseluruhan proyek, meninggalkan banyak hal yang diinginkan. Akibatnya, proyek ini tidak hanya kehilangan saya sebagai kontributor, tetapi juga banyak lainnya. Programmer ini tidak menerima pengembalian dari orang lain, ia bekerja seperti penyendiri.
Menurut saya,
kesepian itu salah sekarang. Pasar bergerak ke arah tim yang lebih besar: akan ada lebih banyak orang di dalamnya, mereka akan datang dan pergi lebih sering.
Dinamika sumber daya manusia bergerak menuju pergantian yang lebih tinggi, sehingga setiap orang yang datang ke proyek lagi perlu melihatnya secara keseluruhan - bukan hanya kode yang berjalan pada simulator.
Seorang pemula harus berakhir di lingkungan yang ramah baginya dari sudut pandang perakitan - ia harus membuka file readme dan dalam beberapa menit mengerti bagaimana memastikan bahwa semuanya dimulai pada simulator. Apa yang harus diklik untuk memeriksa apakah semuanya dibangun dari baris perintah - bukan dari IDE kompleks yang perlu dikonfigurasi selama beberapa jam lagi. Seharusnya dimungkinkan untuk menulis make / build / etc pada baris perintah. Setelah itu, semuanya dikumpulkan dan mencetak garis hijau - semuanya siap - lalu tarik permintaan. Ini adalah pemikiran pertama yang ingin saya bagikan hari ini.
Tentu saja, Anda akan mengatakan bahwa Anda tidak bekerja sendirian, bukan sebagai satu-satunya pendiri proyek, bukan sebagai CTO. Anda bekerja dalam tim dan Anda tidak bisa datang dan mengatakan bahwa sekarang Anda akan berurusan dengan penyebaran, TestFlight, dan Anda harus segera memahami CI. Ini bukan tugas Anda, Anda tidak akan diberi waktu untuk itu, dll.
Karena itu, saya sarankan Anda melakukan proyek kesayangan Anda sendiri - proyek yang Anda lakukan untuk kesenangan Anda sendiri - untuk memahami semuanya secara keseluruhan.
Hanya 20-30% programmer yang memiliki aplikasi mereka sendiri, dan semua orang harus memilikinya. Jika Anda menganggap diri Anda dan ingin menjadi programmer yang dicari, saya akan merekomendasikan membuat aplikasi mobile Anda dan melalui seluruh siklus masuknya ke pasar: cek di Apple Store, CI, pengemasan dan yang lainnya. Jadikan sebagai sumber terbuka sehingga orang dapat berkontribusi dan menunjukkan kepada Anda bagaimana mereka gagal.
Lihat bagaimana Anda bekerja dengan pasar, cobalah dan pahami programmer seperti apa Anda. Saya pikir seorang programmer yang tidak memiliki proyek kesayangan buruk.
Dia entah tidak tertarik pada profesinya, atau dia tidak peduli, entah dia tidak bisa, atau dia takut. Ini adalah ketakutan untuk melihat seluruh siklus. Kami takut melihat proyek sebagai produk yang siap untuk klien. Dan klien bagi kami dalam banyak kasus adalah pengembang lain, seperti dalam contoh saya, saya adalah pengembang klien di Flutter.
Ketakutan kedua, menurut saya, adalah uang.
Berapa banyak kode yang akan Anda tulis seharga $ 100?
Saya bekerja dengan banyak programmer di platform Zerocracy dan memperhatikan bahwa mereka sangat takut pada uang. Mereka terbiasa membayar pada akhir bulan, dan mereka sangat menyakitkan ketika mereka dihargai dalam uang. Banyak yang tidak bisa menjawab pertanyaan sederhana: "Apakah Anda tahu seberapa banyak Anda bisa menghasilkan kode seharga $ 100?"
Tentunya Anda tahu berapa banyak yang ingin Anda dapatkan per bulan. Bayangkan berapa bulan penuh biaya hidup Anda: apartemen, mobil, pembayaran rutin, tingkat kenyamanan dan hiburan yang biasa.
Pengembang penuh waktu dan pembayaran tetap kehabisan waktu.
Saya pikir kita akan bekerja lebih dan lebih lagi dalam tim yang dikumpulkan untuk sementara, di mana orang-orang datang saat mereka dibutuhkan, dan melangkah lebih jauh setelah itu. Era pengembang duduk di satu tempat akan pergi karena perusahaan mempekerjakan mereka bertahun-tahun yang lalu, mereka hanya mencintai perusahaan ini, dan karena itu mereka ada di dalamnya - tidak masalah apa pun teknologi yang digunakan perusahaan.
Saya tahu contoh-contoh proyek yang ditulis dalam C ++ selama bertahun-tahun, dan kemudian menyadari bahwa mereka perlu menulis di Jawa. Dan orang yang sama, di kantor yang sama, untuk penukaran uang investor yang sama, berlatih kembali selama setengah tahun dan mulai goyah dan berguling di Jawa. Ini adalah pendekatan dari masa lalu. Menurut pendapat saya, di masa depan pendekatan seperti itu akan tidak ada lagi, karena tidak masuk akal.
Pasar menjadi global , akses jarak jauh ke pasar tenaga kerja menjadi lebih mudah dan lebih mudah. Perusahaan yang berbasis di Moskow tidak akan menarik dan tidak menguntungkan untuk melatih orang, misalnya, dari iOS ke Android atau dari C ++ ke Java. Lebih mudah untuk mempekerjakan spesialis baru yang akan datang sebagai freelancer, menyelesaikan tugas dan pergi.
Saya pikir format proyek ini akan menjadi populer: proyek sementara, di mana freelancer bertemu, mengerjakan tugas mereka - satu ahli dalam hal ini, ahli lain dalam hal itu, dan pergi.
Dari pemrogram, waktu baru ini mengharapkan:
- Kemampuan untuk memahami berapa nilai Anda. Artinya, berikan perkiraan berapa nilai jam kerja Anda, berapa banyak nilai yang akan Anda buat untuk itu.
- Kemampuan untuk bekerja dalam kondisi sementara.
- Keterampilan menjual diri sendiri, hadir dengan benar. Pengembang freelance di pasar global harus memiliki "keunggulan perdagangan" dan harga.
Banyak orang takut membuat resume, takut menjual diri. Seperti yang saya katakan, saya berpikir bahwa ringkasan pasti harus menyertakan item proyek kesayangan.
Proyek sendiri akan menjadi indikator nilai pertama di pasar , dan bukan di tempat Anda mengembangkan perangkat lunak yang Anda warisi selama 5 tahun berturut-turut. Anda membuat proyek hewan peliharaan dari awal, dan tidak peduli apa masalahnya, seberapa rumit atau berapa banyak unduhan yang ada di Apple Store. Jadikan 0 suka dan 2 unduhan, tetapi ini adalah proyek integral yang Anda buat sendiri.
Bagi saya, sebagai majikan, orang-orang seperti itu lebih berharga daripada mereka yang telah berada di kantor selama bertahun-tahun dan memiliki resume dengan satu atau dua majikan. Sulit bagi saya untuk memahami apa yang harus dilakukan dengan orang ini, bagaimana cara mengevaluasinya. Saya tahu bahwa dia ingin saya mengambilnya selama sebulan penuh dan berteman dengannya terlepas dari hasilnya. Bagi saya, format ini sekarang tidak dapat diterima, karena banyak majikan di masa depan juga tidak nyaman.
Oleh karena itu, rekomendasinya adalah
menghitung uang, mencoba bekerja berdasarkan kontrak . Mungkin ini tidak akan sesuai dengan majikan Anda, tetapi cobalah, bekerja penuh waktu dan duduk di kantor, pada saat yang sama mencari beberapa proyek mikro untuk pekerjaan paruh waktu. Bukan demi uang, tetapi untuk memahami apakah pasar membutuhkan Anda sebagai pekerja lepas atau tidak, apakah Anda membutuhkannya sebagai seorang ahli atau tidak. Atau Anda hanya perlu bos Anda, yang takut kehilangan Anda, karena hanya Anda yang tahu cara kerja kode proyek.
Cari alternatif, lihat, coba, jual . Pada awalnya Anda tidak akan dibeli, akan ada masalah - banyak masalah! Tetapi memecahkan masalah ini, Anda akan menjadi programmer yang lebih dicari di tingkat yang lebih tinggi.
Sayangnya, tidak hanya programmer sendiri tidak dapat menentukan harga pekerjaan, tetapi juga pelanggan. Terkadang mereka menyarankan agar saya melakukan tugas tertentu sebagai ahli. Dan seringkali pelanggan yang menawarkan saya pekerjaan tidak mengerti bagaimana cara mengevaluasi saya. Lebih sering daripada tidak, orang hanya ingin lebih murah, seperti $ 50, bukan $ 100, per jam. Saya mengerti bahwa seseorang dengan pendekatan ini masih tidak mengerti berapa banyak saya akan menulis secara real time selama jam ini. Kemudian saya setuju dan hanya mengalikan jumlah jam dengan 2. Sebagai hasilnya, saya mendapatkan sebanyak yang saya inginkan.
Saya tahu nilai dan kecepatan saya yang sebenarnya. Pelanggan tidak siap untuk jumlah $ 100-500 per jam, bagi mereka 20 sudah banyak, karena mereka terbiasa dengan format pekerjaan penuh waktu dari waktu ke waktu. Artinya, ketika seseorang menerima uang untuk waktu yang ia duga dihabiskan untuk pembangunan.
Saya tidak tahu tentang Anda, tetapi saya tidak bisa duduk selama 8 jam menulis kode. Saya yakin Anda masing-masing akan mengonfirmasi bahwa dari 8 jam kerja Anda di kantor atau di komputer, Anda sebenarnya menulis kode yang jauh lebih sedikit. Dan mereka membayar selama 8 jam ini, dan pelanggan berpikir bahwa itu adalah 8 jam kerja. Ini adalah sistem penipuan ganda: mereka senang tertipu, dan kami menipu mereka. Karena itu, saya menggunakan faktor multiplikasi. Saya akan bekerja setidaknya selama 20, tapi kemudian saya akan melakukan 3 minggu apa yang benar-benar dapat saya lakukan dalam 2 jam.
Ajari pelanggan Anda dan pelajari cara menghitung uang sendiri.
Pemrogram yang baik menulis kode, tiket terbaik
Baik pelanggan dan programmer terbiasa dengan komunikasi informal.
Komunikasi informal dalam bentuk obrolan, panggilan telepon, demonstrasi, e-mail adalah bentuk komunikasi yang menghancurkan proyek dan hanya membuat pelanggan dan programmer lebih buruk.
Komunikasi informal tetap di udara, tidak dicatat dalam dokumentasi, tidak dipantau, maka sulit untuk kembali ke sana, dan itu membuat proyek sulit dipertahankan. Ketika sebuah tim berubah, dan seperti yang saya katakan sebelumnya, tim harus berubah dan akan berubah lebih intensif, menjadi sangat penting bagaimana dapat dipahami komunikasi masa lalu dalam proyek.
Jika saya datang ke proyek pengembangan, saya ingin memahami apa yang telah dilakukan selama setahun terakhir, tidak hanya dalam bentuk kode, tetapi juga memiliki beberapa jenis penjelasan untuk kode ini: mengapa kerangka kerja atau algoritma seperti itu dipilih, yang telah menyatakan pendapat mereka tentang algoritma ini dan saya tidak setuju. Saya ingin melihat semua ini, dan tidak mencari di kantor atau mengobrol dengan seseorang yang akan menjelaskan semuanya kepada saya. Saya perlu kesempatan untuk membaca ini langsung di repositori atau sistem tiket.
Sayangnya, paling sering programmer mengikuti jejak pelanggan. Tentu saja, demi kepentingan klien memiliki kesempatan komunikasi informal dengan pengembang. Dan kita menemukan diri kita cukup lemah dan mengikuti petunjuk mereka, mendengarkan di telepon apa yang harus dilakukan, menjawab, mendengarkan, menjawab ... dan kemudian kita pergi dan melakukannya.
Kemudian 2-3 minggu berlalu, dan kami tidak lagi ingat apa yang kami sepakati. Pelanggan mengatakan bahwa dia tidak menginginkan ini, kami mencoba untuk membuktikan bahwa ini adalah apa yang dia minta, kami sedang mencari beberapa menyebutkan dalam obrolan - penangkapan kutu dimulai.
Saya pikir alasannya adalah ketakutan akan sistem tiket. Banyak programmer dengan siapa kami bekerja (pasti, ini juga menyangkut Anda) tidak tahu bagaimana, tidak suka, tidak ingin merumuskan tugas dalam bentuk tiket - jelas dan ringkas.
Lebih mudah bagi orang untuk mengatakan: "Ayo bicara!" Kami akan mengadakan rapat umum, duduk bersama dan memutuskan segalanya. Dalam 3 jam kita akan saling memahami, dan kemudian saya akan pergi dan kode itu. Saya akan mengingat apa yang telah kami sepakati dan akan memprogram semuanya. " Lupa apa-apa, ketemu lagi. Dan jadi kita entah bagaimana akan membentang dari reli ke reli.
Ini salah. Kami, sebagai programmer, harus mengubah komunikasi informal apa pun menjadi tiket. Kami berbicara dengan klien (pelanggan, pemilik produk, programmer lain), menemukan apa yang perlu diubah - kami mengubah komunikasi apa pun menjadi tiket yang dibatasi oleh kerangka kerja sistem kami (Jira, GitHub, dll.), Di mana kami menulis: apa yang tidak berfungsi, bagaimana Anda perlu memperbaikinya, mengapa Anda harus memperbaikinya, apa motivasi, dan kemudian kami mengerjakan tiket ini.
Ketidakmampuan seorang programmer untuk menyusun pekerjaan di dalam tiket dapat menunjukkan kualifikasinya yang rendah. Saya percaya bahwa ada dua jenis pengembangan:
- Pengembangan berkelanjutan - pemrograman dari jam 9 pagi sampai jam 5 sore: Saya tiba, menyalakan komputer, lalu saya melakukan sesuatu, di sana, makan siang, saya juga memberi kode, akhir hari - ya, besok saya akan melanjutkan. Yaitu, kami memprogram selagi ada energi, waktu, dan kekuatan.
- Pengembangan tambahan berbeda: ada tugas nomor 13, saya akan melakukannya sampai akhir, dan kemudian melihat tugas apa selanjutnya. Dalam formulir ini, tugas (tiket) akan selalu selesai. Tetapi jika tidak ada tiket, tidak ada tugas yang didokumentasikan yang dirumuskan, proyek tidak bergerak - kode tidak ditulis, dan permintaan tarik tidak muncul.
Saya sering menemukan diri saya bekerja dalam skenario pertama. Saya suka memprogram, di pagi hari saya menyalakan komputer - dan pergi. Lalu saya rem - berhenti, mari kita bagi menjadi tugas, tentukan tugas mana yang akan kita pindahkan.
Dalam versi kedua, setiap tiket diakhiri dengan permintaan tarik: inilah masalahnya, uraiannya, diskusi di bidang masalah ini, perubahan kode. Permintaan tarik dikirim, diverifikasi, diterima - tiket ditutup, Anda dapat melanjutkan ke yang berikutnya.
Biasanya orang bekerja dua arah. -, , : .
, 2 , pull request' 5 . . — 0,5–2 , pull request 50-100 . — - (, ) .
, , .
, — , . , , , .
. , , , . . , , , , - , . , . , , . .
. . — , . .
, , .
? !
, — . , - , . IT- , , , . , , .
, . , , , , , ,
English only .
, , — , , Swift, , , . , . , 5-10-15 , .
, . Telegram-, , . — , . , , .
, . , .
, .
. , , .
. . , -, . , , , . — . . , , , .
. , , , . , .
—
. Twitter, , Telegram- . , . .
, , , , . , , , , , — .
5-10 . 2 , , .
, . — . , , .
GitHub —
, open source , 10–15 open source, (NASA ).
, .
open source . , — . : , pull requests , , GitHub, .
open source- . open source-, , , .
, , . — open source, ? , , , — .
, — , . , , . open source- . open source community: , -, , pulll request, .
open source-, : , , — - . 2 300 followers GitHub — , 6 .
— , . -, , . , .
, . , . , , , , . — , 25 , , community .
, . , . , full-time, . , .
— , . , 20 Twitter 2 GitHub, . open source-, , . .
— .
2000 , 2019. 2029 . , , followers, , .
, . DevOpsConf Russia , , QualityConf . Saint TeamLead Conf .
— . .