Topi apa yang seharusnya tidak dipakai oleh seorang programmer? [Tutup]

Dalam pengalaman saya, pengembang perangkat lunak cenderung memakai banyak topi dan mengisi banyak peran dengan tanggung jawab yang berbeda. Dari tidak hanya coding, tetapi kadang-kadang juga menulis SQL, mendesain antarmuka pengguna, mendesain database, manipulasi grafik, bahkan pengujian QA.

Jika peran utama adalah menulis perangkat lunak / kode, peran apa yang seharusnya tidak diambil pengembang? Apakah ada?

Maksud dari pertanyaan ini bukan karena pengembang tidak mampu mengisi peran lain - tetapi memiliki peran tambahan benar-benar berfungsi melawan peran utama , atau harus benar-benar menjadi peran khusus seseorang yang tidak terutama memprogram.

Sysadmin. Mengembangkan perangkat lunak dan menangani infrastruktur TI adalah dua keahlian yang berbeda yang terlihat mirip dengan orang luar. (Ini semua hanya menggedor komputer, kan?) Untuk perusahaan bertubuh kecil, godaan akan sangat kuat untuk membuat The Computer Guy bertanggung jawab atas semua mesin di kantor.

Jika Anda memiliki keterampilan untuk benar-benar memakai kedua topi itu, luar biasa; tetapi itu adalah salah satu hal yang bisa menjadi tenggang waktu yang jauh lebih besar daripada yang disadari orang, dan jika Anda belajar sendiri ketika Anda pergi, kemungkinan Anda tidak melakukannya dengan sangat baik.

Anda mengenakan topi apa pun yang diminta atasan Anda. Itulah yang membuat Anda menjadi pemain tim. Itulah yang membuat Anda menjadi Pemecah Masalah .

Orang terlalu terperangkap dalam gagasan menjadi "pengembang" atau "arsitek" atau "analis". Persetan dengan itu. Anda harus menjadi pemecah masalah. Kode hanyalah alat di sabuk Anda.

Pemecahan Masalah tidak pernah ketinggalan zaman.

Jika majikan saya ingin saya melakukan dukungan teknis atau membuat komputer, biarlah. Sepertinya mereka membuang-buang uang, mempertimbangkan gaji pengembang, tapi itu urusan mereka. Saya di sini untuk menyelesaikan masalah. Bagaimanapun saya bisa melakukan itu, saya akan melakukannya. Dan jika saya merasa seperti, setelah waktu tertentu, bakat saya terbuang sia-sia atau kepuasan kerja saya tidak seperti yang saya inginkan, maka saya hanya memiliki banyak hak untuk pindah ke pekerjaan lain.

Tetapi untuk pertanyaan mendasar - tidak ada topi yang tidak Anda kenakan. Heck, jika mereka ingin Anda mengambil kopi, lakukanlah. Pecahkan masalah mereka; ketahuilah bahwa Anda memiliki hak untuk menemukan pekerjaan lain jika Anda menginginkan perubahan.

Penguji!

Silakan kirim kami penguji langsung dari sekolah penguji jika perlu!

Tanpa penguji, orang-orang berharap semuanya berjalan baik karena programmer adalah penguji dan mereka sangat pintar sehingga harus bekerja.

Saya tidak mengatakan dogfooding bukan ide yang baik. Saya hanya berpikir penguji sangat penting sekarang karena saya seorang programmer.

Anda harus berhati-hati untuk menjadi orang yang tepat untuk masalah perangkat keras kantor . Ini dapat mencakup pemecahan masalah PC, admin server, cadangan, dan bahkan kerja sistem telepon. Saya membuat kesalahan dengan menyebutkan pengalaman perangkat keras saya sebelumnya, dan akhirnya tugas perangkat keras / pemecahan masalah saya sangat bertentangan dengan tugas pemrograman saya.

Seorang programmer tidak harus hanya tester untuk kode sendiri .

Pengembang menulis kode dengan serangkaian asumsi. Jika penguji memiliki seperangkat asumsi yang sama, mereka tidak akan menggunakan fungsionalitas yang tidak terduga di luar batas tersebut, dan banyak masalah akan tetap tidak terdeteksi.

