Memerangi Efek Einstellung [ditutup]

17

Ditutup . Pertanyaan ini perlu lebih fokus . Saat ini tidak menerima jawaban.

Ingin meningkatkan pertanyaan ini? Perbarui pertanyaan sehingga berfokus pada satu masalah hanya dengan mengedit posting ini .

Ditutup 4 tahun yang lalu .

The Einstellung Effect mengacu pada "kecenderungan seseorang untuk memecahkan masalah yang diberikan dengan cara tertentu meskipun ada 'lebih baik' atau metode yang lebih tepat untuk memecahkan masalah."

Sebagai seorang programmer dengan jumlah pengalaman yang layak, bagaimana seseorang dapat melawan kecenderungan ini untuk selalu mendekati penyelesaian masalah dari jalur yang "dicoba dan benar" dari pengalaman masa lalu?

Untuk memberikan dua contoh yang sangat konkret saya telah membangun aplikasi web untuk waktu yang lama, cukup lama untuk mendahului penggunaan kerangka kerja Javascript yang luas (misalnya jQuery) dan kerangka kerja aplikasi web yang lebih baik (misalnya ASP.NET MVC). Jika saya memiliki pekerjaan klien di mana saya berada di bawah krisis waktu atau masalah mendesak dari domain masalah atau aturan bisnis, saya cenderung hanya menggunakan apa yang saya tahu untuk mencoba mencapai solusi. Ini melibatkan hal-hal yang sangat jelek seperti

document.getElementById

atau menggunakan ASP.NET dengan kontrol terikat templat (DataList / Repeater) daripada mencari tahu bagaimana menata ulang hal-hal dengan pendekatan ASP.NET MVC.

Salah satu teknik yang saya gunakan di masa lalu adalah memiliki proyek pribadi yang ada hanya untuk mengeksplorasi teknologi baru ini tetapi ini sulit dipertahankan. Apa pendekatan lain yang bisa direkomendasikan?

learning

— David di Dakota
sumber

Apakah Anda bekerja sendiri?

— Apalala

3

hati-hati dengan kereta musik "MVC", ia memiliki tempatnya. Jika solusi Webforms berfungsi maka biarkan.

— Darknight

4

Ini pertanyaan yang bagus. Dan saya pikir bukan hanya programmer senior yang mengalami hal ini - mengatasinya lebih awal bisa menjadi cara yang bagus bagi pelajar untuk mempercepat pengembangan keterampilan mereka.

Ada dua sisi dari masalah ini - yang buruk dan yang sebenarnya bagus .

Buruk - Memilih solusi yang salah

Berikut ini adalah contoh - sebagai pengembang berpengalaman, Anda mungkin harus hanya benar-benar memecahkan dua masalah sebelumnya, masalah A dan B . Pada titik ini, Anda tahu ada masalah yang Anda tidak tahu, tetapi mengingat lensa pengalaman Anda sendiri, banyak dari apa yang Anda lihat tampak seperti itu mungkin A atau B .

Datanglah masalah baru. Untuk Anda, masalah ini baru terlihat seperti masalah A , sehingga Anda mengatasinya dengan cara Anda biasanya memecahkan A . Sesuatu tidak merasa benar, dan itu memakan waktu lebih lama, dan saat Anda bekerja Anda berakhir menyadari ini adalah masalah baru, C . Ini variasi A yang Anda tidak tahu ada.

Jadi apa yang Anda lakukan untuk tidak membuat kesalahan ini lagi? Dua hal:

Cari tahu apa yang berbeda dari masalah baru ini. Cari tahu pendekatan apa yang mungkin berhasil secara berbeda dan mengapa.
Buat katalog masalah ini dan beralih ke pemecahan lebih banyak masalah baru.

Ini akan membantu Anda memecahkan masalah ini secara alami . Pada saat Anda memiliki 10 tahun pengalaman, Anda sudah terbiasa dengan masalah A hingga Z dan daftar solusi Anda sangat luas.

Baik - Efisiensi

Di dunia nyata, dengan tenggat waktu dan sumber daya terbatas, menggunakan apa yang Anda ketahui tidak selalu buruk:

