hi wil!

I've had pretty same experiences as you had last year, so I think I know what you feel like. It's always hard to speak about coding to people that don't have a clue what amount of time the "program" they wish will take. I also found out that it's VERY important to discuss out if the things people want really are important or just nice-to-have. I even had experiences where people wanted stuff kinda because they were bored or something but then didn't really use it.

Currently I work in a room which is full of people who know what coding is about, even if I'm the only person here who codes perl, the others do PL/SQL mostly. But the point is that they know what it is all about and that saves you a lot of time. Also my boss has quite a few years of coding-experience so there usually aren't long discussions needed to find out how long it will take to do the job etc.
If you have only people arround you who do word-processing mostly and that's it, it often takes more time to find out what they really want than the time you need for coding itself. You start to discuss, then their mind changes after you told them what is necessary etc and so on...
I think it's always good to request a clear concept of what people want, what they want it for and how important it is. There are everywhere lots of things that could be made easier by coding a script and automating stuff that has beed done by hand until now...so you will get lots of requests pretty soon, once people know "that guy can do that!", so you have to set clear priorities.
But as I said my boss knows about coding so I didn't have to argue in any way, because if there is a problem I tell my boss and don't have to argue with people usually :)

What I don't like is when someone "important" in a high position wants something and then it has to be done, doesn't matter what kind of time it takes and if there are other important things but I guess that's pretty usual....

greetings,
giant