Pernahkah Anda khawatir bahwa Anda lebih mementingkan bagaimana sesuatu dibangun daripada apa yang sebenarnya Anda bangun?

Sebagai seorang programmer saya memiliki gangguan yang mengganggu yang melekat pada alat saya, kode orang lain, kode saya, dunia pada umumnya. Saya selalu ingin memperbaikinya. Jadi saya refactor, saya tetap di atas teknik terbaru. Saya mencoba dan mempelajari pola, saya mencoba menggunakan kerangka agar tidak menemukan kembali roda. Saya bisa menulis spesifikasi teknologi yang akan membuat kaus kaki Anda lepas dengan jumlah pola yang bisa saya peras.

Namun, belakangan ini saya merasa benar-benar tahu lebih banyak tentang alat yang saya gunakan daripada bagaimana sebenarnya mengimplementasikan perangkat lunak yang sukses.

Saya merasa seperti saya kurang dalam keterampilan faktor manusia dan saya percaya bahwa untuk menjadi insinyur perangkat lunak yang sukses dibutuhkan lebih dari sekadar mengetahui kerangka kerja paling keren. Saya pikir itu membutuhkan beberapa dari rangkaian keterampilan berikut juga.

• Desain interaksi
• Pengalaman pengguna
• Pemasaran

Saya memiliki sedikit hal ini yang saya pelajari dari orang-orang yang pernah bekerja dengan saya dan proyek-proyek besar yang telah saya kerjakan, tetapi saya tidak merasa seperti "memiliki" keterampilan ini.

Apakah saya benar? Haruskah saya mencoba mengembangkan keterampilan ini lebih lanjut, atau haruskah ini diserahkan kepada orang-orang yang melakukan ini untuk karier?

Bagaimana Anda memastikan Anda tidak terlalu terikat dengan cara Anda melakukan sesuatu dan memastikan Anda "membuat pengguna Anda luar biasa"?

Adakah yang tahu sumber daya yang baik untuk mempelajari keterampilan ini dari sudut pandang pemrograman?

Saran saya: Bicaralah dengan pengguna Anda sebanyak mungkin. Saya tidak tahu apakah Anda berada di perusahaan besar dan berada di benua yang berbeda dari pengguna Anda, atau jika Anda berada dalam posisi tipe freelancer, tetapi jika mungkin, hanya berbicara dengan pengguna Anda.

Saya tahu bahwa seringkali, saya harus duduk dan mengingat bahwa bukan tugas saya untuk membangun sedikit kode terbesar yang pernah ada di dunia, atau membangun fungsi yang menggunakan paling sedikit siklus dan waktu jumlah waktu sesingkat mungkin secara teknologi, tetapi untuk membuat apa pun yang dibutuhkan pengguna untuk melakukan pekerjaan mereka. Dan untuk efek itu, saya menemukan bahwa di luar kemampuan teknis belaka, (bagi saya sendiri) 2 sifat terbaik untuk dimiliki adalah pengetahuan kerja yang baik dari bisnis pengguna, dan hubungan kerja yang baik dengan mereka.

Saya bekerja di sebuah perusahaan bertubuh kecil (~ 50 orang), dan saya suka bisa berjalan ke kubus siapa pun dan mengobrol tentang hal terbaru yang saya buat / perbaiki untuk mereka. Perasaan terbaik mutlak yang pernah saya dapatkan dari pekerjaan saya adalah ketika saya dapat mendengar mereka berbicara tentang pekerjaan mereka, dan menyarankan sesuatu yang akan memecahkan masalah yang mereka tidak pernah sadari akan ada solusi teknis. Itu tidak akan mungkin terjadi jika saya tidak memahami bisnis mereka dan tidak dapat melakukan percakapan santai dengan mereka.

Saya akan mengatakan itu tergantung di mana Anda bekerja, dan apa jenis perusahaan yang Anda lihat bergerak di masa depan - yang benar-benar diskusi terbuka.

Dengan perusahaan yang lebih kecil, Anda mungkin memakai banyak topi (meskipun saya tidak yakin mengapa pemasaran ada dalam daftar ini kecuali Anda berniat untuk menjual produk Anda sendiri).