Pada awal proses penyelesaian masalah, Anda membandingkan masalah baru dengan semua masalah yang Anda tahu.
Anda akan berusaha mengenali tanda-tanda dan memutuskan masalah seperti apa yang terlihat.
Jika kecocokan 100% tidak dapat dilakukan, pengembang yang berpengalaman akan mempertimbangkan risiko menghabiskan lebih banyak waktu dalam penemuan terhadap risiko eksekusi yang mungkin cacat. Jika risiko waktu yang terbuang terlalu tinggi, maka Anda cukup melanjutkan apa yang Anda ketahui.

Itu bukan hal yang buruk - menggunakan analisis risiko untuk memilih efisiensi lebih dari 100% akurasi. Itu dilakukan setiap hari dan kita semua akan terikat pada hal-hal yang tidak membawa kita kemana-mana jika kita tidak melakukannya.

Jadi, untuk menjawab pertanyaanmu:

Sebagai seorang programmer dengan jumlah pengalaman yang layak, bagaimana seseorang dapat melawan kecenderungan ini untuk selalu mendekati penyelesaian masalah dari jalur yang "dicoba dan benar" dari pengalaman masa lalu?

Terus mencari dan membuat katalog masalah baru
Lebih baik dalam memilih solusi yang tepat untuk masalah; alih-alih hanya mengetahui solusi mana, ketahuilah mengapa itu benar.
Latih dan asah keterampilan membuat keputusan Anda . Terkadang efisiensi adalah pilihan yang tepat, dan semakin baik dalam mengenali saat-saat itu akan mengarah pada keuntungan dunia nyata yang terukur.

— Nicole
sumber

Saya suka jawaban ini, terima kasih telah meluangkan waktu.

— David di Dakota

9

Sisihkan 20% dari waktu kerja Anda untuk meningkatkan keterampilan Anda / melakukan hal-hal yang benar daripada cepat. Jika tidak, Anda perlahan mulai tertinggal. Ini mungkin berarti bahwa Anda mendapatkan lebih sedikit pekerjaan yang dilakukan dalam jangka pendek, tetapi dalam jangka panjang investasi akan terbayar.

Bagian yang sulit adalah menahan tekanan untuk memotong sudut ini. Sampai kebiasaan itu tertanam, jangan memotong sudut itu. Setelah Anda berada di titik di mana Anda menganggap investasi dalam keterampilan Anda ini sebagai "normal", Anda kemudian dapat memilih untuk sesekali bergegas melalui suatu proyek. Sementara itu, jangan anggap waktu ini opsional dan bentuk perkiraan Anda yang sesuai.

— Ethel Evans
sumber

2

jika Anda punya waktu untuk itu, tingkatkan 20%. Aku bahkan tidak berpengalaman, tapi aku sudah membayangkan ini: melakukannya dengan benar selalu terbayar pada akhirnya. Juga, semakin banyak pengetahuan yang Anda miliki tentang melakukannya dengan benar, semakin cepat Anda akan menyelesaikannya dengan benar dan pada akhirnya (well, itulah yang saya harap; P) keduanya akan bergabung bersama dan Anda akan dapat melakukan hampir semuanya dengan benar DAN cepat.

— stijn

btw apa yang terjadi pada saya lebih sering daripada tidak: mulai sesuatu, mengetahui bahwa itu tidak sepenuhnya benar, maka 2 hari kemudian kehilangan jumlah waktu yang gila karena hal yang saya tahu salah pada awalnya sekarang perlu refactoring untuk memperbaikinya, setelah semua.

— stijn

1

Atau 50% ketika pekerjaan sedang rendah, atau bahkan lebih di antara proyek. Tidak ada yang pernah saya pelajari telah terbuang sia-sia. Itu semua telah digunakan lebih cepat daripada nanti, bahkan jika hanya untuk memiliki pendapat yang terinformasi ketika itu penting.

— Apalala

5

Pengembangan Perangkat Lunak, dalam pandangan saya tidak selalu tentang menemukan solusi mutlak * terbaik *, tetapi menyelesaikan sesuatu. Jadi mungkin jika Anda tidak selalu menyelesaikan masalah dengan cara terbaik, itu bukan akhir dunia.

Namun, jika Anda merasa bahwa melakukan sesuatu dengan cara terbaik adalah penting, maka saya pikir taruhan terbaik akan dikembangkan sebagai bagian dari tim. Diskusikan desain dan lakukan tinjauan kode dengan rekan kerja. Karena orang biasanya memiliki latar belakang dan preferensi yang berbeda, antara dua atau tiga orang, Anda harus memiliki beberapa masalah dan solusi yang berbeda.

