Борьба с эффектом Einstellung [закрыто]

Эффект Einstellung относится к «предрасположенности человека решать конкретную проблему определенным образом, даже если существуют« лучшие »или более подходящие методы решения проблемы».

Как программист с приличным опытом, как можно бороться с этой тенденцией всегда подходить к решению проблем с «проверенных и истинных» путей из прошлого опыта?

Чтобы привести два очень конкретных примера, я долго создавал веб-приложения, достаточно долго, чтобы предшествовать широкому использованию фреймворков Javascript (например, jQuery) и более качественных фреймворков веб-приложений (например, ASP.NET MVC). Если у меня есть клиентская работа, где я испытываю затруднения или сталкиваюсь с проблемами из предметной области или бизнес-правил, я, как правило, просто использую то, что знаю, чтобы найти решение. Это включает в себя очень уродливые вещи, такие как

document.getElementById 

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

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

Это большой вопрос. И я думаю, что это не только старшие программисты, которые сталкиваются с этим - раннее решение может быть отличным способом для ученика ускорить развитие своих навыков.

У этой проблемы есть две стороны: одна плохая, а другая действительно хорошая .

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

Вот пример - как неопытный разработчик, вы можете иметь только действительно решить две проблемы до того , проблемы A и B . На данный момент, вы знаете , есть проблемы , которые вы не знаете, но , учитывая объектив вашего собственного опыта, много того , что вы видите , как выглядит это может быть или B .

Вдоль новой проблемы. Для вас эта новая проблема выглядит как проблема А , так вы решить ее так , как вы обычно решить A . Что - то не чувствует себя хорошо, и это занимает больше времени, и , как вы работаете вы в конечном итоге понимая , что это новая проблема, C . Это вариация А, о которой ты не знал.

Итак, что вы делаете, чтобы не повторить эту ошибку? Две вещи:

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

Это должно помочь вам естественным образом решить эту проблему. К тому времени, как у вас есть 10-летний опыт работы, вы уже знакомы с проблемами от А до Я, и у вас обширный перечень решений.

Хорошо - Эффективность

В реальном мире, с крайними сроками и ограниченными ресурсами, использование того, что вы знаете, не всегда плохо:

1. В начале процесса решения проблем вы сравниваете новую проблему со всеми проблемами, которые вы знаете.
2. Вы попытаетесь распознать признаки и решить, на какую проблему это похоже.
3. Если 100% -ное совпадение не может быть достигнуто, опытный разработчик будет взвешивать риск тратить больше времени на обнаружение против рисков возможного ошибочного выполнения. Если риск потерянного времени слишком высок, тогда просто продолжайте с тем, что вы знаете.

Это не плохо - он использует анализ рисков, чтобы выбрать эффективность более 100% точности. Это делается каждый день, и мы все были бы связаны тем, что нас никуда не привело, если бы мы этого не делали.

Итак, чтобы ответить на ваш вопрос:

Как программист с приличным опытом, как можно бороться с этой тенденцией всегда подходить к решению проблем с «проверенных и истинных» путей из прошлого опыта?

1. Продолжайте искать и каталогизировать новые проблемы
2. Получить лучший выбор правильного решения проблемы; вместо того, чтобы просто знать, какое решение, знать, почему это правильно.
3. Практикуйте и оттачивайте свои навыки принятия решений. Иногда эффективность является правильным выбором, и улучшение понимания этих времен приведет к ощутимым реальным преимуществам.

Выделите 20% своего рабочего времени, чтобы улучшить свои навыки / делать все правильно, а не быстро. В противном случае вы медленно начнете отставать. Это может означать, что в краткосрочной перспективе вы выполняете меньше работы, но в долгосрочной перспективе эти инвестиции окупятся.

Трудная часть сопротивляется давлению, чтобы срезать углы на этом. Пока привычка не укоренилась, просто не обрезай этот угол. Когда вы считаете, что эти инвестиции в ваши навыки являются «нормальными», вы можете время от времени спешить с проектом. В то же время, не считайте это время необязательным и формируйте свои оценки соответственно.

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

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

Как программист с приличным опытом, как можно бороться с этой тенденцией всегда подходить к решению проблем с «проверенных и истинных» путей из прошлого опыта?

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

Если у меня есть клиентская работа, где я испытываю затруднения или сталкиваюсь с проблемами из предметной области или бизнес-правил, я, как правило, просто использую то, что знаю, чтобы найти решение.

Хорошо. Вы концентрируетесь на потребностях клиента, а не на своих целях. Путь

Это включает в себя очень уродливые вещи, такие как

document.getElementById

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

В вебформах нет ничего плохого. MVC не предназначен для замены веб-форм. Сейчас не время изучать новые технологии. Помните треугольник. Рефакторинг, когда у тебя есть время. Также см. Первое утверждение.

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

Что трудно выдержать? Надеюсь, вы не поддерживаете проекты, разработанные для вас, чтобы учиться. Если так, выбросьте примеры проектов. Нет ничего плохого в создании одноразовых проектов для учебных целей. Это очень хорошая вещь. Смотрите первое утверждение.

Испытано и верно! = Плохо. «Эффект Einstellung» здесь немного вырван из контекста. Тесты относятся к людям, которые оптимизируют «открытие банки». Народные методы «открытия банки» ограничены и не совершенствуются с течением времени (исключая любые научно-фантастические вещи). В программном обеспечении лучший способ «решить задачу X» меняется со временем.

То, что помогает мыслить нестандартно, - это практическая практика для этого. Эдвард Де Боно написал много книг о латеральном мышлении и смежных темах.

Но в любой момент принятия решения наиболее важным является оценка и принятие риска. Де Марко и Листер « Вальсирование с медведями » - одна из лучших книг на эту тему применительно к разработке программного обеспечения.

Экстремальное программирование и другие гибкие методологии предлагают просто идти вперед и экспериментировать с новыми (всплесками) решениями как с рутиной. Я проводил эксперименты с различными технологиями во время стартапов проектов, и это несколько раз спасало меня от шумихи в пользу истинного и проверенного, а иногда и открытия нового технологического сокровища.

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

Вы уверены, что это не просто то, что вы положили бы вместо document.getElementById - это действительно пустая трата времени, независимо от того, насколько вы готовы к этому?

Редактировать: Я только что понял, что оба ваших примера касаются инструментов, это может быть потому, что вы считаете, что изменение инструментов является самой важной вехой в развитии ваших навыков. Хорошему кодировщику нужно чуть больше, чем полный язык Тьюринга, чтобы творить чудеса, то есть инструменты не важны, но то, что вы используете, уже не совсем набор инструментов. Если переход от одного инструмента к другому является самым большим прогрессом, о котором вы только можете подумать, возможно, вы оказались в тупике в менее поддающихся количественной оценке областях.

Как программист с приличным опытом, как можно бороться с этой тенденцией всегда подходить к решению проблем с «проверенных и истинных» путей из прошлого опыта?

Самосознание

Осознайте свои тенденции, свои слабости и свои сильные стороны.

Сознательные Решения

Сделайте ваши решения явными и осознанными. Не прыгайте, чтобы сделать что-то, не задумываясь о том, как вы это сделаете.

Учиться и применять

Продолжайте изучать новые методы и подумайте, где они могут быть применены. Когда вы сталкиваетесь с ситуацией, когда это может быть применено, проведите анализ затрат и выгод. Иногда выгода от попыток чего-то нового перевешивает пользу от известного решения.