Desain cacat dan berurusan dengan penghinaan [ditutup]

Apakah Anda selalu benar secara fundamental dalam desain perangkat lunak yang Anda usulkan? Ketika Anda memberikan beberapa desain yang secara fundamental salah, Anda cenderung kehilangan rasa hormat dari sesama anggota tim Anda. Apa pun yang Anda lakukan setelah itu, Anda akan diperiksa ulang untuk semua hal yang Anda usulkan setelah kejadian itu. Ini khususnya lebih buruk ketika Anda masih baru dalam sebuah tim dan mereka tidak tahu masa lalu Anda di mana Anda memiliki beberapa kisah sukses yang bagus.

Mungkin alasan Anda memberikan desain yang buruk adalah karena kurangnya pengalaman atau pengetahuan atau keduanya di bidang itu. Bagaimana Anda yang telah menghadapi situasi seperti ini mengatasinya? Apakah ini seperti satu hal dalam karier Anda atau apakah itu terjadi berulang-ulang? Apakah seseorang meletakkan ini di belakang atau seseorang dalam situasi seperti itu perlu mencari pekerjaan baru? Tolong, beberapa umpan balik jujur ​​...

Terima kasih.

Suatu ketika, vp dari kekayaan 500 perusahaan biaya 1 juta dolar dengan keputusan bisnis yang buruk. Ketika dia menyerahkan pengunduran dirinya kepada CEO, jawaban yang diberikan kepadanya adalah, "Saya baru saja menginvestasikan Satu Juta dolar untuk pendidikan Anda dan sekarang Anda mencoba untuk pergi? Saya tidak menerima."

Saya mulai bosan dengan manajer dan pekerja lain yang cepat menyalahkan kesalahan pada seseorang yang menjadi pemula atau menganggap bahwa mereka tidak kompeten. Hanya ada satu cara untuk menjadi desainer yang baik dan itu adalah untuk naik sedikit. Saya tidak peduli jika karyawan saya melakukan kesalahan, saya peduli jika mereka melakukan hal yang sama beberapa kali. Pertanyaannya adalah, seberapa rendah hati Anda dan bagaimana Anda bisa diajari? Ketika seseorang menyampaikan kesalahan Anda kepada Anda, apakah Anda membela diri terlebih dahulu, atau mendengarkannya? Jika Anda adalah salah satu dari pria langka yang dapat menelan harga dirinya dan belajar darinya, maka Anda layak bertahan. Siapa pun yang kehilangan respek karena membuat kesalahan sekali, bukanlah seseorang yang pantas Anda hormati.

Saya pribadi harus menulis ulang dua proyek pertama yang saya rancang setidaknya dua kali, tetapi Anda tahu? Saya belajar banyak, dan meskipun atasan saya terganggu pada saat itu, itu dengan cepat diimbangi oleh efisiensi yang saya peroleh dari waktu ke waktu dengan bersedia belajar dari kesalahan saya.

Mengenai aspek penghinaan dan cara memulihkan, saya memiliki dua saran. Pertama, orang lupa waktu. Juga, ketika orang lain memiliki sorotan pada mereka, mereka akan mengacaukannya juga. Maka semua akan sama lagi. Kedua, jangan menjadi bajingan bagi orang lain ketika mereka melakukan kesalahan, belajar, jujur. Bahkan, Anda harus mendorong mereka kecuali mereka benar-benar membutuhkan tendangan keras. Dari waktu ke waktu Anda dapat membantu mengubah budaya tim Anda dengan mengingat apa yang Anda rasakan ketika Anda melakukan kesalahan yang jujur. Anda pada akhirnya akan menginspirasi orang untuk menjadi programmer, perancang, dan manusia yang lebih baik.

Saya sudah melakukan ini sejak lama (15+ tahun), dan saya masih belum melakukannya dengan benar pertama kali. Desain terbaik muncul dari proses yang berulang dan kolaboratif. Ketika Anda telah mengerjakan suatu desain untuk sementara waktu, mudah untuk terjebak dalam pemikiran bahwa itu adalah satu-satunya cara yang dapat dilakukan. Perspektif baru sangat membantu untuk melihat hal-hal yang Anda lewatkan.