Selain itu, untuk bergerak maju, para pengembang tidak memiliki motivasi yang tinggi untuk mencoba memecahkan banyak hal, sementara para penguji (mungkin berada di tingkat bawah sadar).

Ini tidak berarti pengujian dev tidak berguna. Justru sebaliknya - pengujian dev yang baik memungkinkan penguji untuk fokus pada menemukan masalah yang lebih dalam. Namun, pengujian dev bukan pengganti untuk tester khusus.

Dua yang bisa kupikirkan segera.

1. Dukungan teknologi. Saya di sini bukan untuk membantu klien bekerja melalui situs baru atau mengajari mereka cara menggunakan fitur.
2. Meskipun mungkin diperlukan untuk berinteraksi dengan klien di berbagai titik dalam proses, kecuali jika Anda seorang programmer pengelola, Anda tidak boleh berkomunikasi secara langsung dengan mereka tentang fitur dan implementasi desain.

Anda bisa mengatakan bahwa pengembangan CSS / UI akan berada di luar pemrograman "ranah" tetapi dalam pengalaman saya itu adalah keterampilan yang diperlukan saat ini. Anda tidak bisa pergi begitu saja dengan tabel dan bergantung pada orang lain untuk mengimplementasikannya dengan benar. Saya mungkin tidak suka menerapkan desain atau mengubah kode untuk menangani desain baru, tetapi itu adalah bagian dari pekerjaan.

Menulis pertanyaan tidak masalah, pengujian T / A baik-baik saja (dan IMO harus menjadi pekerjaan programmer, memiliki departemen eksternal yang dapat menemukannya, tetapi pertama-tama Anda harus mengujinya). Administrasi server agak sedikit abu-abu. Bergantung pada seberapa besar proyek tersebut atau jika Anda memiliki admin server khusus, itu mungkin atau mungkin tidak diperlukan.

Secara umum, sudah menjadi pengalaman saya bahwa sebagian besar programmer tidak harus mengembangkan tampilan dan nuansa antarmuka pengguna - walaupun saya tentu mampu mengembangkan UI (dan sering membuat satu ketika membangun prototipe atau bukti konsep), ini adalah lebih baik diserahkan kepada faktor manusia (yang di perusahaan kecil kami adalah seorang seniman grafis yang juga melakukan tata letak layar dan menciptakan sebagian besar manual dan brosur).

Selain itu, pengembang tidak boleh melakukan pengujian QA - itu adalah pekerjaan departemen QA (perusahaan tempat saya bekerja membuat perangkat medis tertanam, jadi ini merupakan persyaratan bahwa pengujian dilakukan oleh departemen terpisah).

Di sisi lain, saya tidak melihat alasan mengapa pengembang tidak dapat mendesain database dan menulis SQL, jika mereka memiliki latar belakang untuk melakukannya - saya telah melakukannya berkali-kali.

Dukungan teknologi

Begitu banyak hari saya terbuang dengan menerima panggilan dukungan teknologi ...

Beberapa yang populer adalah:

• "Akun saya terkunci" atau "Saya lupa kata sandi saya"
• "[Telepon | keyboard | mouse | komputer] saya tidak berfungsi"
• "Komputer saya lambat, bisakah Anda memeriksanya untuk sesuatu yang tidak biasa?"
• "Mengapa X terjadi ketika saya mengklik tombol ini? Seharusnya melakukan Y"
• "Aku terus mendapatkan popup ini ...." atau "Kurasa aku punya virus"
• "Orang ini tidak lagi di sini, bisakah kamu menonaktifkan semua barang mereka?"
• "Kami memiliki karyawan baru, dapatkah Anda mengaturnya dengan login, kartu keamanan, telepon ext, email, dll?"

