Well I’ll share a few opening sentences that tend to make my heart sink a bit as a programmer. I’m an independent software author so I don’t have any problems with others telling me what to do, but often get requests from users. I’ve found ways to work with this over the years, so it’s much easier now than it was. But I used to get many frustrating questions, and still do sometimes.

1. It’s not working - and then when you ask for details they don’t answer and expect you to solve it without knowing what the problem is. Still get this sometimes. Usually I manage to get details eventually but it can take quite a few messages back and forth. It’s understandable but frustrating at times.
2. It’s working now - sometimes good news, but not if you haven’t fixed the bug yet. Users have a different perspective from the developer. As a developer, if you can’t reproduce the bug yourself, you are dependent on them to reproduce it. So - especially if you’ve spent maybe several hours or days trying to fix a bug, and have nearly got there - narrowed it down to a few lines of code perhaps - then suddenly the user says ”it’s working now” and no longer is interested in reporting back and helping you go through the last few steps to find out what really caused it and fix it - it can be quite frustrating. You just have to wait for someone else to report it to continue the debugging. That happens much less often now because I’ve got much better automatic reporting from the program, so long as they send me the necessary data on request.
3. I know how you can fix this bug - when users say that they almost invariably are wrong. They haven’t written the code, and I wouldn’t be able to say that to another programmer even, if I didn’t have the code. Sometimes you can see how to fix a bug right away. But if not, it’s often a bit like trying to solve a mystery in a detective story - it’s almost never the culprit you thought it was. If you can’t see it as programmer right away it is very rare for the user to see it somehow.
   
   Unless of course it is something unusual about their machine e.g. “I’m using a third party shell for all the windows” - that was the answer to one rather strange user interface bug - the menus were buggy, they couldn’t see some items - because they had a non standard third party shell that was displaying the menus in a slightly different way, (I forget the details now). It took several messages back and forth before we figured out that it might be due to their UI shell - it’s the sort of thing people tend to install and forget.
   
   That sort of thing is very useful to know as of course you can’t know that without being told. I found a work around for them in that example. I installed their preferred UI shell on my computer, duplicated the bug, and then played around until I found a solution - I added some extra spaces into the menu item names which had no impact on other uses but fixed their issue - it was a workaround for a bug in their UI shell basically.
4. I’ve got this great idea for your program - sometimes it is a good idea but often it’s something like e.g. - a text editor that plays a different note for each letter typed (okay made that one up) - Now that I have a wish list, this is no longer a “sinking feeling” type email or message. Instead it is quite fun now, I just add it to the wish list and they are satisfied by that also, and from time to time I implement some of the ideas. Bounce Metronome Pro Wish List And the user never has a clue about whether there idea will be easy to implement - sometimes astonish them by doing it in a few hours - or next to impossible - something that seems dead easy to do for a user may be a one or three year project for a team of a dozen developers, as in this xkcd cartoon.
   xkcd: Tasks

1. This idea is so great it’s going to earn both of us a fortune: I get this from time to time, maybe once every few years, not that often, but when it does happen they are often very sure of themselves and persistent about it. “I know lots of people will like it, and it’s incredibly important to do it, please do it and give me 50% of the royalties.” - nowadays I have a clear statement on my website that I never make royalty agreements in exchange for ideas and send them to read that. It’s at the bottom of this page: Standard Disclaimer
   “I WILL NOT ENTER INTO ANY ARRANGEMENT INVOLVING PERCENTAGES OF SALES OR FUTURE RECOMPENSE IN RETURN FOR SUGGESTIONS, BUG REPORTS, ALTERNATIVE GRAPHICAL USER INTERFACES, OR ANY OTHER PROPOSALS FOR MODIFICATIONS OF MY PROGRAMS.”
   
   If they say it is secret and I have to agree to share royalties before they tell me, I just say, please don’t send it to me. If they are still keen for me to do it, I then add it to the wish list, or program it if it is easy to do. The reality is that if something is an outstanding business idea for a software program, then nearly always someone has done it already, probably dozens of developers done different versions of it.
   
   If not done already, then it’s a reasonable guess that it is perhaps of great interest to a small group of people, but they are greatly overestimating how much it would earn. If say 0.01% of the population are interested in it, that may mean there are tens of thousands of potential buyers. But advertising to reach them would probably cost much more than you’d earn. And the chances are that most will want it for free. The reality of the situation is that there are very few programs with millions or thousands of sales, rather more that make a few sales per week, and the majority of programs by independent developers will only make a few sales a year or ever. It’s best to do a program that you want for yourself, or have friends who want it and just do it because you think it is fun and interesting and useful, and then if you earn anything from it, that’s a bonus.
2. “Oh, that’s not what I wanted” - after working on it for weeks or months. This used to be very frustrating - though some of the ideas I programmed in this way were useful for other users though not for the person who originally asked for them. The problem is that users don’t really have a good insight into how the UI will work, so they may say that they think you need to do x, y, z in great detail but when they see it they realize it is not what they want at all.
   
   The main issue here is that it is natural to interpret what they say as if they were programmers talking to you about your program. It’s important not to deal with user requests as if they were program specifications, but instead ask them to explain why they want these features and try to learn what it is they are trying to do. Often you find the program does it already, just that the help was a bit confusing, or that the obvious way of doing things is buggy, so you have to fix that bug and they are trying to get you to program a work around for a bug they haven’t thought to report, etc.
   
   Nowadays I deal with that by going over it more clearly, like that. Also once the idea is clear, or as clear as I can, I get a rough version for them to see at an early stage, instead of implementing the whole thing, just some part of what they want. Then if it is still interesting, if they say “Great that’s just what I wanted” etc then I take it further. If not, haven’t spent too much time chasing that particular red herring.
3. Please make this program more user friendly - that’s reasonable enough as is, but then you go on to say “Okay, do you mind testing it for me and giving some feedback” and they say “no, why do you need to test it? Just make it work better”. If I was the likes of Microsoft I could have teams of users to test everything. But an independent software author can’t do that, you test it yourself, get a few friends to test perhaps - but if that is not enough you are dependent on your users to give some feedback. If they can’t answer questions or don’t want to, you just have to give up on it, and wait until someone comes along who will explain what the issue is for them.
   
   And if it is something very specialized, the only people who can test it are the ones who would be using it. At least in detail. You can go a certain way towards this goal by following user interface guidelines, relying on past experience etc. But after doing that if they still say “make the program more user friendly” - where do you go next when you’ve already done everything you know how to do? You need feedback from the users of the software otherwise it is just randomly changing things in hope that it will help, which is as likely to make it worse as better, and also to annoy previous users of your program who are used to the way it is now.
   
   I deal with that by explaining the situation somewhat better than I used to. It’s a tricky one though, as you need to be a programmer I think to understand quite how complex UI programming is. The modern friendly UI - e.g . the editing UI for quora as an example - it seems so simple but is a result of thousands, or more likely millions of carefully thought out ideas, many sketches, programming, user interface testing, this UI - which I think is very good as a user - it must involve so much by way of thought and testing and experience… And to most people all that is totally invisible except when it goes wrong.

My two innovations that make a huge difference are, first to have an online wish list. which you can read here. Bounce Metronome Pro Wish List

So since I created that, I’ve had much less by way of problems. If someone asks me to do something that involves several years of work, for instance, I write it up and put it on my wish list, and say there whether it is possible or not, and a rough estimate of how long it might take as in whether it is years of work, months of work or days of work.

And from time to time I get a chance to do some of the wishes, sometimes several of them in one go, as they are often related.

The other thing that helps is my Standard Disclaimer