Agar ini bekerja, tim perlu saling percaya. Anda tidak perlu takut menunjukkan desain yang mungkin cacat pada orang, dan harus dapat menerima kritik terhadap desain tersebut. Pada gilirannya, anggota tim lainnya perlu memahami bahwa kekurangan dalam suatu desain bukan refleksi dari desainer. Ini adalah bagian yang diharapkan dari desain. Ini juga merupakan cara anggota tim belajar dan menjadi lebih baik: dari kesalahan mereka sendiri dan kesalahan orang lain.

Jika Anda berada di tim disfungsional yang tidak berfungsi seperti ini, Anda memiliki dua opsi:

1. coba perbaiki tim
2. menemukan tim baru (baik secara internal atau di karyawan baru).

Sejauh yang saya tahu, saya selalu dapat dipertahankan secara fundamental . Itu tidak sepenuhnya sama dengan benar secara fundamental . Seringkali keadaan berubah antara saat Anda harus membuat keputusan 'x' dan waktu menjadi jelas bahwa 'x' adalah keputusan yang salah di belakang .

Ini seperti mempersiapkan pajak penghasilan AS Anda. Banyak orang berpikir seharusnya ada jawaban. Tidak ada. Anda memiliki pendapat Anda; akuntan pajak Anda memiliki pendapatnya; IRS memiliki pendapat mereka.

Ketika saya melakukan kesalahan, saya tidak kehilangan rasa hormat dari siapa pun. (Sejauh yang saya tahu.) Saya pikir itu karena, sebagian, saya selalu mengakui kesalahan saya sendiri. (Bahkan, saya sering menemukan kesalahan saya sendiri.) Juga, hampir semua keputusan desain yang signifikan memiliki lebih dari satu orang yang menandatanganinya. Kesalahan apa pun dalam keputusan itu dimiliki oleh kelompok, tidak sepenuhnya oleh satu orang.

Sejauh mengakui kesalahan, saya pikir itu semakin mudah saat Anda memperoleh kompetensi dan pengalaman. Dalam pengalaman saya, semakin baru Anda merancang dan mengembangkan, semakin kecil kemungkinan Anda mengakui kesalahan.

Itu terjadi berulang-ulang, dan itu seharusnya tidak menggagalkan karier Anda. Tidak seorang pun dalam posisi yang memiliki tanggung jawab signifikan yang selalu membuat keputusan yang benar. Faktanya, tidak ada seorang pun dalam posisi tanggung jawab yang signifikan yang selalu membuat keputusan yang dapat dipertahankan.

Tetapi sebagian besar waktu, Anda harus dapat membuat keputusan yang dapat dipertahankan berdasarkan informasi yang tidak lengkap. Seperti yang dikatakan putri saya, "Itu hanya menjadi manusia."

Setiap orang terkadang salah. Kesalahan tidak bisa dihindari. Akui dengan bebas ketika Anda salah, belajarlah dari kesalahan Anda, dan tunjukkan kerendahan hati terutama jika Anda awalnya tidak yakin bahwa Anda sebenarnya salah.

"Penghinaan" seharusnya tidak pernah terjadi. Itu tidak mungkin untuk meningkatkan kinerja seseorang sama sekali.

Di sini, di perusahaan saya, kami telah mengembangkan budaya menghormati orang-orang yang masih bersedia untuk mengambil keputusan yang sulit tetapi dapat mengakui bahwa mereka salah dan menyesuaikan perilaku mereka saat dibutuhkan.

Apakah Anda selalu benar secara fundamental dalam desain perangkat lunak yang Anda usulkan?

Ya, saya manusia super! Ya tentu saja tidak.

Ketika Anda memberikan beberapa desain yang secara fundamental salah, Anda cenderung kehilangan rasa hormat dari sesama anggota tim Anda.