— apoorv020
sumber

Membuat diri Anda sibuk dengan pekerjaan sering berarti menjaga diri Anda sama produktifnya dengan pria yang mempelajari teknologi "terbaik" berikutnya. Saya akan menghitung tiga dekade di perdagangan, dan sebagian besar yang saya ingat dari semuanya adalah belajar, belajar, dan belajar lebih banyak.

— Apalala

+1 untuk pemrograman (setidaknya pemrograman profesional) adalah tentang menulis kode yang menyelesaikan pekerjaan alih-alih kode yang secara teoritis sempurna itu adalah karya seni.

— jwenting

3

Sebagai seorang programmer dengan jumlah pengalaman yang layak, bagaimana seseorang dapat melawan kecenderungan ini untuk selalu mendekati penyelesaian masalah dari jalur yang "dicoba dan benar" dari pengalaman masa lalu?

Refactor secara teratur. Refactoring mengharuskan kami memeriksa kode yang kami tulis sebelumnya. Kita dapat menggunakan waktu ini untuk melihat kode lama dengan perspektif baru. Selama Anda mengikuti perubahan teknologi besar, orang dapat membuat pembaruan yang Anda anggap perlu.

Jika saya memiliki pekerjaan klien di mana saya berada di bawah krisis waktu atau masalah mendesak dari domain masalah atau aturan bisnis, saya cenderung hanya menggunakan apa yang saya tahu untuk mencoba mencapai solusi.

Baik. Anda berfokus pada kebutuhan klien daripada tujuan Anda sendiri. Jalan untuk pergi.

Ini melibatkan hal-hal yang sangat jelek seperti

document.getElementById

atau menggunakan ASP.NET dengan kontrol terikat templat (DataList / Repeater) daripada mencari tahu bagaimana menata ulang hal-hal dengan pendekatan ASP.NET MVC.

Tidak ada yang salah dengan Webforms. MVC tidak dimaksudkan untuk menggantikan Webform. Ini juga bukan waktu untuk mempelajari teknologi baru. Ingat segitiga itu. Refactor ketika Anda punya waktu. Juga, lihat pernyataan pertama.

Salah satu teknik yang saya gunakan di masa lalu adalah memiliki proyek pribadi yang ada hanya untuk mengeksplorasi teknologi baru ini tetapi ini sulit dipertahankan. Apa pendekatan lain yang bisa direkomendasikan?

Apa yang sulit dipertahankan? Semoga Anda tidak memelihara proyek yang dirancang untuk Anda pelajari. Jika demikian, buang proyek sampel. Tidak ada yang salah dengan membuat satu proyek untuk tujuan pembelajaran. Ini adalah hal yang sangat bagus. Lihat pernyataan pertama.

Sudah mencoba dan benar! = Buruk. "Efek Einstellung" diambil sedikit di luar konteks di sini. Tes mengacu pada orang yang mengoptimalkan "membuka stoples". Metode "membuka botol" orang terbatas dan tidak meningkat seiring waktu (tidak termasuk barang-barang Sci-Fi). Dalam perangkat lunak, cara terbaik untuk "mencapai tugas X" memang berubah seiring waktu.

— P.Brian.Mackey
sumber

2

Sesuatu yang membantu berpikir di luar kotak adalah memiliki praktik nyata untuk melakukannya. Edward De Bono telah menulis banyak buku tentang pemikiran lateral dan mata pelajaran terkait.

Tetapi pada setiap titik keputusan tertentu, yang paling penting adalah menilai dan merangkul risiko. Waltzing with Bears oleh De Marco dan Lister adalah salah satu buku terbaik tentang subjek ketika diterapkan untuk pengembangan perangkat lunak.

Pemrograman Ekstrim dan metodologi lincah lainnya mengusulkan bahwa seseorang harus melanjutkan dan bereksperimen dengan solusi baru (lonjakan) sebagai masalah rutin. Saya melakukan percobaan dengan berbagai teknologi selama startup proyek, dan itu telah menyelamatkan saya beberapa kali dari jatuh cinta pada hyped demi yang benar dan mencoba, dan kadang-kadang untuk menemukan permata teknologi baru.

— Apalala
sumber

1

