To generalize what Colin wrote -- this is a method I learned doing business in Japan. You can never, ever say no to anything; the other person would lose too much face. However, saying, "Yes, and..." and then pointing out possible issues that would arise (like Colin's 3rd paragraph) can often cause the decision maker to change the original request, or even decide it was a bad idea on their own.

Of course, sometimes, you end up doing the work anyway, but the 'disclaimer' in your "Yes, and..." give you a position in which to work where your boss implicitly buys into those limitations -- this is also a better thing.

"Yes, and... {limitations}" instead of a no is always a better answer to a superior. Most of mine have seen the light after discussions like this when something was a bad fit or bad idea.

On the other hand, sometimes I ended up having to do the undesirable. Take pride in what you do, no matter how undesirable, and you will find yourself building excitement for your work. You may discover you learn some cool stuff along the way, too.

Best of luck!

> A point for concern is your response that you're a Java developer with no interest in a different language.

It's not that I'm not interested in a different language (besides Java I use other languages, too), it's just that I was not interested in Perl.

I agree with you about the value of learning new languages, but I think you are more successful in learning a new language when you learn it because you want to learn it, and not, because you must learn it. Intrinsic vs. extrinsic motivation.

I'm more successful in pretty much any task when I have no deadline, five highly competent assistants and a private masseur for whenever I'm feeling stressed. But if I was only willing to work that way, I'd be living on the street. Being a professional means getting the job done even in suboptimal conditions.

Yes, that's true, though I think being a professional also includes the option of saying "no" (on how you say it, that's another question).

No, you can only say "no" if you're a self-employed professional like a doctor or lawyer or consultant with his own practice. Then you have the choice of whether to take on a potential client or not. However, a professional who works for someone else has to take on their employer's priorities. That's the deal you sign up for when you become an employee; that's what you give up for a regular monthly paycheck.

If you're very valuable to your employer, you might be able to get away with saying "no". But most people are not indispensable, and if you say "no" too many times, your employer will start looking for ways to replace you.

Those are valid reasons. I coded a fair amount of Perl a decade or so ago, and I wouldn't be wild about having to do more of it, never mind learn it nowadays. But it doesn't sound like you were approaching the conversation constructively.

Why is it so important to your boss that the project be done in Perl? You need to understand this so you can see if there are other avenues you can pursue that will make him equally satisfied. For example, using Ruby or Python.

And why is it so important to him that you do the project in Perl? As you said, you don't even know Perl. Why isn't the project going to someone who does know it?

If you're lucky, there will be some alternate win-win path to helping your boss accomplish the goals he wants accomplished without getting stuck doing work you really don't want to do. Or you may have to sign up to do a certain amount of scutwork, but get your boss to agree that once you're through the current crisis, you can move on to a path that you will find more rewarding. If a good boss understands your career goals, he will work to find a way to help you work toward them. And the better you are at helping your boss solve the problems he faces, the more likely you are to discover that you have a good boss.

Of course, it's also possible that the reason you're being assigned this task is something to the affect that there's a lot of other Perl in the company, and the company wants to crosstrain people in Perl. Perl is just part of the deal there.. In this scenario, not learning Perl is effectively declining to develop essential job skills, and your only realistic option may be to suck it up until you can go find a better job. Just be glad it isn't COBOL! (Sorry, gallows humor there.)

> Why is it so important to your boss that the project be done in Perl?

It was an existing project developed by the client, and they used Perl. So the technology was fixed.

> And why is it so important to him that you do the project in Perl?

That wasn't important, I was just the guy with some free capacity.

> As you said, you don't even know Perl. Why isn't the project going to someone who does know it?

There was none who knew it (at least as far as I know), the company was a Java shop.