&gt; comes down to experience.<p>Yea. I really should get into the habit of keeping better records of things so that I can look back on past projects. I write in a paper notebook as I program, but that is usually just thinking out loud or trying to artificially increase my working memory.<p>&gt; If you don&#x27;t have a spec, get a spec.<p>Yea, I think I&#x27;ve concluded that I need to always write a spec for myself before I start a project. I know Joel says that PMs should write specs, but I should be prepared for the reality that projects rarely have separate PMs.<p>The hard part is how to write out the technical details ahead of time before I&#x27;ve gotten my mind into the codebase Im adding onto or the new framework I&#x27;m using.<p>&gt; Risk assessments<p>Any tips on what to read to do these effectively?<p>&gt; Once you understand what is going on<p>So I should feel safe in disregarding the advice to &quot;avoid trying to understand the universe&quot;? Or at least attribute it more to how I communicate about being stuck on a problem? That is kinda a relief. I really didn&#x27;t understand how to put that advice into practice.<p>&gt; A few good books on estimation and debugging<p>I&#x27;ve read Debugging: 9 Indespensible Rules, Mythical Man-Month, Critical Chain, and a few chapters from Software Estimation: Demystifying the Black Art. Do you have any other recommendations? The latter three books seem to be talking on the level of projects that are anticipated to take at least 6 months. I&#x27;m looking to start out with being able to reliably estimate how long I can get done in 90 minutes.