Apa yang seharusnya tidak dilakukan spesialis TI pada tahun 2020?

Habr penuh dengan prediksi dan saran tentang apa yang harus dilakukan tahun depan - bahasa apa yang harus dipelajari, di bidang mana yang harus dibatasi, bagaimana menangani kesehatan Anda. Kedengarannya menginspirasi! Tetapi setiap koin memiliki dua sisi, dan kami tersandung tidak hanya pada sesuatu yang baru, tetapi sebagian besar dari apa yang kami lakukan setiap hari. "Yah, mengapa tidak ada yang memperingatkan saya!", Kami berseru kesal, biasanya beralih ke diri kita sendiri. Kami menyebabkan kebakaran pada diri kami sendiri - kami telah menyusun untuk Anda daftar apa yang TIDAK layak dilakukan pada tahun 2020 (dan mungkin selalu).


Dan gravitasi tidak diminta.

Kami ingin mengatur anti-rekomendasi secara berurutan, dari yang paling penting hingga yang paling tidak penting. Tetapi mereka begitu luas, setara dan akrab bagi hampir semua orang sehingga kita akan menulis secara terpisah. Nah, periksa daftarnya?

Tidak perlu pergi ke IT jika semuanya baik-baik saja


Jangan belajar teknologi baru untuk mengubah profesi Anda atau mulai dari awal. Waktu kami luar biasa karena Anda dapat belajar, berganti pekerjaan, mengubah lingkungan secara mendasar - dan bahkan hingga pensiun. Ini adalah hal yang keren dan menggoda. Tetapi jika Anda lebih dari 28-30, Anda tidak boleh meninggalkan semuanya untuk masuk TI atau meninggalkan tumpukan baru (misalnya, Anda menulis sistem yang sangat dimuat di Jawa dan tiba-tiba memutuskan untuk meninggalkan jaringan saraf Python). Alasannya sederhana: itu tidak akan mudah bagi Anda. Pertama, ada persaingan yang tinggi dari para spesialis yang telah duduk di tumpukan ini sejak awal karir mereka, kedua, Anda harus lagi menjadi junior dengan gaji rendah, dan ketiga, secara moral akan sulit bagi Anda untuk menjadi bawahan ke tingkat hierarki terendah. Karena itu, jika Anda ingin pindah ke arah lain, coba lakukan itu sejalan dengan pekerjaan saat ini dan tugas saat ini, atau kembangkan pengetahuan baru sebagai hobi, ajukan proyek kesayangan untuk datang ke pekerjaan baru bukan lagi junior.

Ubah tumpukan ke tumpukan - hanya waktu yang hilang


Jangan terburu-buru di antara tumpukan teknologi untuk pengembangan Anda. Jika Anda menulis proyek dalam satu bahasa, menggunakan kerangka kerja dan perpustakaan tertentu, Anda tidak harus membuang segalanya ke neraka dan menulis ulang ke Dart, hanya karena itu tampak menarik bagi Anda. Buatlah aturan untuk menemukan alasan untuk mengubah teknologi - tidak hanya di tingkat kekurangan, tetapi juga di tingkat keuangan dan teknik.



Tidak perlu berdiri di tanah dan perunggu


Beristirahat di satu bahasa atau teknologi dan tidak belajar yang baru sama ekstrimnya dengan mengubah tumpukan dengan setiap teknologi baru. Pastikan untuk mempelajari perpustakaan dan kerangka kerja baru, jangan keras kepala dalam pengetahuan bahwa semuanya lebih baik dipikirkan oleh Anda dan didoping secara eksklusif oleh Anda. Untuk hampir setiap bahasa, pembaruan terus-menerus keluar, yang terkadang dapat sangat meningkatkan proyek Anda. Jangan malas mengikuti dinamika tumpukan Anda dan, segera setelah Anda menemukan sesuatu yang keren dan berguna, jangan ragu untuk masuk ke proyek!

Kepalamu baik, selalu baik


Jangan berpikir dengan kepala orang lain, milikmu lebih baik. Sayangnya, beberapa pengembang duduk dan menunggu mereka untuk menerima tugas untuk kode dari kesalahan sebelumnya sampai akhir, tanpa mencoba untuk memperkenalkan sesuatu mereka sendiri ke dalam proyek, mengembangkan fungsi baru, mengujinya dan menawarkannya dalam produksi. Mengapa repot ketika ada kepala tim pemimpin atau pemimpin perusahaan yang akan memutuskan semuanya sendiri? Jika Anda mengenali diri Anda sendiri, maka kami memiliki berita buruk: posisi pasif tidak akan membantu dalam karier atau dalam pengembangan. Anda memiliki kesempatan untuk mencoba tangan Anda pada seorang insinyur pengembangan, bukan seorang pembuat kode, dalam sebuah proyek pertempuran nyata dan memahami ke mana harus bergerak, apa yang hilang, tetapi Anda lebih suka menghabiskan waktu Anda pada sesuatu yang lain dan melakukan hal yang tepat "mulai sekarang." Seperti di TI modern bertahan hidup lebih buruk dan lebih buruk, keluar dari animasi yang ditangguhkan.