Tidak! Jika itu terjadi, maka ada yang salah dengan semangat tim.

Semua orang membuat kesalahan. Beberapa solusi ternyata baik, sebagian buruk, sebagian besar diantaranya. Keberhasilan dan kegagalan harus diambil sebagai pelajaran, oleh Anda dan anggota tim lainnya.

Kesalahan pertama mungkin terasa buruk, tetapi setelah Anda membuat ratusan kesalahan, itu seperti bagian dari pekerjaan.

Itu terjadi pada semua orang. Yang terpenting adalah belajar dari kesalahan Anda dan berusaha untuk tidak membiarkannya terjadi lagi. Juga, pastikan untuk mengakui bahwa itu adalah kesalahan Anda. Sebagai contoh, saya pernah membuat kesalahan dengan menggunakan Lapisan Akses Data yang lebih rendah (SubSonic3). Pada saat saya membuat keputusan, saya hanya ingin pergi dari query SQL yang dikerjakan dengan tangan. Jadi saya memilih apa yang pada saat itu tampak sebagai salah satu yang paling mudah untuk memulai. Saya juga tidak terlalu berpengalaman dengan DAL. Nah, setelah menyelesaikan beberapa masalah saya bertanya-tanya mengapa beberapa pertanyaan terlalu lama dan menemukan SubSonic menarik seluruh tabel tanpa alasan yang baik.

Jadi, saya memberi tahu bos saya, menjelaskan saya membuat kesalahan, dan memberinya rencana untuk memperbaikinya. Bos saya tentu saja tidak antusias tentang saya membuat kesalahan yang agak besar yang memerlukan beberapa hari migrasi murni. Tapi, dia juga memastikan aku tidak melakukan kesalahan yang sama lagi. Dia membuat saya membuat proyek proof-of-concept untuk lapisan akses data berikutnya yang saya usulkan untuk dimigrasi dan kami memastikan itu akan bekerja dengan persyaratan kami, dan itu tidak menurunkan seluruh tabel. Secara keseluruhan, itu adalah pengalaman belajar yang baik bagi saya dan sekarang saya akan memastikan untuk memastikan bagian penting dari proyek memenuhi persyaratan dan tidak memiliki masalah besar.

Jadi pada dasarnya yang Anda lakukan adalah ini:

1. Akui Anda melakukan kesalahan
2. Buat rencana untuk memperbaikinya
3. Pastikan rencana Anda benar-benar berfungsi
4. Pastikan lagi.
5. Memperbaikinya!

Jika Anda tidak yakin bagaimana cara memperbaikinya, jangan takut untuk melibatkan anggota tim lainnya.

Satu hal lagi, santai! Setiap orang membuat kesalahan. Sangat sedikit orang yang sempurna pertama kali

Ini adalah hal kontes kencing geeky, dan bukan situasi yang baik untuk masuk. Tidak ada yang selalu benar, dan tidak ada yang perlu malu jika seseorang datang dengan cara yang lebih baik untuk melakukannya, atau jika mereka menemukan masalah dengan cara Anda melakukannya.

Anda perlu melepaskan diri secara emosional dari solusi Anda , dan menghabiskan waktu Anda untuk mencoba menemukan solusi terbaik , maka Anda dapat merasa senang ketika masalah diselesaikan, bahkan jika itu diselesaikan oleh orang lain.

Ada banyak hal yang tidak Anda ucapkan dalam pertanyaan Anda. Saya tidak tahu apa pengaturan Anda untuk "membagikan desain". Apakah ini diskusi awal dengan rekan tentang pendekatan yang Anda rencanakan atau apakah itu penyampaian apa yang Anda harapkan merupakan kode final?

Jika yang pertama, maka tidak ada alasan untuk merasa buruk dan tidak ada alasan bagi rekan-rekan Anda untuk mencurigai Anda di masa depan.

Jika Anda menunggu sampai pengiriman akhir untuk membahas desain Anda dengan orang lain, maka saya tidak menyalahkan mereka karena curiga dengan pekerjaan Anda yang lain.

