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" an

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.