I'm highly sceptical of managers that are focused on measuring metrics.
If the engineer can't convey why it took a week to find that one-line, they should work on their communication skills. A good manager can help set expectations for an engineer who has underdeveloped soft skills.
I just spent a week and a half tracking down a bizarre issue in a 3rd party library and filed a fix for it. It was simultaneously frustrating and fascinating, but I never once was worried that the team didn't support my effort because I kept the team in the loop during daily standups. I've also been lucky to have excellent managers who believe in letting the engineers work.
On the other hand, if somebody is constantly disappearing for a week+ with a low complexity ticket, gives cagey standup updates, and then submits a PR that looks like it was thrown together in an hour.. That's a red flag that needs attention.
What if you have an employee who doesn't know how to do software estimation? Do you know of ways to teach people how to do estimates or resources/habits they can follow to learn how to estimate how long tasks will take?
I ask this as someone who has only received the advice "go with your gut and triple it." There is a book by Steve McConnell on estimating larger projects but nothing out there on estimating things within a week.
If the problem is in fact known, your estimate will be the time to pull in a library from GitHub. If it's not to pull in a library, you're into unknowns.
Asking to estimate may work in aggregate if your 'gut' is good at assessing the amount of unknown your devs' face (e.g., 2x as much unknown work - multiply estimate by 3), but not in the specific. The specific amount of unknowns in a given task are unknown.
To translate a requirement into code will take exactly as long as it takes to discover and bridge the unknowns. You can't do anything about that, other than (a) change the requirement, or (b) change how much is known by the developer.
My rule of thumb is that if you cannot estimate your work to some degree of confidence up front then you haven't spent enough due diligence time and the design before writing code. If your task is too complex to estimate then estimate a time boxed proof-of-concept and then turn around with a solid estimate at the end.
Its my personal belief that any programmer who expects a check from an employer or a client for unbounded unscoped scope work usually isnt unreasonable. Just like any other profession.
But, you can look at a piece of code and go "no that doesn't make sense. Lets try this instead" and both reason about its quality or run tests on it. You can have nuanced discussions of what makes a piece of code more clear or a tutorial code example more easy to interpret.
It seems like no such nuance is available.
I share your opinion that it is unreasonable for me to expect to be paid without giving an estimate, but I hate hate hate lying to people and so I either avoid giving an estimate or I give one and try desperately to convey "this number is a near-random guess." I have on occasion failed to impress upon someone the uselessness of an estimate of mine and the deception makes me sick.
So I don't know what to do. I have occasionally considered giving up programming, but that seems drastic. I'm currently in a company that doesn't do estimates that much or put too much stock in them and has quite good habits for clarifying scope. But, I feel really unprofessional that I can't estimate.
For 10 years I was a small gig consultant 5 of which I worked solo. Fixed price contracts. Clients with tight budget. Projects with high technical variety.
People like us our product is our time. Getting things done on time/budget (or not) sometimes yield a significant impact on our reputation. Thats pressure especially when youre working with so many variables!
Everybody in this line of work goes through this on some level. Based in my downvotes above i assume many folks dont like the idea of trying to estimate to high accuracy. Thats their take. Everyone has their own opinion. Heres mine:
Itemize out the work into logical work items. For each item fix the estimate and the level of confidence on your estimate. If the level of confidence is below say 80% then state the unknowns and add estimate an optimistic/pessimistic range for the item instead of a single number.
After going through this exercise bring this to the client. In all my years doing this ive never had a client who didnt appreciate a thoughtful breakdown of the work and it became easy for all parties to appreciate what areas of the project had the greatest unknowns and why. Also the client can either accept the estimate based on the pessimistic high end of the range or we find a cheaper alternative or i scope a proof of concept. Either way the choices are clear to everyone even if the estimates arent entirely clear.
Sorry for the long-winded explanation and thank you for reading. I would summarize by saying an estimation is just that. it is not accurate but the unknowns are clear and the work is carefully considered before beginning in earnest.
Best of luck to you and don't give up
> Don't supervise the quality and volume of people’s work.
And I agree with the argument following that sentence. On the other hand, 2 points above that it says:
> Do enforce behavioral and performance standards. Fire bullies and underperformers.
So how else do I recognize underperformers without taking note of quantity and quality of people's output? Surely I can't just take someone else's word for it (and by the point a peer complains about this it's probably too late already anyway?).