There are a lot of inexperienced software engineers and very little good guidance written for them. What is a new CS grad to do when asked for an estimate? How can a new grad learn to produce accurate estimates within 3 months?
A problem with our industry in this regard is that we don't understand the difference between learning and doing.
A new grad entering industry is going to be doing a lot more learning than doing -- or rather learning while doing.
I know from experience that explicit doing is highly predictable/estimate-able for the experienced software practitioner.
I have a suspicion that the learning side would be predictable, too, if our industry could do a better job of articulating what the practitioner skill set actually is -> then a pedagogy could develop and it could be said that learning X-Y-Z takes on average this long for a set of students. Etc.
But we as an industry do not seem to be near this level of clarity -- in large part because we don't even have the vocabulary to frame it this way... in terms of learning vs doing...
Now what this means for the new CS grad is not the best story. You'll rather have to play the chaotic game a little bit, which includes a mess of things like doubling estimates and working weekends or what-have-you depending on the work culture you find yourself within.
That ^^ in the short term.
In the long term what you should do is practice on your own:
1) ALWAYS privately plan and estimate your tasks to the best of your ability--on your own, you may not get benefit by exposing your "practice" to the higher-ups
1a) hint: your tasks should be as scoped/small as you can make them and they will look pretty simple, like this: "design widget X", "design API interface", "implement API interface", "test API interface", "implement widget Y", "learn how framework X lifecycle works" (yes! even learning tasks can be estimated!), and so on. The key is that you try to keep them under a day and ideally even smaller on the order of hours.
2) RECORD the time it takes and compare to your estimates. --> LEARN from this.
3) REPEAT
If you do this conscientiously you will find that your estimates improve dramatically over time and you'll be able to out-estimate your peers to their own wild confusion.
This skill set will pay off in your ability to deliver AND have weekends and hours with your family. Because you will be able to "see time" and protect yourself. You'll have protection and ammo even in the worst pressure-cooker environments because you will be able to say "No" with confidence. Or rather you will learn how to say "Yes" and what to say "Yes" to. (Ie. you will get really good at priority negotiation etc.) And you'll cultivate delivery trust with superiors and everyone will be happy.
The main reason you get these claims that "business just doesn't understand software" and "they put too much pressure on us" is because "business" side doesn't trust us. Once you get good at estimates and delivering on them, that trust is restored and everyone can be made happy.
BUT -- and here's the rub -- it takes time and conscientious effort and variety of experience to reach this level of confidence. My advice: Ignore all the philistines who say it can't be done....because they'll just try to talk you out of the effort that they weren't or aren't willing to do themself.
There are a lot of inexperienced software engineers and very little good guidance written for them. What is a new CS grad to do when asked for an estimate? How can a new grad learn to produce accurate estimates within 3 months?