Semua orang perlu mendiskusikan desain mereka dengan orang lain. Bergantung pada kompleksitas atau kekritisannya, Anda mungkin perlu mendiskusikannya dengan banyak orang beberapa kali. Setiap orang dapat membuat kesalahan, salah paham tentang persyaratan, atau melewatkan kasus khusus.

Kesalahan yang diidentifikasi sejak dini lebih mudah dan lebih murah untuk diperbaiki. Mereka harus sangat dimaafkan kecuali Anda mengulangi kesalahan yang sama berulang kali. Peer reviews memudahkan menangkap kesalahan lebih awal.

Jika Anda mencoba untuk menjadi seorang penyandi tunggal dalam lingkungan tim, Anda melakukan dosa dengan berpikir (hampir tidak dapat dimaafkan) bahwa Anda cukup sempurna sehingga Anda tidak memerlukan bantuan orang lain. Fakta bahwa ini adalah lingkungan tim membuktikan bahwa masalahnya cukup besar sehingga tidak ada orang yang akan mengerti semuanya. Orang-orang harus berbicara satu sama lain atau kesalahan akan memundurkan kepala mereka terlalu dekat untuk dilepaskan (atau setelah dilepaskan).

Saya selalu membuat perbedaan antara, di satu sisi, keputusan baik atau buruk; dan pada keputusan lain yang benar dan salah. Keputusan yang baik adalah keputusan yang, dalam keadaan yang sama, dengan informasi yang sama, Anda akan membuat dengan cara yang sama; keputusan yang buruk adalah keputusan yang akan Anda buat secara berbeda. Keputusan yang benar adalah keputusan yang, dengan manfaat dari belakang dan informasi tambahan, terbukti benar; dan sebaliknya dengan keputusan yang salah.

Sering dikatakan bahwa orang yang membuat keputusan yang salah tidak pernah membuat apa pun. Keputusan yang salah adalah cara seseorang belajar. Keputusan yang buruk sering diperburuk karena pembuat keputusan berinvestasi sendiri dalam keputusan itu dan mencoba untuk secara retrospektif membenarkan keputusan itu, atau membuktikan bahwa itu adalah keputusan yang baik (menutup-nutupi selalu lebih merusak daripada keputusan semula).

Sebagian besar keputusan desain yang saya buat terbukti benar, tetapi saya paling banyak belajar dan lebih maju dengan keputusan-keputusan yang salah. Saya berharap sangat sedikit dari keputusan saya adalah keputusan yang buruk, tetapi bagian dari masalah dengan keputusan buruk seseorang adalah mengakui bahwa keputusan itu buruk dan menerima pelajaran yang seringkali tidak menyenangkan yang muncul dari mereka.

Selama mereka tidak menjadi " Monday Morning Quarterback ." Saya tidak menggunakan seseorang yang duduk di semua diskusi desain tanpa mengatakan apa-apa hanya untuk mengklaim bahwa mereka tahu itu tidak akan berhasil setelah fakta. Anda harus dapat menerima kritik bahkan jika itu tidak dimasukkan ke dalam konteks yang konstruktif.

Mungkin salah satu fitur terbaik dari situs SO adalah untuk dapat mengambil risiko dan mengusulkan dan solusi yang tidak pasti. Inilah cara Anda belajar. Mengalami kehidupan dengan banyak omong kosong di kepala Anda yang salah, tetapi Anda belum pernah diberitahu tentang pengkhianatan, adalah benar-benar ketidaktahuan.

Mereka mungkin tahu sesuatu yang tidak Anda ketahui, tetapi mereka tidak akan tahu segalanya. Mengatasinya, mulai bekerja, dan menyelesaikan sesuatu. Biarkan mereka membuang waktu dengan berpikir mereka sangat pintar.

Apakah saya selalu menyediakan desain yang bagus? Tidak! Saya berusaha untuk melakukannya, saya berusaha untuk menjadi lebih baik, tetapi dengan setiap proyek berturut-turut, apa yang tampaknya selalu dapat saya lakukan adalah melihat kembali ke apa yang telah saya lakukan sebelumnya dan merasa ngeri pada bagaimana saya melewatkan tanda dalam beberapa cara.

