Rajani’s weblog

Have you ever worked with someone who was just-technical-enough-to-be-dangerous?

As in, maybe they used to write a little code back in the day, but are now woefully out of touch with what it’s like to dig deep and build software right now.

Somehow that doesn’t stop them from sticking their noses into the technical side of the shop and thinking they know better than the real programmers.

Sometimes these people are simply just-technical-enough-to-be-annoying, but they become more dangerous the more control they have over the technical aspects of the project. I’ve definitely seen programmers, even more senior ones, give in to ridiculous demands made by these people just to appease them.  Often they’re actually the boss which makes it really hard to fight.

Someone who is just-technical-enough-to-be-dangerous…

• often declares that tasks are going to be easy
• debates developer estimates, usually to make them smaller
• tells other people that something is not possibly in the system, because he wouldn’t know how to do it
• “architects” technical solutions that don’t make any sense in the actual context
• tries to “solve” bugs by dissecting the bug reports or error messages
• wants to pair with you on solving bugs (ie. hover distractingly) to “help”

Handling these people is a painful part of being a developer, but here are a few tips and tricks to help you along:

Show them how to help you

Sometimes this person truly means well, and thinks that they are helping the situation with some of their antics.  Pointing out that they are spreading misinformation or slowing you down may work for someone who is humble, but will likely upset and frustrate most people.  Instead, direct them to how you would like them to help.

If they keep trying to solve your bug reports (ie. “I think it’s breaking in the validation, because X, Y and Z”) you might suggest a bug report format.  “You know, I could solve bugs faster if I got bug reports in this format.  Do you think you could help me out?”

Be noncommittal

When someone tells you that something is easy or tries to tell you what is possible or isn’t possible, try not to have that fight right there.  The real answer is “I’m right because I actually know the code and you have no idea what you’re talking about” but that’s unlikely to go over well.

Instead, say something noncommittal like “Maybe, since they would prefer it with feature X, let me go check if it’s possible and get back to you.” then once you’ve “checked” it will be harder for him to argue.  Or, say “You know, I think I recently found a way to do that.  I’ll give it a try and if it doesn’t work out we can reevaluate.”

Give them busy work

Sometimes people just want to constantly meet and discuss and analyze a bug, instead of getting down to actually fixing it.  In those cases it can be helpful to give them busywork.

“You know, I wonder how it reacts to this type of data.  If you do have some time to spend on this, do you think you could check on that while I look at the code?”  If they have time to kill, they may go off and do it.  Although in my experience, this is often when someone will jolt.  Whew.

Let them prioritize

So long as they can label something “easy”, people tend to throw tons of things at you that aren’t necessarily a priority.  And then you’re still supposed to get the high priority things done.

When people approach you to do something that will “just take a minute”, show them the priority list you’re working off of.  Make sure that it truly does rank as higher than anything else.  Most of the time, it won’t, and so you just insert it where it belongs.  If it really does, then you can do it next, but now they know that everything else is getting moved down because of it.

Ignore fake emergencies

As a general rule, avoid stopping what you’re doing to do something else.  Sometimes that may be necessary; if the company is losing millions of dollars by the second on some ecommerce bug, for example.  But often it’s a waste of time doing a context switch.

When asked to do something, volunteer to take care of it “this afternoon” or “by tomorrow” or whenever.  When asked to do something right now, unless you’re doing something truly wasteful, always let them know that you’re working on something important, but you can be free at X time. Even if you end up doing it, at least you have pointed out that they are interrupting you.  Of course, make the exception if you know it’s truly important, or if the request comes from someone who isn’t wasteful.

Be transparent

Many programmers hate transparencies, and prefer to have their time in this large, mysterious black hole.  Unfortunately, this exacerbates these types of issues.

If someone is having you spend too much time on overhead activities, track them for a couple of weeks (along with other things you d0).  Then in a planning meeting where you’re discussing how to meet the looming deadlines and be more efficient, point out how much time you’re spending (in hours or as a percentage) and helpfully suggest that reducing them will help the project move forward faster.

——————————————————–

By the by, Code Anthem is launching into beta soon.  Sign up for the beta now if you want an early pass when we do.