It always gives me a pause, and then I would double the schedule.
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.
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.
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.
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.
Yeah, couple of months - me, every time.