Peran apa pun yang membuatnya mengatur dirinya. Dalam tim kecil, sering ada kecenderungan untuk menjadikan salah satu pengembang senior sebagai manajer proyek, tetapi juga membuatnya tetap dalam tim sebagai programmer. Ini mengarah ke semua jenis masalah, karena orang ini, sebagai seorang programmer, pada dasarnya tidak dikelola. Alih-alih mendelegasikan semua tugas kepada anggota tim lain, ia akan sering tergoda untuk menugaskan banyak dari mereka untuk dirinya sendiri, terutama tugas yang paling sulit. Jadi tugas yang paling sulit, mereka yang paling mungkin menyebabkan masalah, ditugaskan kepada orang yang hanya 50% tersedia sebagai programmer dan dengan demikian melaporkan kepada siapa pun. Ketika anggota tim lain tidak dapat memberikan, alih-alih menendang pantat mereka, ia akan mencoba melakukan tugas mereka, untuk, karena sebagai manajer proyek, ia bertanggung jawab atas keberhasilan dan cara teraman untuk menyelesaikannya adalah dengan melakukannya sendiri bukan?

Dukungan teknis untuk sesuatu yang Anda tidak punya andil dalam mengembangkan, menyebarkan, atau memelihara, dan belum mendapatkan pelatihan untuk dan tidak terus mengikuti perkembangan perubahan besar. Sebagian dari pekerjaan saya adalah menjawab telepon untuk klien yang menanyakan mengapa internet mereka tidak berfungsi. Saya tidak berurusan dengan setengah dari bisnis itu, jadi saya tidak bisa memberi tahu mereka apa-apa tentang penggunaan.

Tidak harus melakukan dukungan teknis, tidak ada masalah dengan itu. Menjadi seorang sekretaris / teknisi pendukung sambil mencoba mengembangkan sesuatu.

Ini cukup melelahkan karena harus mendengarkan orang mengeluh sepanjang hari dan tidak bisa memberi tahu mereka apa pun. Saya sarankan menghindari ini di semua biaya.

Penjualan .

Beberapa bugger yang malang harus melakukannya, tetapi pastinya bukan pengembangnya.

Seiring bertambahnya usia, saya menyadari bahwa yang terbaik adalah jika pengembang tidak melakukan penyebaran sendiri (saya berjuang mati-matian). Mereka seharusnya tidak memiliki hak apa pun atas basis data produksi kecuali hak pilih. Kode kami menjadi jauh lebih sedikit kereta (dan hal yang sama tidak muncul berkali-kali karena perubahan itu hanya dibuat dalam prod dan penyebaran dev kemudian menimpa lagi kemudian diperbaiki hanya pada prod dalam terburu-buru, bilas dan ulangi) ketika kita harus mulai memberikannya kepada orang lain untuk disebarkan dan tidak diizinkan melakukan perbaikan produksi dengan cepat karena penyebarannya tidak tepat. Lebih lanjut kami berhenti memiliki "pembaruan yang tidak disengaja tanpa disorot klausa tempat yang mengubah setiap catatan dalam tabel" masalah.

Artis dan Perancang Antarmuka Pengguna .

Sebagian besar programmer sangat miskin dalam hal karya seni, tetapi perusahaan tidak perlu membayar artis untuk menggambar dan ikon untuk produk mereka, dan cukup menggunakan "seni programmer" - dengan hasil yang mengerikan. (Sampai Windows Vista, ini adalah faktor pembeda yang paling jelas antara Mac dan PC - Mac tampak cantik dan ramah, PC merusak pemandangan)

Dengan cara yang sama, banyak programmer tidak terlalu tertarik dengan antarmuka pengguna - mereka terutama peduli tentang kode mereka. Mereka hanya mengekspos isi variabel anggota mereka langsung ke beberapa bidang yang dapat diedit, sering tidak peduli di mana mereka meletakkan tombol dan bidang pada formulir mereka, dan menganggap bahwa ini cukup, sehingga perangkat lunak tidak dapat digunakan. (Seluruh industri ponsel sangat bersalah akan hal ini sampai iPhone tiba untuk menunjukkan kepada mereka bahwa Anda benar-benar dapat membuat UI ponsel yang baik untuk digunakan)

Lotus Notes adalah contoh cemerlang dari seberapa buruk kedua hal ini dapat terjadi jika Anda tidak mendapatkan desainer profesional untuk membantu programmer keluar.

