[xTorvos]

My client/coworker just sent me this (identifying information removed):

"Guy1 and Guy2 want me to do task X for Guy1. Chick1 is adamant about me NOT providing this service since it is supposed to be handled by the RandomAssociation members. Guy2 is the Operating RandomAssociation member.

I sent Guy1 my worksheet with tips and guidelines for doing task X but he says that it is too difficult to do.

But Guy2 sent me a (information), said find someone to do it and charge him.

Now I am desperately asking if one of you (lowly servants) could do task X for Guy1 even though I know it is not your job either. What do you think?"

(Attached is worksheet of tips and guidelines [a simple checklist of things required to do task X])

I develop the application that they are using, but it is not my job to help users get accustomed to it or use it for them.

What would you guys do in this situation?

Edit: Spelling

This post has been edited by xTorvos: 13 July 2010 - 09:26 AM

[tlhIn`toq]

Quote

I develop the application that they are using, but it is not my job to help users get accustomed to it or use it for them.

If 20 other employees are having trouble using your application, then it is your job to fix the application so it makes sense and is intuitive and easy to use.

If 200 employees have no problem, and just 1 guy is too lazy to read the book, or too dumb to understand it... Ask your supervisor where to prioritize the task. You don't refuse it. But you bring it to the attention of the supervisor without narcing on the idiot or refusing it. Just ask in the most friendly cooperative tone: "Where do I prioritize this task? Is the quick-start training guide higher priority than the new database, above the new sales software, above the new security program, blah blah blah"

This makes you happy to help out... and the supervisor will either prioritize it below cleaning the breakroom fridge... or say "Don't worry about it, I'll make this go away (along with the idiot)."

I also find that informing supervisors that writing the new documentation or program will shift the completion deadlines of projects by 2 weeks gets a lot of response. Again, you aren't refusing the task. You present yourself as happy and co-operative. But are letting them know the reality that the 40-80 hours to complete their request has a consequence of moving other project completion dates. That tends to get the attention of higher ups who insist on following the release roadmap and won't sacrifice release dates for one guy with an I.Q. lower than his neck size.

This post has been edited by tlhIn'toq: 13 July 2010 - 09:44 AM

[Choscura]

Joel on Software had a good article on this with an excellent piece of advice: make sure every part of your application passes the 'hallway test'. this means you grab the first person you see in the hallway, bring them in, and for 20 seconds, you watch them try to do something in your application. If they can't do it, ask them why. you'll get better feedback faster and at a more relevant time this way than any other way.

Other than this, if the app regularly passes the hallway test, you need to tell them to stop getting stoned in the mens room get an extra cup of joe and figure out how to do this.

[SpeedisaVirus]

Of course for that test to work you have to assume most people in your hallway are about as retarded as the average user.

[calvinthedestroyer]

SpeedisaVirus, on 15 July 2010 - 05:44 PM, said:

Of course for that test to work you have to assume most people in your hallway are about as retarded as the average user.

Yeah, there are some really high end Physicists, programmers and chemists where I work. Not to mention the head supervisor uses my lab as a short cut to get from one end on the building to the other.

[moopet]

xTorvos, on 13 July 2010 - 03:25 PM, said:

Chick1 is adamant about me NOT providing this service since it is supposed to be handled by the RandomAssociation members.

Is she hot?

[baavgai]

SpeedisaVirus, on 15 July 2010 - 07:44 PM, said:

Of course for that test to work you have to assume most people in your hallway are about as retarded as the average user.

I can't imagine this being an issue. Unless they're computer people, even a brain surgeon turns into a drooler when faced with you average business app.

When we write programs, we try our best to idiot proof them. The problem is that there are some exceptional idiots. The trick is determining if this is a general idiot problem or if someone is raising the bar.

[Valek]

baavgai, on 17 July 2010 - 06:56 AM, said:

When we write programs, we try our best to idiot proof them. The problem is that there are some exceptional idiots.

"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning." --Rich Cook

[SixOfEleven]

Valek, on 17 July 2010 - 10:16 AM, said:

baavgai, on 17 July 2010 - 06:56 AM, said:

When we write programs, we try our best to idiot proof them. The problem is that there are some exceptional idiots.

"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning." --Rich Cook

There is also the problem what we have to rely on third party components that may not have been idiot proofed. Martyr2 had a post on his blog here about that. It is an unfortunate fact of life that even if we write perfect code, we have to rely on the fact that others have also written perfect code. And Rich Cook was definitely right, the universe is winning here.

[Valek]

Indeed, I agree completely. There really is no way to guarantee perfect code against idiots. Someone will always find a way to make it work differently than intended. Of course, the better your code is, the more likely they do something that throws an error you never expected to see, and then they're so retarded about it, they don't even know what they did to repeat it for you so you can patch it

[NickDMax]

Quote

Of course, the better your code is, the more likely they do something that throws an error you never expected to see

I have always felt that the better your code is, the more "features" your users will discover to help them solve their problems...

I used to analyze office practices to see how software could improve their lives and one of the things that really amazed me is the ingenious work-arounds that secretaries will discover for doing a function the software was actually design to do. One of my favorites was printing out a Word-document to scan it to to a pdf to email it... this is especially important because email is a very important step in all kinds of horrible ad hoc workflows -- most of these workflows actually simulate a functionality already in the software.

[Valek]

I wonder how they would have reacted if you had shown them they didn't have to go through all that run-around they were putting themselves through.

Probably something along the lines of "but it's much easier this way!"

[NickDMax]

The results very... some are floored and so very pleased that I found them a way of saving time.

Others are VERY defensive of their way and begin to challenge me with all kinds of "what if" scenarios in an attempt to prove that their way is better.

Generally though I have learned to try to work with them not against them. For example you show them that they can save a copy of the document as a pdf and that might save them a step (if the document does not need a signature). You might then show them that they can also fax directly from Word (again if there is no need for a signature). i.e. You ease them into it, if you sit down and say, well you don't need to do any of that you can just do this... prepare to spend the rest of the day answering complicated questions that you don't really understand.

[Valek]

Sounds accurate to my experience as well. Usually if someone tries to "go for the throat" defending their way, I let them keep it. If they're that adamant about doing it the hard way, it'd be a waste of my time to try to turn them away from it.

[NickDMax]

I actually loved working with secretaries/office managers -- they all seem to think in very concrete terms. They know everyone's names and use them in describing scenarios. Whats funny though is that after a while you begin to recognize the differences between how names are formed for different position. Customers are almost always first/last names, male supervisors are Mr. whoever, female supervisors are full first or possible full first/last names, etc.


Oddly enough I kind of miss writing MS-Office customizations... I mean I make a lot more money now, but that was a really fun job and I got to work with nice people who all seemed to think I was a super-genius.