The one that drives me up the wall is the schedule/cost anchoring question, "this should be easy to do, right?" every time they asking for a new feature. It's set to manipulate you to lower the schedule or the cost. If you say it's not easy, they would question your competency. If you say it's easy, they would say, well then you can get it done this week.
It always gives me a pause, and then I would double the schedule.
On the other hand, programmers are very good at wasting weeks creating incredible software architectures to try the latest library they read about or try a design pattern, or in general over engineer something so that it’s “better designed”, more generic, more “flexible”, and so on.
In other words, if a project manager sets an expectation that a task is a “task that takes two weeks”, the developer will somehow manage to use about two weeks to make it, that is find the “best way” to do it given that timeframe, where “best” is probably evaluated under some kind of metric which has nothing to do with product or user value.
Sometimes the question “explain me why it should take more than two days, when i know it takes two days to do just that in the context of a minimal MVP” goes a long way in making programmers focusing on delivering the maximum value for the product.
So I think there is actually some value in having a technical person continuously challenging developers in shortening their path to implement a feature.
Programmers actually hate working on the same thing for longer than necessary. They like new problems and new challenges, as your identifying in your misguided take on always wanting new libs/frameworks. If you are finding that you actually believe this, you've somehow cultivated a very toxic technology environment where your developers are hiding necessary tasks from you and attempting to make up the difference wherever they can. You have probably browbeat them and cowed them from speaking about their ideas in the past.
I've been getting paid to write code since 1998. The last few years in management. So I know something about actually being a programmer.
I hired someone who was awesome from a technical knowledge perspective. Friendly, personable, smart, driven, etc. Loved talking tech with him and he had really great ideas.
Anyway, the problem was, I'm running a startup and every single project he was on he tried to model it as "the perfect open source project". So instead of doing something simple in a couple of days he would build this really well abstracted, over engineered (but pretty damn good code!), "beautiful" thing that would take 3 or 4 weeks to deliver.
In the end, it didn't work out for him.
Anyway, my point is that it is not true that programmers hate working on the same thing for longer than necessary. I do. You do. Many others do. But some just love being architecture/purity astronauts and refining that 3 line method into a 7 class inheritance hierarchy.
This is a pretty common management strategy to stroke your ego and put you in a elevated position where you awkwardly feel the need to agree.
I do the opposite, I say well it's not entirely clear how much work this is going to take, I'll need to do some initial assessment to get a more accurate idea.
If they continue to pressure I ask them what changes they imagine need to be done since they're so assured of the scope and timeline of their request. I have not a care in the world of letting someone else be the "expert." If they are, I'm more than happy to go with their idea.
I've yet to get a response back outside of a collaboratige conversation with another developer working on the same codebase for similar efforts. This is usually where people realize just how much ignorance they have around their request and that they should leave it to the people more familiar with the work to make accurate assessments.
I'd always prefer the honest path. You could try to explain the problem and why it might seem easier than it is in simplified terms.
Also, fast and slow, hard and easy - those terms don't always correlate. Easy tasks can require a lot of time while hard problems might result in a quick solution after careful consideration. Furthermore getting hard tasks done quickly might be exactly why you're billing that much. Maybe you've dealt with a similar problem before - in that case your experience and competence in that particular subject shouldn't devalue your work.
What I'm trying to say is: Don't base your price on time spent alone.
It always gives me a pause, and then I would double the schedule.