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

17

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

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

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

document.getElementById 

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

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

Дэвид в Дакоте
источник
Ты работаешь в одиночку?
Апалала
3
будьте осторожны с "MVC", у него есть свое место. Если решение Webforms работает, пусть так и будет.
Darknight

Ответы:

4

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Этель Эванс
источник
2
если у вас есть время, увеличьте 20%. Я даже не такой опытный, но я уже понял это: правильное выполнение всегда окупается в конце. Кроме того, чем больше у вас знаний о правильных действиях, тем быстрее вы сделаете все правильно и в конечном итоге (ну, это то, на что я надеюсь; P) оба слиться воедино, и вы сможете делать практически все правильно И быстро.
Stijn
Кстати, что случается со мной чаще, чем нет: начинайте что-то, зная, что это не совсем правильно, затем через 2 дня теряете безумное количество времени, потому что то, что я знала, было неправильным, во-первых, теперь требуется рефакторинг, чтобы сделать это правильно, после все.
Stijn
1
Или 50%, когда работа на низком уровне, или даже больше между проектами. Ничто из того, что я изучал, не пропало даром. Все это использовалось раньше, чем позже, даже если только для того, чтобы иметь обоснованное мнение, когда это важно.
Апалала
5

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

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

apoorv020
источник
Заниматься работой часто означает сохранять себя таким же продуктивным, как парень, который изучил следующую «лучшую» технологию. Я собираюсь рассчитывать на три десятилетия на торговлю, и большая часть того, что я помню из всего этого, - учиться, учиться и еще учиться.
Апалала
+1 за программирование (по крайней мере, профессиональное программирование) за написание кода, который выполняет свою работу, а не за теоретически совершенный код, который является произведением искусства.
С
3

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

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

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

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

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

document.getElementById

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

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

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

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

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

P.Brian.Mackey
источник
2

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

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

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

апалала
источник
1

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

bethlakshmi
источник
1

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

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

AAAAAAAAAAAA
источник
1
Я не уверен, что вы имеете в виду; Я имел в виду использование селекторов jQuery как лучший подход. Использование прямого DOM работает хорошо, но jQuery - гораздо лучший подход. Таким образом, чтобы быть ясно, оба работают, один просто лучше, чем другой.
Дэвид в Дакоте
1
Ну, $("#id")короче, но в конечном итоге просто псевдоним для document.getElementById("id")некоторых сверху. Знаете ли вы, что это улучшит ваш рабочий процесс? Или вам только что сказали, что jQuery лучше столько раз, что вы в это верите?
аааааааааааа
1
@eBusiness - Знаете ли вы, что $("#id")в конечном итоге это просто псевдоним для document.getElementById("id")? Или вам только что говорили так много раз, что вы в это верите? Я надеюсь, что каждый раз, когда вы используете его, getElementByIdвы не забываете обращаться со случаем, когда IE и Opera возвращают элементы по имени, а также со случаем, когда Blackberry 4.6 возвращает узлы, которых больше нет в документе.
Ник Ноулсон
Если вы используете один и тот же идентификатор для имени и идентификатора различных объектов или ваш код не может «запомнить», какие объекты он удалил, тогда использование jQuery является практичным. В противном случае это не что иное, как раздувание, которое снижает скорость вашего кода. Я не говорю, что то, что делает jQuery, неправильно, но это не лучше для каждой цели.
aaaaaaaaaaaa
1
Я знаю, что это спровоцировало это, но я думаю, что мы слишком далеко заходим в jQuery против JavaScript flawarwar.
аааааааааааа
1

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

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

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

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

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

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

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

dietbuddha
источник