These are all excellent questions.<p>&gt; What do you do when you don&#x27;t have a spec and when you ask the senior engineer you are working with questions, they don&#x27;t respond or push back against having a spec or a plan longer than the very next feature?<p>Oh man, it drives me nuts to hear this.  I&#x27;m a senior engineer, and you know what my biggest complaint is about many junior engineers?  They don&#x27;t ask enough questions!  So to hear that you&#x27;re asking questions and not getting a helpful response is beyond frustrating.<p>And in my view, a senior engineer who won&#x27;t plan beyond the next feature is incompetent.  I mean, I sometimes am forced to admit that I haven&#x27;t figured something out yet, or in some cases haven&#x27;t even thought about it yet, but if it&#x27;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.<p>&gt; 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?<p>&gt; How do you break down the steps if you don&#x27;t know what a project entails until you are finished?<p>I hope you&#x27;re not really _always_ working with a new framework or language, but yes, in software we&#x27;re usually doing something new for every project, because it would be pointless to do the same thing over again.<p>You&#x27;ll have to take anything I say about estimation with a grain of salt, because I&#x27;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&#x2F;4 of the way in -- before you can begin to give confident estimates of how long it will take.<p>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&#x27;m sure they have a point and I don&#x27;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.<p>&gt; What do you do if asked to estimate how long something will take to debug?<p>You say &quot;I don&#x27;t know.&quot;  If you&#x27;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&#x27;t promise this one won&#x27;t be harder.  If you have no experience with that code, though, stick to saying you don&#x27;t know.<p>&gt; I&#x27;ve gotten the feedback that I should avoid trying to &quot;understand the universe&quot; when debugging.<p>Ay ay ay.  Find a new job.<p>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&#x27;t, and that&#x27;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&#x27;ll never fully understand what&#x27;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.<p>&gt; Why do experienced engineers ask for estimates anyway?<p>Well, in fairness, there are cases where we have multiple things to fix, and their relative priority depends partly on how much time they&#x27;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.<p>&gt; How do I deal with it when they are upset about it taking a week and a half?<p>If they won&#x27;t give you walkthroughs, and they won&#x27;t answer questions, and they still get upset when things take time... yeah, get a new job.