How to handle a "stupid user"

Question

I write scripts to take files via a web app in many different formats and transform them into a common standard. Not the greatest job, but I'm pretty fresh out of college. Recently my large company got a new employee in the team I write scripts for. Everything he touches he breaks. I expect data in one way, he'll open the files up and change stuff around. I send him instructions on how to repair a problematic file, he ignores the email and drops the file 4 more times. I create some defense to one problem and he comes up with some new, stupider way to break something. I don't know what to do, and I'm out of ideas for walls to code. I've tried educating him, I've tried explaining why something is breaking, I've tried giving short recipe style orders to fix things.

I'm scared to just solve every problem for him, because I'm afraid he'll start creating more problems than he was before and assume I'll fix it. I grew up with the idea of the anti-social computer person, and I've attempted to break that mold by being friendly and open with him - I'm starting to think thats a bad idea.

So tell me SO - how can I get this guy to shape up?

Answer 1

Have you talked to your manager about this user?

Answer 2

• Keep a kind of paper trail of your problems, how you tried to help and how much time you spent on it.

• Talk with a manager/supervisor. It might be that it is your "new" job description to hand-hold everyone through data-entry or it might turn out that the other guy isn't really fit for his job.

Answer 3

You're his peer, not his manager. It's not your job, and you can't. Best you can do is what you've done, treat him with respect and expect him to do his job in a semi-competent manner. When your manager asks about problems you're having, be honest and objective, not mean and spiteful.

One thing about the professional world is a simple pair of axioms:

A) It seems like nobody notices.

B) People are noticing.

If this colleague is a recent hire, he's likely also on a probational period of sorts. He's probably being watched pretty closely.

Answer 4

Add some code in so that if a broken file is passed in, your program fails into a graceful error message and logs what the problem was as best as possible. Give a hint on the error message screen as to what the problem is (e.g. file format is incorrect). If he complains that he can't do something then ask him what error he got, and why he didn't try to fix the file to resubmit.

If he gets a bit touchy about it, then take it to a manager and point out it isn't your job to add support for unsupported file formats.

Answer 5

If he doesn't break something, what makes you think somebody else won't? While I agree that it's definitely annoying, view it as an opportunity to get some extra testing in. After all, there's plenty more dummies to come after him.

Answer 6

Clarify your time-allocation priorities with your manager.

It's probably not worth 50% of your time, for example, to babysit one highly problematic user.

Answer 7

This is what I understand: the problem guy is submitting files via the website and your scripts parse his files, right?

And his files don't conform to the standard that your scripts expected?

If so, why can't you just reject the file and send an error message / email / notification back to the problem user saying that the file couldn't be processed.

I guess I don't expect MS Word to automagically fix my .doc file if it is corrupted, but it sounds like that is what is expected of you.

Answer 8

I'd argue that this guy is one of the best testers you've currently got! I would take a look at the way he's using your scripts and the webapp to improve your work.

I say this as a relatively new developer myself (I've been out of University for a little over a year), so I hope you don't take offence. If you have to keep explaining why something is broken, it's quite possibly the case that it is broken, or, at the very least, it could be improved. Take a leaf out of Don't Make Me Think by Steve Krug and watch your users at work - it's a really eye-opening experience! This will give you the opportunity to improve the UI of your program/scripts, by improving the wording of the field labels, prompts, error messages, etc.

Equally, however, I know how frustrating it is dealing with people who just "don't get it". There are in these instances personnel routes that you can follow, by talking to your manager. Make sure you have specific examples at the ready and ensure you phrase it in terms of the company's time, and not your own. Don't ever make it sound personal, and definitely don't question this guy's competence/professionalism/intelligence, etc. Be very careful that you don't do this implicitly, too.

Hope that helps, and good luck!

Answer 9

Clarify with your boss what your job is and what is "good enough" - because there is some level at which your boss with consider your efforts to be sufficient.

Many of my users over the years have not been computer savvy and I've had to code for them, by design. Perhaps this is the case here too. It might just be your job to cover these cases and have a really robust system that does X when he gives you junk.

Clarify that with the boss.

You're going to come across plenty of 'stupid users' in your career. Some of them might show you how much of a 'lazy coder' you are - they've done that to me at times. No slight intended there. I've found that many of my best improvements were made in response to dealing with folks who simply don't play by the rules, who don't follow the happy path, and who consistently give me edge case data.

Again, check with the boss. This might not be your battle to fight.

Best of luck!

Answer 10

Horror of horrors, a user who makes mistakes and is human.

I'm pretty fresh out of college.

Now is the time to reframe your attitude, then.

First, he is not a stupid user. He is a user, and users do different things. Our job as programmers is to write code that does what they need. If this guy goes away, there'll be someone else who makes those mistakes.

Have you ever typed an incorrect command at the command line? The program handles it, doesn't it? The programmer who wrote that command didn't curse "Aw, geez, some moron can't remember all the command line switches, and now I have to allow for that error. They never learn!"

The reason that we as programmers make the big bucks to be computer experts is so other people who are not computer experts do not have to be experts.

Get in the habit right now of expecting bad data and having your code allow for it. Your entire programming career is about tolerating mistakes.

Most of all, vow right now to never describe your users as stupid again. Your future career will thank you.

Answer 11

Over time I've figured out that no matter what you make, people will use it in a way you don't expect/like.

One of the best defenses is "Fail early, fail hard"--be very specific about what caused the failure, but do not try to work around it.

Then remove ways in which people can effect your data. Make copies and never let them at your raw data. Give them a UI to access your data if they need to see raw data.

If they need to update your data, have them do so in a controlled fashion, either through a GUI or have them submit changes for your program to check and patch in.

All these things seem like extra work, but trust me--being defensive saves you MUCH more than it costs.

I even code like this--If I have to go to meta-programming for something (where compile-time checks don't work), I'm VERY clear and specific about my runtime errors, and I usually fail HARD (like shutting down the system leaving nothing but a giant, clear, specific message on the screen). At this point about 50-70% of my code is error checking. Again, totally worth it--otherwise they won't notice it.

Answer 12

It seems like what might be useful is to create a tool that is used at the client-side to simplify data entry / data generation, so that the output of that program is compatible with the expected input format of your website. The tool can provide validations and on-screen hints (for example), to minimize errors.

BTW, I agree with others -- resist the urge to think of him as a stupid user. Even if it's true. That way of thinking will ultimately contaminate your outside demeanor, and will be deterimental to your future.

BTW, there's a certain WTF going on with the business process -- if the business relies on data reporting created by users, and the users are allowed to arbitrarily generate bad data, what's to stop him from reordering data which is perfectly parseable, but puts data in the wrong fields?

Answer 13

In my opinion, you need to nail down what the operational parameters of your program and job are, and route all change requests through your boss.