Боротьба з ефектом Ейнштелунга [закрито]

Einstellung Ефект відноситься до «схильності людини вирішити дану проблему в певному порядку , незважаючи на те, що є" краще "або більш підходящі методи вирішення цієї проблеми.»

Як програміст з пристойним обсягом досвіду, як можна боротися з цією тенденцією завжди підходити до вирішення проблем із "перевірених і правдивих" шляхів з минулого досвіду?

Наводячи два дуже конкретні приклади, я будував веб-додатки вже давно, досить довго, щоб перед цим широко використовувати рамки Javascript (наприклад, jQuery) та кращі рамки веб-додатків (наприклад, ASP.NET MVC). Якщо у мене є робота з клієнтами, де я перебуваю під час стискання або нагальних проблем із проблемної області чи правил бізнесу, я намагаюся просто використовувати те, що знаю, щоб спробувати досягти рішення. Це стосується дуже некрасивих речей на кшталт

document.getElementById 

або використовувати ASP.NET з керованими шаблонами елементами управління (DataList / Repeater), а не з'ясовувати, як перерозподілити речі за допомогою підходу ASP.NET MVC.

Однією з методик, яку я використовував у минулому, є створення персональних проектів, які існують просто для вивчення цих нових технологій, але це важко підтримати. Які ще підходи можна рекомендувати?

Це чудове питання. І я думаю, що не просто старші програмісти стикаються з цим - його вирішення може бути чудовим способом прискорити розвиток навичок.

У цьому питанні є дві сторони - та, яка погана, і насправді хороша .

Погано - вибір неправильного рішення

Ось приклад - як недосвідчений розробник, ви можете мати тільки дійсно вирішити дві проблеми до того , проблеми A і B . На даний момент, ви знаєте , є проблеми , які ви не знаєте, але , з огляду на об'єктив вашого власного досвіду, багато того , що ви бачите , як виглядає це може бути або B .

Поряд виникає нова проблема. Для вас ця нова проблема виглядає як проблема А , так ви розв'язати цю проблему так , як ви зазвичай вирішити A . Що - то не відчуває себе добре, і це займає більше часу, і , як ви працюєте ви в кінцевому підсумку розуміючи , що це нова проблема, C . Це варіант А, якого ви не знали, що існує.

То що ж робити, щоб не помилитися знову? Дві речі:

1. З’ясуйте, чим відрізнялася ця нова проблема. З’ясуйте, які підходи могли працювати по-різному і чому.
2. Каталогізуйте цю проблему і переходьте до вирішення нових нових проблем.

Це має допомогти вам природно вирішити цю проблему. На той час, коли ви маєте 10-річний досвід, ви знайомі з проблемами від A до Z і ваш репертуар рішень великий.

Добре - ефективність

У реальному світі, з обмеженими термінами та обмеженими ресурсами, використання того, що ви знаєте, не завжди є поганим:

1. На початку процесу вирішення проблем ви порівнюєте нову проблему з усіма проблемами, які ви знаєте.
2. Ви спробуєте розпізнати знаки та вирішити, який набір проблем це виглядає.
3. Якщо 100% збігу неможливо здійснити, досвідчений розробник зважить ризик витратити більше часу на розкриття проти ризиків можливого несправного виконання. Якщо ризик витраченого часу занадто високий, то ви просто продовжуйте те, що знаєте.

Це не погано - це за допомогою аналізу ризиків вибирати ефективність із 100% точністю. Це робиться щодня, і всі ми були би прив'язані до речей, які нікуди не дістають нас, якби ми цього не зробили.

Отже, щоб відповісти на ваше запитання:

Як програміст з пристойним обсягом досвіду, як можна боротися з цією тенденцією завжди підходити до вирішення проблем із "перевірених і правдивих" шляхів з минулого досвіду?

1. Продовжуйте шукати та каталогізувати нові проблеми
2. Отримайте кращий вибір правильного рішення проблеми; замість того, щоб просто знати, яке рішення, знайте, чому це правильно.
3. Практикуйте та відточуйте свої навички прийняття рішень. Іноді ефективність - це правильний вибір, а покращення визнання тих часів призведе до вимірюваних переваг у реальному світі.

Виділіть 20% робочого часу, щоб покращити свої вміння / робити речі правильно, а не швидко. Інакше ти повільно починаєш відставати. Це може означати, що ви отримаєте менше роботи за короткий термін, але в довгостроковій перспективі ці інвестиції окупляться.

Важка частина чинить опір тиску, щоб вирізати кути на цьому. Поки звичка не вроджується, просто не вирізайте цей куточок. Опинившись на місці, коли ви вважаєте, що ця інвестиція у ваші навички є "нормальною", ви можете час від часу поспішати через проект. Тим часом не вважайте цей час необов’язковим і формуйте свої оцінки відповідно.

Розробка програмного забезпечення, на мою думку, не завжди полягає у пошуку абсолютного * найкращого рішення, а в тому, щоб виконати справи. То, може, якщо ви не завжди вирішите проблему найкращим чином, це ще не кінець світу.

