These are all excellent questions.
> What do you do when you don't have a spec and when you ask the senior engineer you are working with questions, they don't respond or push back against having a spec or a plan longer than the very next feature?
Oh man, it drives me nuts to hear this. I'm a senior engineer, and you know what my biggest complaint is about many junior engineers? They don't ask enough questions! So to hear that you're asking questions and not getting a helpful response is beyond frustrating.
And in my view, a senior engineer who won't plan beyond the next feature is incompetent. I mean, I sometimes am forced to admit that I haven't figured something out yet, or in some cases haven't even thought about it yet, but if it's important, I make a point to figure it out. Maintaining architectural coherence of the product in the long term is, in my view, one of my most important jobs.
> The author says that estimation is easier to do if you are doing something you have done before. What do you do if you are always working with a new framework or language?
> How do you break down the steps if you don't know what a project entails until you are finished?
I hope you're not really _always_ working with a new framework or language, but yes, in software we're usually doing something new for every project, because it would be pointless to do the same thing over again.
You'll have to take anything I say about estimation with a grain of salt, because I've been in the business 35 years and I still suck at estimation. But your second question hints at the best answer I know, which is that you have to get well started on a project -- at least 1/4 of the way in -- before you can begin to give confident estimates of how long it will take.
What the OP is suggesting is to try to go at it breadth-first rather than depth-first: figure out what the top-level tasks are, then their immediate subtasks, then the level below that, etc., rather than just diving into the first thing until you get it done. I'm sure they have a point and I don't do enough of this. But the counterpoint is that doing this is a task in itself, and takes time -- to do it well takes a significant fraction of the time of the project. If the business needs are such that that makes sense, then do it.
> What do you do if asked to estimate how long something will take to debug?
You say "I don't know." If you've tracked down other bugs in the same code before, you can offer that in the past, bugs in that code have taken so many hours or days, but you can't promise this one won't be harder. If you have no experience with that code, though, stick to saying you don't know.
> I've gotten the feedback that I should avoid trying to "understand the universe" when debugging.
Ay ay ay. Find a new job.
The last thing I want is my team members making fixes without at least trying to fully understand the consequences. Sometimes we think we understand but it turns out that we didn't, and that's life, but not to even make the attempt is a sure path to code rot... making the code even harder to understand for the next person. I guess some people get inured to the idea that they'll never fully understand what's going on and they have to try to fix it anyway, but in my opinion, the best engineers always try hard to understand first.
> Why do experienced engineers ask for estimates anyway?
Well, in fairness, there are cases where we have multiple things to fix, and their relative priority depends partly on how much time they're likely to take. So getting some kind of order-of-magnitude estimate, if possible, can be helpful. But how experienced engineers can forget that there is always an element of guesswork in these is beyond me.
> How do I deal with it when they are upset about it taking a week and a half?
If they won't give you walkthroughs, and they won't answer questions, and they still get upset when things take time... yeah, get a new job.