Adapun seseorang yang telah mengusulkan desain yang kurang dari bintang, saya tidak akan menentangnya jika orang itu menunjukkan bahwa dia mau belajar dari kesalahan dan terbuka untuk kritik. Jika saya melihat bukti bahwa orang tersebut juga berusaha untuk menjadi lebih baik dan memiliki bakat untuk melakukannya, maka proposal desain yang buruk hanyalah kesempatan belajar.

Ini terjadi pada semua orang sekarang dan kemudian, jadi hal terbaik yang harus dilakukan adalah mencari tahu mengapa desainnya salah dan belajar dari itu. Jika kurang pengetahuan, maka kegagalan desain semoga akan memberi Anda beberapa pengetahuan baru yang dapat Anda gunakan lain kali. Jangan biarkan itu mengecilkan hati Anda, semua orang melewati ini di beberapa titik. Ini adalah cara terbaik untuk mendapatkan pengalaman dan menangkap dengan tim / lingkungan baru.

Ini akan sering terjadi. Industri kami berubah begitu cepat, peluang untuk tidak pernah salah secara efektif nol.

Namun, apakah Anda mendorong desain buruk itu ke atas keberatan mereka? Itu bisa jadi mengapa mereka bereaksi berlebihan.

Jika kesalahannya besar, tentu saja akan butuh waktu untuk mendapatkan kembali rasa hormat. Jika salah satu rekan kerja Anda membawa Anda ke arah yang buruk dan menciptakan masalah bagi seluruh tim, tidakkah Anda membutuhkannya untuk membuktikan dirinya lebih banyak dalam waktu dekat?

Yang dapat Anda lakukan adalah mengakui bahwa Anda salah, memberikan penghargaan kepada siapa pun yang benar, dan berusaha untuk mendengarkan dengan lebih baik dan meriset pilihan yang lebih baik di masa depan.

Apa yang menurut Anda tidak membuat kesalahan desain? (Bukan contoh acak - desain proses impor untuk menggunakan layanan web yang ada yang menjalankan baris-demi-baris (penggunaan kembali kode dan hanya perlu mengubah aturan bisnis di satu tempat) tidak menyadari bahwa beberapa impor akan memiliki jutaan catatan dan akan membutuhkan waktu berhari-hari untuk selesai.) Belajar darinya dan pertimbangkan hal-hal itu di masa depan.

Akan selalu ada kesalahan. Untuk berbuat salah adalah menjadi seorang programmer. Teruslah belajar dari orang lain di internet dan terutama dari rekan kerja Anda. Satu-satunya rasa malu di sini adalah menyerah, atau mengubur kepala Anda di pasir ketika sampai pada masalah seperti ini mulai sekarang.

Letakkan di belakang Anda, tundukkan kepala, dan lakukan yang terbaik. Jika Anda seorang programmer yang baik, Anda akan menyinari kesalahan Anda.

Jika Anda tidak yakin bahwa ide Anda berada di atas dasar yang kuat, Anda harus mendiskusikannya dengan beberapa rekan terpercaya sebelum Anda mengusulkannya ke seluruh perusahaan atau departemen. Bahkan, meskipun Anda yakin, Anda tetap harus mendiskusikannya dengan orang-orang yang bekerja dengan Anda dan yang paling mungkin mengenal Anda yang terbaik. Mereka akan membantu Anda menemukan masalah sejak dini.

Itu terjadi pada kita setiap saat. Gunakan desain pertama sebagai prototipe. Cari tahu persis apa yang berhasil dan apa yang tidak dan mengapa. Maka Anda dapat menulis produk akhir yang jauh lebih baik.

Jangan mencoba membenarkan diri sendiri atau bersikap defensif. Akui kesalahan itu dan lanjutkan.