Pengguna adalah orang-orang yang menakutkan


Jangan melebih-lebihkan pengguna perangkat lunak Anda: jika Anda tidak menulis untuk programmer, berharap bahwa program tersebut akan menghadapi kesalahpahaman yang tidak dapat ditembus. Beberapa hari atau minggu pertama, pengguna akan membenci perangkat lunak Anda, karena "yang lama tidak sebodoh itu." Untuk menghindarinya, lakukan beberapa dokumentasi keren dan materi pelatihan. Ketika menginstal atau membeli, itu sangat mengganggu untuk mengisyaratkan bahwa manual harus dibaca sebelum Anda mulai bekerja dengan program ini, dan tidak setelah crash database, kehilangan kata sandi dan kontrol diri.



Jangan meremehkan pengguna: mereka lebih licik, lebih pintar, dan lebih ingin tahu daripada yang Anda pikirkan. Jika Anda berpikir bahwa bug dengan format variabel dan dieksekusi pada tekan Enter ke 138 dengan interval satu detik tidak akan muncul, Anda salah - mereka akan muncul dan mempengaruhi operasi aplikasi Anda dengan cara yang paling aneh. Aturan amatir berfungsi: dialah yang mengatasi pengujian terbaik. Tetapi untuk beberapa alasan, pengguna tidak suka menemukan bug dalam produksi - tidak ada solidaritas di dalamnya. Secara umum, semakin Anda percaya diri dalam perangkat lunak Anda, semakin baik. Pada akhirnya, lebih baik menunda rilis beberapa fitur daripada menambahkannya ke aplikasi yang sedang berjalan dan membuatnya tiba-tiba mentah.



Hentikan googling!


Berhenti mengakses Google sendirian. Kami bahkan tidak akan berdebat - di bidang pengembangan, permintaan langsung ke mesin pencari dapat menemukan banyak. Semakin dalam Anda menggali informasi, semakin banyak "sisi" data yang akan Anda dapatkan dan pelajari lebih banyak, karena Anda akan mempelajari sesuatu yang baru, tidak terkait dengan permintaan Anda, tetapi mungkin dibutuhkan di masa depan. Beralih ke materi lengkap, buku, artikel, dll. Bahasa dan perpustakaan memiliki spesifikasi, komunitas, cara, dan Anda mendapatkan cara yang paling dapat diandalkan untuk mengembangkan keterampilan programmer Anda - cukup baca dokumentasi, dan tidak mencari solusi lokal orang lain dan cuplikan kode. Bagaimana jika keputusan Anda akan lebih baik, lebih cepat dan lebih dingin?

Percaya tapi verifikasi


Jangan gunakan pustaka dan kerangka kerja yang dibuat oleh pengembang pihak ketiga tanpa memeriksa kode atau mengadaptasinya untuk tujuan Anda sendiri. Anda tidak memiliki alasan untuk mempercayai pembuat kode tanpa syarat ini yang tidak Anda ketahui sama sekali. Ya, berbagai elemen berbahaya yang disengaja dalam kode pihak ketiga tidak begitu umum dan paranoia tidak layak untuk diderita, tetapi menyalin secara buta bagian-bagian perangkat lunak yang selesai ke dalam proyek Anda dapat menyebabkan konsekuensi yang tidak terduga. Oleh karena itu, pastikan untuk membaca dan menganalisis kode sebelum menggunakan dan melakukan pengujian setelah penerapan kode.

Buat cadangan!


Berhentilah tidak membuat cadangan atau menyimpannya di server pihak ketiga yang sama tempat proyek Anda di-host. Pikirkan nasihat lucu dan sia-sia? Tetapi lebih dari 700 peserta obrolan di Telegram yang jatuh ke dalam situasi yang tidak menyenangkan baru-baru ini dengan berhentinya pusat data terkenal tidak berpikir demikian - yang tidak ada di sana: dari proyek kesayangan hingga situs web besar milik negara. badan dan basis perusahaan 1C dan penagihan. Bagian penting - tanpa cadangan atau dengan cadangan di tempat yang sama. Jadi sebarkan risiko dan simpan cadangan setidaknya di hosting utama, pada beberapa VDS yang andal, dan di server lokal Anda. Pada akhirnya, itu akan menjadi jauh lebih murah.

Berhentilah membawa barang milik Anda sendiri yang merugikan proyek


