17

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?

David in Dakota
  • 839

8 Answers8

9

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.

Ethel Evans
  • 5,319
  • 2
    if you have the time for it, increase the 20%. I'm not even that experienced, but I already figured this: doing it right always pays off in the end. Also, the more knowlegde you have about doing it right, the faster you will get it done right and eventually (well, that's what I hope ;P) the two will merge together and you'll be able to do pretty much everything right AND fast. – stijn Mar 29 '11 at 20:22
  • btw what happens to me more often than not: start something, knowing that it's not completely right, then 2 days later lose insane amounts of time because the thing that I knew was wrong in the first place now needs refactoring to make it right, after all. – stijn Mar 29 '11 at 20:25
  • 1
    Or 50% when work is on a low, or even more between projects. Nothing I have ever studied has has been wasted. It has all been used sooner than later, even if only to have an informed opinion when it matters. – Apalala Mar 29 '11 at 20:59
5

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.

apoorv020
  • 656
  • Keeping your self busy with work frequently means keeping yourself as productive as the guy who learned the next "best" technology. I'm about to count three decades on the trade, and most of what I remember of it all is study, study, and more study. – Apalala Mar 29 '11 at 20:57
  • +1 for programming (at least professional programming) being about writing code that gets the job done rather than theoretically perfect code that's a work of art. – jwenting Mar 31 '11 at 06:10
4

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.
Community
  • 1
Nicole
  • 28,181
3

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.

Community
  • 1
P.Brian.Mackey
  • 11,103
2

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.

Apalala
  • 2,283
1

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.

aaaaaaaaaaaa
  • 1,066
  • 1
    I'm not sure what you mean; I was referring to using jQuery selectors as a better approach. Using the straight DOM works fine, but jQuery is a much better approach. So to be clear, both work, one is simply better than the other. – David in Dakota Mar 29 '11 at 20:25
  • 1
    Well, $("#id") is shorter, but ultimately just an alias for document.getElementById("id") with some overhead on top. Do you know that it will improve your workflow? Or have you just been told that jQuery is better so many times that you believe it? – aaaaaaaaaaaa Mar 29 '11 at 20:38
  • 1
    @eBusiness - Do you know that $("#id") is ultimately just an alias for document.getElementById("id")? Or have you just been told that so many times that you believe it? I hope that every time you use getElementById you remember to handle the case where IE and Opera return elements by name instead as well as the case when Blackberry 4.6 returns nodes that are no longer in the document. – Nick Knowlson Mar 29 '11 at 20:57
  • If you are using the same identifier for name and id of different objects or your code can't 'remember' what objects it have deleted then using jQuery is practical. Otherwise it is nothing but bloat that drags the speed of your code down. I'm not saying that what jQuery does is wrong, but it is not better for every purpose. – aaaaaaaaaaaa Mar 29 '11 at 22:06
  • @eBusiness - here's something fun: if you have a select element with options, you can use: $("myselect").val() to return the selected item. Fairly obvious that more is happening than just aliasing. There are many features like this to jQuery that make it more robust than straight DOM not even taking into account what @Nick Knowlson refers to with browser compatibility. And we're not even in the territory of $.ajax - – David in Dakota Mar 29 '11 at 22:41
  • 1
    I know that I sparked this, but I think we are moving a bit too far into a jQuery versus JavaScript flamewar. – aaaaaaaaaaaa Mar 29 '11 at 23:02
1

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).

bethlakshmi
  • 7,625
1

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.

snakehiss
  • 8,697