Combating the Einstellung Effect [closed]

Question

The Einstellung Effect refers to "a person's predisposition to solve a given problem in a specific manner even though there are "better" or more appropriate methods of solving the problem."

As a programmer with a decent amount of experience, how can one combat this tendency to always approach problem solving from "tried and true" paths from past experience?

To give two very concrete examples I have been building web applications for a long time, long enough to predate wide use of Javascript frameworks (e.g. jQuery) and better web application frameworks (e.g. ASP.NET MVC). If I have client work where I am under a time crunch or pressing issues from the problem domain or business rules, I tend to just use what I know to try to achieve a solution. This involves very ugly things like

document.getElementById 

or using ASP.NET with template bound controls (DataList/Repeater) rather than figuring out how to rearchitect things with an ASP.NET MVC approach.

One technique I've used in the past is to have personal projects which exist simply for exploring these new technologies but this is difficult to sustain. What other approaches could be recommended?

Answer 1

This is a great question. And I think it isn't just senior programmers that run into this — addressing it early can be a great way for a learner to accelerate their skill development.

There are two sides to this issue - one that is bad and one that is actually good.

Bad - Picking the wrong solution

Here's an example — as an inexperienced developer, you may have only really solved two problems before, problems A and B. At this point, you know there are problems you don't know, but given the lens of your own experience, a lot of what you see looks like it might be A or B.

Along comes a new problem. To you, this new problem looks like problem A, so you solve it the way you usually solve A. Something doesn't feel right, and it takes longer, and as you work you end up realizing this is a new problem, C. It's a variation of A you didn't know existed.

So what do you do to not make this mistake again? Two things:

1. Figure out what was different about this new problem. Figure out what approaches may have worked differently and why.
2. Catalog this problem away and move on to solving more new problems.

This should help you naturally solve this problem. By the time you have 10 years of experience, you are familiar with problems A through Z and your repertoire of solutions is extensive.

Good - Efficiency

In the real world, with deadlines and limited resources, using what you know isn't always bad:

1. At the onset of the problem-solving process, you compare the new problem to all problems you know.
2. You'll attempt to recognize the signs and decide which problem set this looks like.
3. If a 100% match can't be made, an experienced developer will weigh the risk of spending more time in discovery against the risks of a possibly flawed execution. If the risk of wasted time is too high, then you just go ahead with what you know.

That isn't a bad thing - it's using risk analysis to choose efficiency over 100% accuracy. It's done every day and we'd all be tied up in things that aren't getting us anywhere if we didn't do it.

So, to answer your question:

As a programmer with a decent amount of experience, how can one combat this tendency to always approach problem solving from "tried and true" paths from past experience?

1. Keep looking for and cataloging new problems
2. Get better at selecting the right solution for the problem; instead of just knowing which solution, know why it's right.
3. Practice and hone your decision-making skills. Sometimes efficiency is the right choice, and getting better at recognizing those times will lead to measurable real-world advantages.

Answer 2

Set aside 20% of your work time to improve your skills / do things right instead of fast. Otherwise, you slowly start to fall behind. This might mean that you get less work done in the short-term, but in the long term that investment will pay off.

The hard part is resisting the pressure to cut corners on this. Until the habit is ingrained, just don't cut that corner. Once you are at the point where you consider this investment in your skills to be "normal", you can then choose to occasionally rush through a project. In the meantime, don't consider this time optional and form your estimates accordingly.

Answer 3

Software Development, in my view is not always about finding the absolute *best* solution, but getting things done. So maybe if you do not always solve the problem in the best way, that is not the end of the world.

However, if you do feel that doing things in the best manner is important, then I think the best bet would be develop as part of a team. Discuss design and do code reviews with colleagues. Since people normally have different backgrounds and preferences, between two or three people, you should have several different takes on problems and solutions.

Answer 4

As a programmer with a decent amount of experience, how can one combat this tendency to always approach problem solving from "tried and true" paths from past experience?

Refactor regularly. Refactoring requires that we scrutinize code we wrote in the past. We can use this time to view old code with a fresh perspective. So long as you keep up with major technology changes, one can make updates as you deem necessary.

If I have client work where I am under a time crunch or pressing issues from the problem domain or business rules, I tend to just use what I know to try to achieve a solution.

Good. You are focusing on the client's needs rather than your own goals. Way to go.

This involves very ugly things like

document.getElementById

or using ASP.NET with template bound controls (DataList/Repeater) rather than figuring out how to rearchitect things with an ASP.NET MVC approach.

There is nothing wrong with Webforms. MVC is not meant to replace Webforms. This is not the time to learn a new technology either. Remember the triangle. Refactor when you have time. Also, see first statement.

One technique I've used in the past is to have personal projects which exist simply for exploring these new technologies but this is difficult to sustain. What other approaches could be recommended?

What is difficult to sustain? Hopefully you are not maintaining projects designed for you to learn from. If so, throw the sample projects away. There is nothing wrong with creating one off projects for learning purposes. This is a very good thing. See first statement.

Tried and true != Bad. The "Einstellung Effect" is taken a bit out of context here. The tests refer to people optimizing "opening a jar". People's methods of "opening a jar" are limited and don't enhance over time (excluding any Sci-Fi stuff). In software, the best way to "achieve task X" does change with time.

Answer 5

Something that helps think outside the box is having an actual practice for doing it. Edward De Bono has written many books about lateral thinking and related subjects.

But at any given decision point, what matters most is assessing and embracing risk. Waltzing with Bears by De Marco and Lister is one of the best books about the subject when applied to software development.

Extreme Programming and other agile methodologies propose that one should just go ahead and experiment with the new (spike) solutions as a matter of routine. I do experiments with different technologies during project startups, and that has saved me several times from falling for the hyped in favor of the true and tried, and sometimes to discover a new technological gem.

Answer 6

As a team, you can change the group by recognizing pattern-breaking awesomeness. I often use new people for this, cause they aren't broken into the normal way of doing things. This is somewhat a managerial answer - but even as an experienced engineer, I think you can realize that someone else's view may be less biased and so consider with with a ranking of at least as much weight as your own opinion (maybe even more).

Answer 7

Are you sure that it isn't just that what you would put instead of document.getElementById is truly a waste of time no matter how accommodated you are to it?

Edit: I just realized, both of your examples are about tools, this could be because you consider changing you tools to be the biggest milestone of your skill development. A good coder need little more than a Turing complete language to work his wonders, that is not to say tools ain't important, but what you are using already isn't exactly a rock bottom toolset. If moving from one tool to another is the biggest progress you can think of then it might be that you have basically stalled in the less quantifiable areas.

Answer 8

As a programmer with a decent amount of experience, how can one combat this tendency to always approach problem solving from "tried and true" paths from past experience?

Self-awareness

Be aware of your tendencies, your weaknesses and your strengths.

Conscious Decisions

Make your decisions explicit and conscious. Do not jump to do something without consciously thinking about how you will do it.

Learn and Apply

Continue to learn new techniques and consider where they can be applied. When you run into a situation where it can be applied, do a cost-benefit analysis. Sometimes the benefit for trying something new outweighs the benefit of a known solution.