[burlesona]

This is a great list. I would add estimating, although it's implied in a few of your points.

As an engineering manager I find that a consistent difference between good engineers and great engineers is that great engineers can tell me how long something will take even when they haven't done something just like it before. That doesn't mean they can perfectly forecast how the hours will be spent -- no one could do that -- but they know how to figure things out, know how to build in some buffer, and know how to go heads down and crank when absolutely necessary, and as a result they can consistently hit deadlines.

[ramblerman]

It’s funny that in your narrative good to great means scoring well on the one metric that helps you personally.

I’m not picking on you. But I guess it highlights how hard this list is.

Estimation would by no means be the distinguishing factor to call a programmer great in my book

[burlesona]

Well, I don’t think it’s just about what helps me. I think it’s about the craft of Engineering, which is fundamentally about shipping things.

You can be a good coder but struggle to deliver because you get distracted or rabbit hole, over or under engineer, etc.

The engineers who have really mastered their craft have mastered not just the coding, the infra, operations, etc. they’ve mastered putting it all together and getting it out to the world.

The ones who have mastered all that can usually give pretty good estimates. The ones who haven’t usually find estimating to be difficult.

So it’s not so much that estimating is the single critical skill, but rather that estimating comes from a synthesis of all the other skills, and as a result it’s a good indicator for how much someone has mastered the craft.

[pytester]

Estimation effectiveness is inversely proportional to the intrinsic difficulty of the problem you work on. Being a programmer who is good at estimation is a bit like being a doctor with the lowest post-op death rates - it doesn't necessarily mean you're actually the best.

[Aloha]

Providing an estimate isnt impossibly hard, I've found there is much more forgiveness for putting a long estimate in, and then coming in early, than putting a short one in, and coming in late.

Stuff I've not done before can be a real challenge, I just add a 50% slop factor, but I won't even give a guess until I can at least have a modicum of understanding of the complexity of the problem, technologies and people involved.

Generally for stuff I'm familiar with - I take how long I think its going to take, then double it, and thats what I give to my management. For stuff I'm not familiar with, I guess based on like-like work, and then add 30-50% more time in, then double that. For some of our customers however, working with them incurs a time penalty, so I add another 20-40% on top to their estimates.

The feedback I've been given is that my time scopings are reasonably accurate however. So while I feel silly turning in an estimate for 24 hours for a task that I think ought to take 8, time and time again, it takes closer to 18-20 hours rather than the 8 I feel it ought to (usually because of external factors outside of my control).

[arethuza]

I think the concepts I would add are understanding the differences between an estimate, a commitment, a plan and what role risk plays in all of these.

[drieddust]

Don't you think estimation is a management job? What if Engineer decides to over estimate and enjoy the freetime?

[hamburglar]

A manager with an attitude that engineers would pad their estimates to "enjoy the free time" is a guaranteed way to get good engineers to quit a team. Not only does it betray a complete lack of trust, but it means engineers are going to be pressured to lower their estimates, which never turns out well.

[taneq]

Absolutely not. It's hard enough for a seasoned senior engineer to estimate something, let alone a non-technical manager. (Of course, said seasoned engineer might be in a managerial role now but it's still an engineering task.)

[sgift]

Only the person who does the job can do the estimate. Estimation by third-party is no better than rolling a dice.

[winrid]

Usually it's a team effort and not just one person. Yes the manager should have say.