[jkovacs]

Question: It says at point 8:

> 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?).

[dom0]

If you require metrics to determine whether an employee is productive in a team, then that is a red flag (to me) that you need to communicate more. Talking to people is a far better way to find issues than looking at metrics.

I'm highly sceptical of managers that are focused on measuring metrics.

[ooqr]

This would be a pretty nerve-wracking position for an employee. Sometimes it takes a long time to hunt down a single-line change to the code to fix a bug.

[sleazebreeze]

I believe it's the responsibility of the person hunting down that one-line change to communicate to their team what was involved with tracking that down. Everyone can learn from a single person's deep dive. An engineer shouldn't feel like they're doing something risky for their career by carefully working through a hard problem with unimpressive code results.

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.

[Rapzid]

Agreed. If it takes a week to make a line change it'd be very unusual IMHO if the entire team were not aware by that point of some the challenges involved. It may even warrant a short presentation on the technical challenges and how the issue was tracked down or solved; good learning opportunity.

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.

[wolco]

Daily standups make me focus on what sounds good to be doing for the next standup. A one line bug that drags on for weeks can be magnified at those meetings.

[jeddf]

Point 4 talks about knowing what everyone is working on, I think just from that a good manager with technical competency can discern underperfomers.

[scott00]

I was initially confused as well. Would be interested in an authoritative answer from the author, but this is what I came up with upon reflection: the behavioral and performance standards he's talking about are the ones that are primarily social and relatively objective. So, for instance, if one of your team members is prone to shouting at colleagues, it's the manager's job to explain that he expects everyone to act civilly. If the team has decided to adopt code style rules or test coverage requirements, and someone frequently flouts those rules, it's the manager's job to tell them they have to follow the team rules or find another team. Stuff like that.

[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.

[user5994461]

It's never too late.