[pweissbrod]

Measure timeliness with respect to estimates. Measure the transparency in which they communicate the progress and focus of their work. Measure the clarity in their design and scoping. Measure what other developers say about their work in peer reviews. Measure how well their work runs in production, how many escalations and emergency bug fixes are needed?

[afarrell]

> Measure timeliness with respect to estimates

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.

[Terretta]

You can only estimate what's known.

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.

[pweissbrod]

I hear you. Estimation is a skill just like coding or documenting or management. Some people have a better knack for it than others. But it is an important skill and a part of being a professional engineer.

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.

[afarrell]

> just like coding or documentation

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.

[pweissbrod]

I've been there. I appreciate what youre saying. You sound like an honest logical person. Id love to help you if i can.

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

[_asummers]

The best phrasing I've seen is "multiply by your favorite number between e and pi", because that gives you some wiggle if you are particularly good or particularly bad at it.