Jangan melakukan apa yang Anda inginkan dalam draft kerja, tetapi lakukan apa yang dibutuhkan pelanggan. Ya, ini sangat menarik dan keren untuk membuat jaringan saraf Anda sendiri, melatihnya dan mengimplementasikannya dalam perangkat lunak Anda, tetapi jika pelanggan Anda memerlukan manajer kontak sederhana, itu akan menjadi kelebihan yang mahal. Lihat bagaimana proyek bekerja, baca dokumentasi, baca ulasan dan aplikasi dari pelanggan dan terapkan apa yang akan memberikan nilai bisnis proyek. Jika Anda ingin membuat sesuatu yang ilmiah atau sangat rumit, mulailah dengan proyek Anda sendiri.

Bukan kode, tapi ikatan saraf


Jangan menulis kode yang tidak dapat dibaca dan tidak didokumentasikan. Kita akrab dengan fitur ini: pengembang menulis kode seperti yang Allah berikan kepada jiwa, dengan sengaja membingungkannya sehingga tidak ada rekan yang bisa mengetahui apa yang tertulis - pembalasan preventif yang aneh sebelum sesuatu terjadi. Namun, Anda mengambil risiko tidak hanya perusahaan (yang membayar Anda untuk pekerjaan), tetapi juga diri Anda sendiri: kemungkinan Anda sendiri tidak akan ingat apa yang ingin Anda katakan dengan kebingungan yang tidak disengaja ini. Hal yang sama dengan kode tidak berdokumen: mengandalkan logika Anda untuk variabel penamaan dan fungsi dan memori yang baik, setelah beberapa tahun Anda mungkin tidak ingat mengapa Anda memilih loop tertentu ini, metode, pola, dll. Mendokumentasikan kode dan strukturnya yang baik adalah layanan yang keren untuk kolega, majikan, dan terutama untuk dirinya sendiri.



Tetap sederhana, bodoh


Jangan menyulitkan kode, keputusan, dan proyek. Tidak perlu memagari struktur yang kompleks dan menghasilkan entitas tanpa signifikansi khusus. Semakin kompleks kode Anda, semakin Anda menjadi sandera - akan sangat sulit bagi Anda untuk mempertahankan dan mengembangkannya. Tentu saja, prinsip KISS yang terkenal ("Tetap sederhana, bodoh") tidak selalu cocok, tetapi diciptakan tidak sia-sia: kesederhanaan dan keanggunan kode adalah kunci untuk aplikasi yang sukses dan digunakan kembali.



Hati-hati


Jangan abaikan keamanan - pada tahun 2020 secara harfiah pidana. Bahkan jika perusahaan Anda, pengembangan, dan Anda tidak tertarik pada penyusup, Anda mungkin akan terpengaruh oleh masalah yang terkait dengan kekalahan segmen jaringan, penyedia hosting, serangan pada pusat data, pencurian kata sandi email dan perilaku tidak aman dari karyawan yang bisa mencuri data dari perusahaan, menarik pelanggan atau kode program dari seluruh proyek. Jika itu berada dalam kekuasaan Anda dan termasuk dalam bidang kompetensi, cobalah untuk melindungi proyek-proyek dengan siapa Anda bekerja. Nah, perhatikan keamanan informasi sendiri, ini tidak mengganggu siapa pun.

Jangan meludah di sumur


Jangan baca majikan Anda. Hingga saat ini, komunikasi telah mencapai tingkat yang, misalnya, semua SDM kota saling kenal dalam absensi dan dapat saling bertukar informasi di ruang obrolan dan grup pribadi (cara membantu mencari pekerjaan dan menulis "Vasily Ivanov, seorang arsitek sistem, membunuh semuanya sebelum pergi akun, menghapus cadangan dan memutus jaringan, pemulihan memakan waktu 3 hari. Jangan bawa bekerja "). Dengan demikian, perilaku Anda akan bermain secara eksklusif melawan Anda - dan kadang-kadang bahkan relokasi ke kota atau ibukota lain tidak akan membantu. Bahkan jika Anda pergi dengan kebencian, tidak ada balas dendam yang lebih baik daripada menjadi karyawan yang berguna dan keren dari pesaing :-) Dan yang paling penting, sepenuhnya dengan impunitas.


Ini juga tidak layak dilakukan. Tetapi, seperti yang ditunjukkan oleh pengalaman, kami tidak akan berhenti

Secara umum, teman-teman, baca tipsnya, tetapi lakukan apa yang menurut Anda terbaik - karena penemuan nyata dibuat ketika kita meragukan kebenaran yang telah ditemukan. Selamat Tahun Baru, biarkan proyek Anda menjadi sukses, karier tidak membosankan, kolega dan manajer memadai, dan kehidupan secara keseluruhan berhasil. Secara umum, untuk Tahun Baru dan untuk kode baru!

Dengan cinta
Tim Studio Pengembang RegionSoft
Di tahun baru, kami akan terus bekerja untuk Anda dan mengembangkan sistem CRM desktop RegionSoft CRM yang kuat dan meja bantuan serta sistem tiket yang sederhana dan nyaman. Dukungan ZEDLine .

Source: https://habr.com/ru/post/id482438/


All Articles