3 ms·

> No one should be allowed to avoid the issue by the old formula, “I can’t give a promise because it depends upon so many uncertain factors.” STRONGLY disagree

by kabdib 14y ago

> No one should be allowed to avoid the issue by the old formula, “I can’t give a promise because it depends upon so many uncertain factors.” STRONGLY disagree. I've worked on projects where: - Getting a stable build might take four hours (minimum) to several weeks (depending on churn); - Processes for adding components were undocumented magic, and very nearly undebuggable; - Components might take days or weeks to propagate, once you were finally able to make changes to them. Debugging is a similar story. Some bugs are nasty, horrible, complex things that take a lot of time. I've seen showstopper-class kernel level bugs take months to find. The nature of interactions at the hardware / software interface is unbelievably complicated. So what does a "senior" engineer do? - Communicate the nature of the problems in a non-whiny way. - Give responsible estimates. "Three days or a month" is honest, if you say why. - DON'T promise results that you can't actually deliver. - Be prepared to have features cut, and to have conversations about things that you consider less than optimal ("sucky") for the customer. Naturally, your senior engineer is also trying to improve the sucky situation the whole team finds itself in (with better tools, build processes, whatever), but some situations are intractable.

kabdib 14y ago
I'll add a little. I do see this a lot in less experienced engineers. "I can't tell you when X will be done." On the other side, I see people promise stuff they can't possibly deliver (due to pressure from management, or simple optimism, or plain cluelessness about the difficulty of a problem). So part of a senior engineer's job is to notice when someone is making bad estimates and correcting the issue. This can range from simple conversation with the engineer, to diving in and helping out, to getting someone transferred or terminated for unfixable cluelessness. Some good tools: - Socratic method. "What don't you know? Can you figure it out?" Repeat. Also, deep examination of base assumptions ("Are you /sure/ you know XXX? Let's dig into that for a bit.") - Crap shield. "Look, leave Figby alone for a few days until he works this out. It'll give him confidence and make him a better engineer." - Crap generator (use this sparingly). "What that guy is doing just isn't very hard, and he's not doing a good job. Have one of ours do it instead, and have your guy do something else." Bring ironclad evidence to the table on this one, because this conversation usually precipitates a firing. The old saw of "Good. Fast. Cheap. Pick two." is so over-used, but it is /so/ damned true. We've been engineering bridges for thousands of years, and we have a pretty good handle on what makes a good bridge. In software, I've come to think of the engineers /as/ the bridges, and we can't engineer a better engineer yet.
DougWebb 14y ago
The difference the article is talking about is a junior engineer saying "I don't know and I don't know how to know, so I'm not going to answer your question" and the senior engineer giving estimates just like the ones you gave: "a build is at least four hours, but if I'm churning it can take several weeks". Junior engineers don't know that an estimate like that is possible to give and provides value. They're often brow-beaten by lots of project managers who don't get the value of an estimate like that, who'll just press you for a single number that you'll commit to, the closer to the low end the better. But actual business managers can hear that estimate and make a business decision: a) I need the build in 15 minutes for a demo... sounds like that's not possible, so skip it. b) I going to need the build to be stable in two months. You'd better get started now, and I should be ok. c) Hmm... I need it next week. Seems we have a business risk here. How can we mitigate that? Part of a senior engineer's value is being able to see the business need to address business risks that are inherent in the question "How long will this task take", and to respond accordingly. The article touches on this too, where it discusses holistic contextual awareness.
- deleted 14y ago
  [deleted]

by kabdib 14y ago

kabdib 14y ago

I'll add a little. I do see this a lot in less experienced engineers. "I can't tell you when X will be done." On the other side, I see people promise stuff they can't possibly deliver (due to pressure from management, or simple optimism, or plain cluelessness about the difficulty of a problem). So part of a senior engineer's job is to notice when someone is making bad estimates and correcting the issue. This can range from simple conversation with the engineer, to diving in and helping out, to getting someone transferred or terminated for unfixable cluelessness. Some good tools: - Socratic method. "What don't you know? Can you figure it out?" Repeat. Also, deep examination of base assumptions ("Are you /sure/ you know XXX? Let's dig into that for a bit.") - Crap shield. "Look, leave Figby alone for a few days until he works this out. It'll give him confidence and make him a better engineer." - Crap generator (use this sparingly). "What that guy is doing just isn't very hard, and he's not doing a good job. Have one of ours do it instead, and have your guy do something else." Bring ironclad evidence to the table on this one, because this conversation usually precipitates a firing. The old saw of "Good. Fast. Cheap. Pick two." is so over-used, but it is /so/ damned true. We've been engineering bridges for thousands of years, and we have a pretty good handle on what makes a good bridge. In software, I've come to think of the engineers /as/ the bridges, and we can't engineer a better engineer yet.

DougWebb 14y ago

The difference the article is talking about is a junior engineer saying "I don't know and I don't know how to know, so I'm not going to answer your question" and the senior engineer giving estimates just like the ones you gave: "a build is at least four hours, but if I'm churning it can take several weeks". Junior engineers don't know that an estimate like that is possible to give and provides value. They're often brow-beaten by lots of project managers who don't get the value of an estimate like that, who'll just press you for a single number that you'll commit to, the closer to the low end the better. But actual business managers can hear that estimate and make a business decision: a) I need the build in 15 minutes for a demo... sounds like that's not possible, so skip it. b) I going to need the build to be stable in two months. You'd better get started now, and I should be ok. c) Hmm... I need it next week. Seems we have a business risk here. How can we mitigate that? Part of a senior engineer's value is being able to see the business need to address business risks that are inherent in the question "How long will this task take", and to respond accordingly. The article touches on this too, where it discusses holistic contextual awareness.

deleted 14y ago
[deleted]