Di perusahaan yang lebih besar, mereka cenderung memiliki orang yang fokus secara khusus pada hal-hal ini.

Jadi sungguh, ini semua tentang ke mana Anda akan pergi, dan berpotensi membuka lebih banyak pintu untuk diri sendiri.

Untuk setiap baris kode yang Anda tulis, Anda memperkenalkan kemungkinan bug.

Jadi, desain terbaik meminimalkan jumlah kode yang diperkenalkan - mungkin melalui prinsip KERING (Jangan Ulangi Diri Sendiri). Namun, startup lebih menyukai pendekatan YAGNI (You Are't Gonna Need It) yang mengarah ke MVP (Minimum Viable Product) lebih cepat.

Jika tujuan Anda adalah menciptakan produk yang bersih dan mudah digunakan yang melakukan persis apa yang diinginkan pengguna Anda, maka YAGNI adalah pola desain utama Anda. Buang semuanya yang tidak berkontribusi langsung ke kode kerja. Itu termasuk proses membangun murni dan penggunaan obsesif dari pola.

Beberapa bahan bacaan

Anda mungkin ingin membaca " Jangan buat saya berpikir " yang merupakan buku yang bagus tentang desain antarmuka pengguna. Juga, seri buku Gitomer mana pun (khususnya The Little Green Book ) akan membantu Anda dalam keterampilan penjualan, jaringan, dan pemasaran.

Saya pikir sejumlah desain interaksi dan pengetahuan pengalaman pengguna sangat berguna bahkan di perusahaan besar karena satu alasan: Anda sebagai pengembang adalah orang pertama yang benar-benar menggunakan antarmuka, berminggu-minggu atau bahkan berbulan-bulan sebelum berada dalam kondisi yang dapat digunakan untuk seorang tester untuk menguji.

Ini bisa sangat berguna pada tahap awal untuk menunjukkan antarmuka yang tidak semudah yang direncanakan, atau beberapa prinsip desain yang mungkin terlewatkan. Hal-hal itu terkadang sulit dilihat sebelum Anda memiliki sesuatu yang konkret untuk dikerjakan, dan Anda selalu menjadi orang pertama yang memiliki sesuatu yang konkret untuk dikerjakan.

Saya bisa menulis spesifikasi teknologi yang akan membuat kaus kaki Anda lepas dengan jumlah pola yang bisa saya peras.

Pernyataan itu sendiri membuat saya percaya Anda harus bekerja pada aspek lain dari pengembangan perangkat lunak.

Meskipun Anda mungkin tidak pernah bertanggung jawab atas setiap aspek perangkat lunak perusahaan Anda, memiliki berbagai pengetahuan di banyak mata pelajaran bisa sangat berharga. Jika tidak ada yang lain, itu adalah lebih banyak hal yang dapat Anda singgahi dalam sebuah wawancara, sehingga Anda dapat melanjutkan karier Anda.

Jika Anda tidak cukup tertantang di beberapa bidang pekerjaan Anda, mulailah proyek Anda sendiri di rumah untuk melakukan sesuatu yang menurut Anda menarik. Atau terlibat dengan proyek sumber terbuka.

Tidak saya tidak, itu bukan tugas saya untuk khawatir tentang apa yang saya bangun tetapi untuk membangunnya sesuai spesifikasi yang ditetapkan oleh klien / majikan saya. Mereka sudah tahu apa yang mereka inginkan dan terserah saya untuk mengimplementasikannya dengan benar sehingga dapat dipertahankan. Saya akan memberikan saran ketika ada kesempatan jika saya tahu mereka tidak yakin cara terbaik untuk memasukkan fitur ke dalam perangkat lunak.

Mungkin pada titik tertentu saya akan ingin membuat proyek saya sendiri dan khawatir tentang apa yang saya bangun tetapi saya pikir untuk sementara waktu ketika memulai karir pengembangan perangkat lunak, penting untuk terus berusaha mempelajari cara yang benar untuk melakukan sesuatu.