The term "anti-experienced" refers to people who have been doing things wrong for so long that it is actually worse to have them on your team than it is to have inexperienced people. Some people learn from their mistakes, but others just don't recognize that they've made mistakes, and actually feel that bad practices are good practices. They stubbornly hold on to the techniques that they think work for them, despite all advice and evidence to the contrary. PracticeMakesPermanent.
This reminds me a lot of UnconsciousIncompetence - hw
Is there a good way to deal with anti-experienced people, other than getting rid of them? Such people may have some valuable experience in addition to their anti-experience, and it would be good to take advantage of the positive if possible.
If you can't get rid of an anti-experienced person, what are the best ways to minimize the damage they cause?
How does one detect an anti-experienced person during an interview?
The same way you detect a neophyte. Don't ask the typical but worthless questions, "do you know this?" or "have you used that?" Make him demonstrate what he knows or how he works; make him solve problems.
Experience is a slippery thing in general. Experience cannot be measured in units of time. Related to this AntiExperience notion is the person who has experienced the same year 18 times. Some people do more in 4 years than others do in 12.
On the other hand, maturity might have a greater tendency to be correlated with time, and that counts for something.
But never forget about aptitude or talent. Here's my theorem:
I see this happening a lot when people change contexts (let's say, from IBMs BigIron to Microcomputing) and believe their way is the RightWay?.
I know about the real of a small investment bank that bought a large brewery company. In this investment bank all they used, with big success, was Excel and microcomputer. So, they believed that this was the right way of doing things (here we have our AntiExperience). They scrapped the information systems of the brewery for the ''new and revolutionary ways of bank X" and, after a short lapse, the company started to have big problems with lack of information. As the result, they had to build a client-server system from scratch.
We have direct experience with working with an intelligent programmer who, having learned to program using C, tried to make Java behave in a C-like manner, despite being presented with the language designer's (not our) reasons for leaving those things out of Java. For example, this programmer attempted to revive multiple-inheritance through the brute-force use of interfaces.
From my experience, I have successfully dealt with these and NetNegativeProducingProgrammer by expanding the scope of my project or area or mostly or fully encompass theirs, limiting them to a small yet time-consuming role (like documentation or specification). Alternatively, dream up a new less-critical yet slightly useful featurette for them to work on that you can tack onto your project. This will minimize their damage.
When I read the term, I tought of something totally different, I thought of those people who say "You can't learn this from book, only from experience", said in the right situation, this sentence can be 100% right, but in many cases it just reflect the person inability or unwillingess or laziness to learn new stuff, which is a must in computers.
I remmember a quote for Larry Wall describing perl as an emperical science, you have to try it to know how it works, which at first sounds nice, but thinking about it, it just means the language is complicated and not documented well enough (because it is complicated)
You should not learn programming from experience, if you haven't READ books about programming and every aspect of it, you are missing a lot, experience, teach you the discipline not the craft, two things I like to denote separately
See also NetNegativeProducingProgrammer, BadProgrammer, LearnFromExperience, MetaWisdom, CargoCultProgramming, UnconsciousIncompetence