Okay, I admit to being a freak even among programmers when it comes to project management issues, e.g., time estimation.
I began my programming career as a mathematician who'd already studied advanced topics in Statistics and Probability (Pure Mathematical Statistics, Bayesian Inference, Linear Regression, Auto-Regressive-Integrated-Moving-Averages) and Operations Research (Queueing Theory, Decision Theory, Chaos Theory, Linear Programming). When I ran into the idea that programmers had trouble understanding how to develop project estimates, it took me slightly aback. I simply hadn't considered the possibility that people doing "Extreme Boolean Algebra" (one of my favorite nicknames for programming) would think of all this estimaty-stuff as anything other than obvious or at worst relatively trivial, extra stuff to be learned...my failure - not theirs - I too was young and inexperience once upon a time.
I'm unfortunately frequently reminded that I let my education prejudice my perceptions of others who work in my field. Milica's story was a much needed slap up-side the head. We ain't all trained the same way, and sharing makes us all stronger.
I really do know the part about sharing...teaching others is one of the best ways to reinforce and extend one's own understanding of a topic. I've taught lots. When you try teaching something you (think you) well understand, and your class all tilt their heads like the RCA dog (looking at their masters' voice), it makes you teach harder, i.e., find different words, new examples, etc.
It's the wee, small hours here in GMT-5. I am almost certain to revisit this topic and offer views to expand my grasp of Milica's views and add my own in wider degree.
Estimation - GOOD ESTIMATION - is a MOST important project skill. New developers need to get it. New developers need to understand that, until they CAN reliably estimate time and explain their estimates, they will usually remain juniors in their shops and correctly so. Being good at estimates is important. Better is being able to detail how you arrived at your estimate, whether it was accurate or not. It correctly) reassures your local gods and godesses (PMs, directors, etc.) to hear your reasoning, if it was good, and to understand how some unusual condition nailed you. It's also good for you to have that understanding.
One of the most frequent misunderstandings of decision-making is the belief that good decisions are directly related to the goodness of the outcome of the decision. The decision is good or bad with respect to :
The goodness of a decision is a function of how well pre-decision data and probability estimates were collected and incorporated into the pre-decision model, NOT whether the actual outcome of the decision was desirable.
There's a supremely good article that I have squirrelled away somewhere in the morass of things still in moving storage (I and my sweetie will be moving from now until about July of 2019). I'll try to track down the article and provide an online link.
Oh, and any time some PM type attempts to button-hole you in a narrow hallway, to pin you down ambush-style on the timing of delivery of a feature, learn to recite, until it falls trippingly from the tongue..."let me get back to you on that."
Thanks, Milica - You Rule.
P.S. I wrote a time/project article a while back that relates mainly to the management of clients as project resources. This directly relates to some of Milica's points. User, clients, business stakeholders, Project Manages, no matter what you call these non-IT types, all of these stakeholders are integral parts of your estimation process. If you fail to consider and manage them to a fully proper degree, your estimates are worthless.
I posted a copy of the related story at: