Favorite Technology Trap

Many programmers have a favorite language — usually the one they know best. To me, it’s a fault if the developer sees the language as a hammer and every problem a nail. If hiring a plumber I’d ask, “What is your favorite tool?” The winning answer would be, “Whichever tool suits best suits the problem in front of me.” Experience with a technology should have no bearing on a technical solution, but it often does.

One likable thing about interviewing is meeting others passionate about technology. Recently, after my last company closed, I interviewed. Small, early-stage startups seem to be the most chaotic in technology choices. At early stages, it’s a small group of developers with only one goal: prove the idea works. When I see a baffling choice, like a high-level scripting language, doing CPU-intensive tasks, I ask, “Why?” The more defensive the answer, the more frightened I gets.

Favorite technologies create selective vision for the afflicted. Problems in other technologies are immediately obvious while the favored tool remains The Chosen Answer. Everyone who disagrees is a heretic. Additionally, when you have a favorite technology, and that technology hits its limit, it is somehow acceptable to change the problem.

“Why did you use Java to stream multi-gigabyte files to create SHA-1 hashes?”

“Java has excellent support for databases and creating hash keys.”

“The SHA-1 key generation could not keep up with the stream, missed bytes, and produced the wrong hash key.”

“You’re right – we need to figure out another way to create the hash keys.”

That’s the problem with a favorite tool, you rationalize your way into using it, even when it’s not appropriate. Why would smart people do this?

Their favorite technology is where many invest significant time. Most people want to be in, not out, of their comfort zone. Sticking with a well-known tool is a way to stay comfortable. This is a huge issue with change management. Getting people to learn new skills often meets huge resistance as they fear devaluation while they come up to speed with the new technology.

A way to avoid this trap is to hire engineers who like what they can do with technologies more than any one technology. Ask open-ended questions in interviews, e.g. what languages or platforms they like or don’t like or what kinds of problems they like to solve. Don’t lead the candidate or broadcast your intent, just listen. If you take some time to get to know the candidate rather than asking obscure technology quiz questions, you may be able to figure out if they are already in the favorite technology trap.

Share

Tags: ,

Comments are closed.