Однак, якщо ти вважаєш, що робити справи найкращим чином, я вважаю, що найкраща ставка буде розвиватися як частина команди. Обговоріть дизайн та робіть огляд коду з колегами. Оскільки люди зазвичай мають різний досвід і переваги, між двома або трьома людьми, у вас повинно бути кілька різних проблем і рішень.

Як програміст з пристойним обсягом досвіду, як можна боротися з цією тенденцією завжди підходити до вирішення проблем із "перевірених і правдивих" шляхів з минулого досвіду?

Рефактор регулярно. Рефакторинг вимагає, щоб ми перевірили код, який ми писали раніше. Цей час ми можемо використати для перегляду старого коду зі свіжою перспективою. Поки ви будете в курсі основних змін технологій, ви можете робити оновлення, як вважаєте за потрібне.

Якщо у мене є робота з клієнтами, де я перебуваю під час стискання або нагальних проблем із проблемної області чи правил бізнесу, я намагаюся просто використовувати те, що знаю, щоб спробувати досягти рішення.

Добре. Ви орієнтуєтесь на потреби клієнта, а не на власні цілі. Шлях.

Це стосується дуже некрасивих речей на кшталт

document.getElementById

або використовувати ASP.NET з керованими шаблонами елементами управління (DataList / Repeater), а не з'ясовувати, як перерозподілити речі за допомогою підходу ASP.NET MVC.

З веб-формами немає нічого поганого. MVC не призначений для заміни веб-форм. Це ще не час для вивчення нової технології. Пригадайте трикутник. Рефактор, коли у вас є час. Також дивіться перше твердження.

Однією з методик, яку я використовував у минулому, є створення персональних проектів, які існують просто для вивчення цих нових технологій, але це важко підтримати. Які ще підходи можна рекомендувати?

Що важко витримати? Сподіваємось, ви не підтримуєте проекти, розроблені для того, щоб ви могли вчитися. Якщо так, викиньте зразки проектів. Немає нічого поганого в створенні разових проектів для навчальних цілей. Це дуже гарна річ. Дивіться перше твердження.

Спробував і справжнє! = Погане. "Ефект Ейнштеллунга" тут трохи вийшов з контексту. Тести стосуються людей, що оптимізують "відкриття банки". Народні методи "відкривання баночки" обмежені і не вдосконалюються з часом (виключаючи будь-які матеріали Sci-Fi). У програмному забезпеченні найкращий спосіб "досягти завдання X" з часом змінюється.

Щось, що допомагає мислити поза межами, - це фактична практика для цього. Едвард Де Боно написав багато книг про латеральне мислення та супутні теми.

Але в будь-який момент прийняття рішення найважливішим є оцінка та прийняття ризику. Вальсинг з ведмедями Де Марко та Лістера - одна з найкращих книг з цього приводу при застосуванні до розробки програмного забезпечення.

Екстремальне програмування та інші гнучкі методології пропонують просто рухатися вперед і експериментувати з новими (шипковими) рішеннями як правило. Я провожу експерименти з різними технологіями під час запуску проектів, і це врятувало мене кілька разів від падіння за скаргами на користь справжнього і спробуваного, а іноді і для відкриття нового технологічного дорогоцінного каміння.

Як команда, ви можете змінити групу, розпізнавши дивовижну дивовижність. Я часто використовую для цього нових людей, тому що вони не порушені у звичайному порядку. Це дещо управлінська відповідь - але навіть як досвідчений інженер, я думаю, ви можете зрозуміти, що чужий погляд може бути менш упередженим, і так подумайте з рейтингом принаймні такої ваги, як ваша власна думка (можливо, навіть більше).

Ви впевнені, що це не просто те, що ви б поставили замість document.getElementById - це справді марно витрачає час, незалежно від того, наскільки ви вміли до нього?

Редагувати: Я щойно зрозумів, що обидва ваші приклади стосуються інструментів. Це може бути тому, що ви вважаєте, що зміна інструментів є найбільшою віхою вашого розвитку навичок. Хорошому кодеру потрібно трохи більше, ніж тюрінг повною мовою, щоб творити свої чудеса, тобто не сказати, що інструменти не важливі, але те, що ви вже використовуєте, не є саме інструментальним набором дна. Якщо перехід від одного інструменту до іншого - це найбільший прогрес, про який ви можете подумати, то, можливо, ви в основному зупинилися в менш обчислюваних областях.

Як програміст з пристойним обсягом досвіду, як можна боротися з цією тенденцією завжди підходити до вирішення проблем із "перевірених і правдивих" шляхів з минулого досвіду?

Самосвідомість

Будьте в курсі своїх тенденцій, ваших слабких сторін і своїх сильних сторін.

Свідомі рішення

Зробіть свої рішення чіткими та усвідомленими. Не стрибайте робити щось, не усвідомлюючи, як ви це зробите.

Вивчайте та застосовуйте

Продовжуйте вивчати нові методики та розглядайте, де їх можна застосувати. Натрапивши на ситуацію, коли її можна застосувати, зробіть аналіз витрат та вигод. Іноді користь від спроби чогось нового перевищує користь відомого рішення.