Masalah mendasar sepertinya tidak dijelaskan: ini adalah masalah sosial . Anda dapat melihat perilaku seperti itu di hampir setiap profesi: jika Anda membuat kesalahan, dan mereka suka "mengelompokkan" Anda dalam hal-hal tertentu, itu selamanya. Itu perilaku sosial. Bahkan orang pintar dan pintar akan cenderung mengikuti semua orang.

Biarkan saya memberi Anda sebuah contoh yang tidak ada hubungannya dengan pemrograman: dalam pekerjaan saya sebelumnya, saya lupa mencuci piring, katakan sekali atau dua kali. Sejak itu, semua pekerja mengira saya adalah tipe pria yang tidak pernah mencuci piring saya. Dan sekarang begitu ada benda kotor di wastafel, ini aku (siapa lagi yang bisa).

Itu sama di mana-mana: ini adalah perilaku sosial , tidak masalah apa pun masalahnya.

Anda memberi tahu saya bahwa Anda ingin umpan balik yang jujur? Satu-satunya solusi adalah keluar dari pekerjaan lain. Jika semua orang di tim berpikir Anda tidak pandai dalam pekerjaan Anda, itu tidak akan berubah dalam waktu dekat, maaf untuk mengatakannya seperti ini. Jadi cari pekerjaan lain, karena Anda tidak akan pernah mengubah perilaku sosial (bodoh yang harus saya akui) semacam ini .

Kuncinya adalah bagaimana Anda menyatakan kasus Anda dan jenis perubahan apa yang Anda lakukan. Jika Anda mengaku sebagai guru pemrograman yang tidak salah dan lebih hebat dari Jon Skeet, maka sangat mungkin bahwa pada titik tertentu Anda akan dikalahkan karenanya. Kuncinya adalah bagaimana Anda menyajikan solusi Anda sehingga Anda dapat menunjukkan bahwa ini adalah solusi yang masuk akal untuk masalah daripada solusi sempurna yang bahkan tidak harus diperiksa.

Contoh terbaik saya adalah menemukan efek samping dari memiliki kelas staticdalam aplikasi web di mana saya pernah bekerja. Saya tidak tahu betapa buruknya memiliki satu contoh yang bertahan dan dibagikan di semua pengguna aplikasi tetapi saya belajar dari itu dan memang pulih dalam waktu. Kadang-kadang bisa jadi sesuatu ditemukan dan koreksi besar harus dilakukan. Saya telah berada di kamp itu juga di mana saya harus menyaring sekelompok VBScript untuk mengurangi rangkaian string yang menyebabkan masalah memori di mana saya pernah bekerja. Saya bahkan dapat mengingat menulis kode yang rentan terhadap suntikan SQL pada tahun 1998 ketika saya sedang menulis menemukan sepotong kode pelanggan yang harus secara dinamis menghasilkan SQL karena saya memiliki ~ 20 bidang opsional di bagian aplikasi tersebut.

Perfeksionisme bisa menjadi pedang bermata dua di sini yang merupakan cara saya melihat komentar ke-3 itu dan juga cara saya kadang-kadang juga. Yang buruk adalah melihat bahwa ada semua kesalahan ini dan tidak ada yang benar. Yang baik adalah bahwa dalam mendapatkan yang terbaik yang Anda bisa, Anda bisa bertemu jika tidak melebihi harapan orang lain terhadap Anda. Peningkatan berkelanjutan bisa menjadi cara PC untuk melihat perfeksionisme dan jika dipertahankan, saya melihat ini sebagai hal yang baik. Untuk semua kesalahan yang dilakukan, apakah kode Anda masuk ke produksi? Apakah itu menyelesaikan pekerjaan? Itu adalah poin untuk direnungkan serta jika seseorang selalu memperbaiki sesuatu di atasnya atau itu baik bahwa Anda ingin menjadi hebat begitu buruk sehingga Anda lebih suka tidak melakukan hal lain sampai itu sempurna? Latihan dapat bermanfaat untuk membantu menemukan pola untuk melakukan pekerjaan dengan lebih baik. Namun,