Menulis tes keseluruhan dan rencana tes. Serius, teman-teman, saya bisa menulis rencana pengujian saya sendiri, tetapi itu berarti memasukkan ke dalam produk apa pun kesalahpahaman, asumsi salah, dan kesalahan kognitif yang saya buat saat menulis barang. Itulah satu-satunya hal yang saya benci tentang satu perusahaan tempat saya bekerja; di mana saya sekarang, setidaknya kita memiliki ulasan kode yang mungkin akan menangkap hal ini.

Jangan pernah memakai lebih banyak "topi" daripada yang bisa Anda tangani dan nyamankan, mencoba merpati pengembang lubang dengan mengatakan bahwa mereka tidak boleh melakukan A atau B berarti bahwa perancang UI hebat mungkin tidak diperhatikan karena seseorang berpikir bahwa programmer harus menjauh dari UI.

Pada akhirnya, setiap orang akan memiliki kekuatan dan kelemahan yang berbeda dan seorang manajer / penyelia / pemimpin tim yang baik harus mengetahui cara terbaik untuk mengarahkan orang-orang yang bekerja untuk mereka untuk memastikan bahwa talenta digunakan dengan tepat. Demikian juga, jika Anda tidak nyaman merancang UI atau berhadapan dengan pengguna akhir, beri tahu tim Anda sehingga Anda dapat meminimalkan peran Anda di bidang itu. Namun, Anda harus siap untuk mengambil beberapa pekerjaan tambahan di bidang lain.

Juga, jika Anda memakai terlalu banyak topi (mis. Programmer, perancang UI, penguji, analis bisnis, dll) maka Anda akan melakukannya dengan buruk di beberapa di antaranya, atau Anda akan kelelahan. Pastikan Anda tahu berapa banyak topi yang bisa Anda tangani dan coba pertahankan beban kerja di sekitar level itu.

Di luar itu, benar-benar tidak ada "topi" yang tidak boleh dikenakan pengembang jika mereka memiliki keterampilan untuk unggul dalam peran itu.

Saya cenderung menerima pekerjaan apa pun yang dilemparkan kepada saya jika dan hanya jika:

• Saya memperingatkan sebelumnya tentang tingkat keahlian saya dan kemungkinan implikasinya dan bos saya memutuskan bahwa itu dapat diterima
• Ada orang tingkat guru yang dapat (dan mungkin akan pada tahap tertentu) membantu saya untuk menghadapi sesuatu yang tidak terduga
• Baca beberapa dokumentasi, pertanyaan yang diajukan secara online, dll.

Dengan cara ini saya sebagian besar diasuransikan terhadap bos saya dan jika ada yang salah itu setidaknya bisa diperbaiki.

Pengembang adalah pemangku kepentingan dalam situasi (seperti pelanggan, pemilik, dll), sehingga mereka memiliki hak untuk mengharapkan pekerjaan yang bermakna. Menurut saya, itu berarti kesempatan untuk bekerja dengan kekuatan Anda .

Jadi, seorang pengembang tidak boleh memakai topi yang tidak memberi energi, berkontribusi pada pertumbuhan pribadi, dan mengarah pada kinerja puncak - dan mencuri waktu dari "topi" yang melakukan hal-hal ini untuk mereka.

Selain tidak menjadi satu-satunya yang menguji kode mereka sendiri, saya pikir "topi" apa pun tidak apa-apa jika itu berarti bagi pengembang yang mengenakan topi.

"Desainer" atau "pria kreatif". Anda akan beralih dari membuat maket antarmuka aplikasi dengan polos untuk menulis teks pemasaran untuk kampanye iklan online berikutnya atau diskusi tanpa akhir tentang warna biru yang "tepat" sebelum Anda mengetahuinya x_x.

topi itu dengan kaleng bir di sampingnya dengan sedotan. ide yang buruk jika Anda tertangkap.

edit:

Inilah topi yang saya benci tetapi itu memiliki pahala yang besar - itu adalah pertanda besar bagi saya yang mengatakan jika hal ini melanggar itu semua salahmu .... ah, tapi jika itu baik, maka kamu anakku adalah anak yang baik kita semua tahu kamu adalah - sekarang kembali ke ruang bawah tanah ... anak baik ... itu saja.

Topi menyalahkan.