Hai
Beberapa tahun terakhir saya telah melakukan banyak pekerjaan dengan orang-orang yang baru memulai karir mereka di bidang TI. Karena pertanyaan-pertanyaan itu sendiri dan cara mereka ditanyakan oleh banyak orang adalah serupa, saya memutuskan untuk mengumpulkan pengalaman dan rekomendasi saya di satu tempat.
Sekali waktu, saya membaca
sebuah artikel pada tahun 2004 oleh Eric Raymond, dan saya selalu mengikutinya dengan ketat dalam karir saya. Ini cukup besar, dan lebih cenderung untuk administrator sistem. Saya harus membantu orang, sering kali tanpa pengalaman dalam pengembangan sama sekali, menjadi junior dan memulai karir saya.
Bagi mereka yang sudah menjadi, atau hanya bermimpi menjadi pengembang pemula, saya dapat memberikan rekomendasi berikut:
- Jelajahi masalahnya sendiri
- Pertama-tama beri tahu target, lalu sampaikan masalahnya
- Menulis dengan benar dan to the point
- Ajukan pertanyaan di alamat dan bagikan keputusan
- Hargai waktu orang lain
- Terlihat lebih luas
Dan sekarang lebih terinci.
Jelajahi masalahnya sendiri
Anda belajar bahasa pemrograman dari buku atau kursus. Mereka mengambil contoh kode, meluncurkannya, tetapi gagal dengan Anda. Jika Anda percaya buku itu - itu harus bekerja. Tapi Anda percaya mata - itu tidak berhasil. Apa saja pilihannya?
- Putuskan bahwa Anda tidak akan pernah menjadi pengembang, karena seluruh dunia menentang Anda, dan bahkan contoh kerja tidak akan berhasil. Berikan pelatihan;
- Putuskan bahwa Anda tidak akan pernah menjadi pengembang karena Anda terlalu bodoh atau tidak diberikan kepada Anda. Berikan pelatihan;
- Mulailah bertanya kepada semua teman Anda yang setidaknya entah bagaimana terhubung dengan IT, menuntut mereka untuk mengetahui mengapa itu tidak berhasil untuk Anda. Belajar banyak tentang diri Anda, tersinggung. Berikan pelatihan;
Opsi mana yang benar? Ini dia:
Pahamilah bahwa Anda tidak unik (apa pun yang dikatakan ibu dan nenek Anda di sana), dan dunia TI tidak sesederhana seperti terompet ketika Anda meminta kursus dan webinar.
Memahami bahwa Anda tidak unik mengarah pada kesadaran bahwa masalah Anda mungkin telah ditemui oleh puluhan, ratusan, ribuan orang. Jika Anda adalah pengembang pemula, maka Anda dapat dengan mudah tidak melihat sesuatu, tidak menginstal atau mengkonfigurasi. Berikut adalah daftar periksa yang saya usulkan sebelum Anda memahami bahwa Anda sendiri tidak dapat menyelesaikan masalah, dan Anda perlu bantuan:
- Pastikan pertanyaannya unik dan tidak ada jawaban di Internet
- Hati-hati mempelajari penyebab masalahnya, bukan efeknya
- Menilai kemungkinan solusi untuk masalah, pro dan kontra mereka
- Pikirkan tentang alternatif untuk mencapai tujuan Anda
- Pikirkan tentang apa yang mungkin ditanyakan kepada Anda, dan siapkan jawaban sebelumnya
Dengan paragraf
pertama , semuanya sepele: jika teks kesalahan benar-benar tidak dapat dipahami oleh Anda, salin ke Google, dan baca teks dengan cermat melalui tautan.
Kedua : misalnya, jika kode Anda rusak dengan kesalahan "Saya tidak bisa menghubungkan perpustakaan pihak ketiga," maka itu bukan kode Anda. Faktanya adalah Anda tidak menginstal pustaka yang ingin Anda gunakan. Jadi, Anda perlu mencari cara menginstalnya, dan bukan cara memperbaiki kode Anda.
Yang ketiga dan
keempat sangat mirip: Bagaimana jika masalahnya ada di perpustakaan ini, dan saya hanya perlu mencari yang lain? Bagaimana jika saya sama sekali tidak menggunakan perpustakaan pihak ketiga, tetapi menulis kode saya menggunakan alat standar?
Poin
kelima membawa kita ke bagian selanjutnya: pikirkan tentang apa yang akan Anda tanyakan kepada Anda dan siapkan jawabannya.
Pertama-tama beri tahu target, lalu sampaikan masalahnya
Tujuannya adalah apa yang ingin Anda lakukan. Misalnya, tulis kode yang masuk ke Internet dan simpan 10 gambar dengan kucing lucu. Masalahnya adalah mengapa Anda melihat kesalahan di konsol, tetapi tidak melihat 10 kucing lucu. Jangan memulai pertanyaan Anda dengan masalah. Mulailah dengan tujuan, akhiri dengan masalah. Jika orang yang Anda minta bantuan adalah pengembang berpengalaman dan tahu banyak, maka dia pasti akan dapat menawarkan solusi yang lebih sederhana dan lebih elegan untuk masalah tersebut. Jika Anda sudah memilih yang paling sederhana dan paling elegan, ia akan dengan jelas memahami apa dan mengapa Anda ingin melakukannya, dan ini akan mempercepat respons.
Pertanyaan bagus:
Saya ingin memelihara 10 kucing lucu setiap hari untuk tertawa dan memperpanjang hidup saya. Untuk ini, saya menulis kode ini: [...]. Saya berharap itu terhubung ke server FTP dan mengunggah gambar baru dari sana. Namun, ketika saya meluncurkannya, saya melihat kesalahan ini: [...] Meskipun saya dapat mengakses server ini melalui browser.
Jawaban cepat:
Anda mengambil perpustakaan ini dengan sia-sia, tidak ada yang mendukung atau mengembangkannya untuk waktu yang lama. Lebih baik ambil yang ini - saya sendiri mengunduh fotonya dengan kucing!
Pertanyaan buruk:
Hai, kode saya menghasilkan kesalahan ini [...], Anda tidak tahu apa yang salah?
Jawaban yang jelas adalah:
Hai Tidak, saya tidak tahu.
Menulis dengan benar dan to the point
Tidak perlu menuangkan aliran pemikiran pada seseorang. Orang yang Anda tuju untuk solusi bagi bisnis Anda. Buat dia cepat mengerti apa masalah Anda dan apa yang Anda inginkan darinya. Jika Anda memiliki masalah dengan melek huruf, gunakan layanan ejaan dan tanda baca online. Anda dapat menghapus sampah dari pesan tanpa layanan online. Jangan menuangkan air, jangan mulai dari jauh. Menulis dengan ringkas, ringkas, dan langsung pada intinya. Berikan contoh.
Buruk:
- telah masuk ketika pintu keluar lewat)))) Saya mencoba menyatukan sebuah proyek secara singkat, tetapi untuk beberapa alasan O_o tidak bekerja untuk saya, meskipun sepertinya saya melakukan segalanya dengan benar, silakan datang))))) di sini secara umum saya memiliki sesuatu yang tidak jelas di konsol (((sudah langsung Saya mencoba segalanya, tidak ada yang berhasil, ahhh (
Baik:
- Hai, saya mencoba memulai sebuah proyek, tetapi ada masalah. Terjadi crash tepat setelah perintah docker-compose up, berikut ini adalah log peluncuran dan kesalahan: [...] Bisakah Anda memberi tahu saya cara menyelesaikannya?
Ajukan pertanyaan di alamat dan bagikan keputusan
Anda tidak boleh menulis pertanyaan dalam pesan pribadi kepada orang tertentu, kecuali jika Anda telah diberitahu bahwa pertanyaan itu harus ditanyakan. Lebih baik menulis kepada sekelompok orang karena:
- Semua orang sibuk menyelesaikan masalah mereka. Kemungkinan seseorang dalam obrolan umum atau di forum dapat memberi Anda waktu lebih tinggi.
- Kemungkinan seseorang dalam obrolan umum mengetahui cara membantu Anda lebih tinggi.
- Anda membiarkan orang lain berkesempatan menemukan pertanyaan dan jawaban yang sama nanti.
Lihatlah paragraf terakhir. Anda sudah belajar bahwa Anda harus mencoba memecahkan masalah sendiri? Sudah menggunakan pencarian di chat / forum / grup, tetapi tidak menemukan penyebutan masalah Anda? OKE, lalu tanyakan.
Di sisi lain, jangan ganggu orang sia-sia. Jika memungkinkan, kecualikan dari daftar penerima yang tidak dapat membantu Anda. Semakin banyak pesan yang diterima seseorang, semakin kecil kemungkinan dia untuk membaca semuanya. Jangan jadikan orang kebiasaan mematikan peringatan atau hanya mengabaikan pesan.
Tentunya, pengalaman Anda mungkin bermanfaat bagi orang lain. Hemat waktu untuk diri sendiri dan orang lain dengan memposting jawaban atau solusi. Pendatang baru berikutnya, jika dia sudah tahu apa yang kita bicarakan di sini, tidak akan mengganggu siapa pun sama sekali - dia akan menemukan solusi Anda dengan mencari. Mengapa saya mengatakan bahwa Anda dapat menghemat waktu sendiri? Karena Anda mungkin mengalami masalah ini dalam setahun, dan jangan ingat bagaimana itu diselesaikan. Pencarian akan menghemat lagi.
Hargai waktu orang lain
Jadikan hidup semudah mungkin bagi orang yang Anda minta bantuan.
Pastikan tautan yang Anda kirim berfungsi. Coba buka dalam mode penyamaran. Jika tautan memerlukan otorisasi, maka Anda akan melihat kesalahan akses. Misalnya, jika Anda mengunduh kode ke repositori pribadi, atau mengirim tautan ke drive Google, yang hanya Anda miliki aksesnya, seseorang akan melihat kesalahan dan dia harus meluangkan waktu untuk memberi tahu Anda tentang hal itu, dan kemudian menunggu hingga Anda mengkonfigurasi akses. Buat orang itu segera melihat apa yang Anda bicarakan.
Jangan berharap ada orang yang ingin mengingat apa yang Anda minta dua hari yang lalu. Kirim informasi lagi, ingatkan konteksnya. Tidak seorang pun ingin mencari dalam korespondensi apa yang Anda miliki. Jika Anda terlalu malas untuk menggandakan informasi sehingga orang tidak menghabiskan waktu mencari, maka Anda tidak perlu bantuan.
Jangan keluar dari konteks. Jika Anda mengirim log dengan kesalahan, jelas bahwa Anda harus memasukkan tidak hanya kesalahan itu sendiri, tetapi juga kode yang menyebabkannya, dengan contoh kerusakannya.
Jika ada proses yang ditetapkan untuk menyelesaikan masalah Anda, ikuti itu. Anda tidak harus menemukan kembali roda jika Anda sudah memiliki artikel dengan HowTo langkah-demi-langkah.
Jangan mencari tanggapan dari satu orang melalui saluran yang berbeda (menulis ke slack, skype, telegram) pada saat yang sama - itu akan tidak menyenangkan bagi seseorang.
Anda tidak perlu menulis pesan yang sama kepada beberapa orang sekaligus, dengan harapan bahwa setidaknya seseorang akan menjawab Anda. Semua orang ini dapat memberi Anda jawaban (kemungkinan besar, itu akan sama), tetapi mereka semua akan teralihkan dari urusan mereka untuk beberapa waktu. Gunakan obrolan grup.
Terlihat lebih luas
Semua yang kami bicarakan di sini berlaku di luar industri TI. Ikuti aturan ini di supermarket, layanan mobil, berlibur di negara lain, saat berkomunikasi dengan teman dan kerabat. Tunjukkan kepada orang-orang bahwa Anda menghargai waktu mereka dan tidak ingin memaksakan mereka dengan gratis. Tunjukkan bahwa Anda menghabiskan waktu dan energi untuk menyelesaikan masalah sendiri, tetapi Anda tidak berhasil, dan Anda benar-benar membutuhkan bantuan. Sebagai rasa terima kasih, orang akan bersimpati dengan masalah Anda dan membantu dengan solusi mereka.