Sebagai tim, Anda dapat mengubah grup dengan mengenali kehebatan pola pemecah pola. Saya sering menggunakan orang baru untuk ini, karena mereka tidak masuk ke cara normal dalam melakukan sesuatu. Ini agak jawaban manajerial - tetapi bahkan sebagai insinyur yang berpengalaman, saya pikir Anda dapat menyadari bahwa pandangan orang lain mungkin kurang bias dan jadi pertimbangkan dengan peringkat paling tidak sebanyak pendapat Anda sendiri (mungkin bahkan lebih).

— bethlakshmi
sumber

1

Apakah Anda yakin itu bukan hanya apa yang akan Anda masukkan alih-alih dokumen.getElementById benar-benar membuang-buang waktu tidak peduli seberapa akomodatif Anda dengan itu?

Sunting: Saya baru sadar, kedua contoh Anda tentang alat, ini bisa jadi karena Anda menganggap mengubah alat Anda menjadi tonggak terbesar pengembangan keterampilan Anda. Seorang pembuat kode yang baik membutuhkan sedikit lebih banyak daripada bahasa lengkap Turing untuk mengerjakan keajaibannya, itu tidak berarti alat tidak penting, tetapi apa yang Anda gunakan sudah tidak tepat toolset bawah batu. Jika pindah dari satu alat ke alat lainnya adalah kemajuan terbesar yang dapat Anda pikirkan maka mungkin Anda pada dasarnya terhenti di area yang kurang dapat diukur.

— aaaaaaaaaaaa
sumber

1

Saya tidak yakin apa yang Anda maksud; Saya merujuk menggunakan penyeleksi jQuery sebagai pendekatan yang lebih baik. Menggunakan DOM langsung berfungsi dengan baik, tetapi jQuery adalah pendekatan yang jauh lebih baik. Jadi untuk menjadi jelas, keduanya bekerja, yang satu lebih baik dari yang lain.

— David di Dakota

1

Yah, $("#id")lebih pendek, tetapi pada akhirnya hanya alias untuk document.getElementById("id")dengan beberapa overhead di atas. Apakah Anda tahu itu akan meningkatkan alur kerja Anda? Atau apakah Anda baru saja diberi tahu bahwa jQuery lebih baik berkali-kali sehingga Anda memercayainya?

— aaaaaaaaaaaa

1

@eBusiness - Tahukah Anda bahwa $("#id")pada akhirnya hanya merupakan alias untuk document.getElementById("id")? Atau apakah Anda baru saja diberitahu itu berkali-kali sehingga Anda memercayainya? Saya berharap bahwa setiap kali Anda menggunakan getElementByIdAnda ingat untuk menangani kasus di mana IE dan Opera mengembalikan elemen dengan nama dan juga kasus ketika Blackberry 4.6 mengembalikan node yang tidak lagi ada dalam dokumen.

— Nick Knowlson

Jika Anda menggunakan pengidentifikasi yang sama untuk nama dan id objek yang berbeda atau kode Anda tidak dapat 'mengingat' objek apa yang telah dihapus maka menggunakan jQuery praktis. Kalau tidak, itu hanya mengasapi yang menyeret kecepatan kode Anda ke bawah. Saya tidak mengatakan bahwa apa yang dilakukan jQuery salah, tetapi itu tidak lebih baik untuk setiap tujuan.

— aaaaaaaaaaaa

1

Saya tahu saya memicu ini, tapi saya pikir kami bergerak agak terlalu jauh ke jQuery versus JavaScript flamewar.

— aaaaaaaaaaaa

1

Sebagai seorang programmer dengan jumlah pengalaman yang layak, bagaimana seseorang dapat melawan kecenderungan ini untuk selalu mendekati penyelesaian masalah dari jalur yang "dicoba dan benar" dari pengalaman masa lalu?

Kesadaran diri

Waspadai kecenderungan Anda, kelemahan dan kekuatan Anda.

Keputusan Sadar

Buat keputusan Anda eksplisit dan sadar. Jangan melompat untuk melakukan sesuatu tanpa secara sadar memikirkan bagaimana Anda akan melakukannya.

Pelajari dan Terapkan

Lanjutkan untuk mempelajari teknik-teknik baru dan pertimbangkan di mana mereka dapat diterapkan. Ketika Anda mengalami situasi di mana itu dapat diterapkan, lakukan analisis biaya-manfaat. Terkadang manfaat untuk mencoba sesuatu yang baru melebihi manfaat dari solusi yang dikenal.

— dietbuddha
sumber