| > comes down to experience. 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. > If you don't have a spec, get a spec. Yea, I think I'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. The hard part is how to write out the technical details ahead of time before I've gotten my mind into the codebase Im adding onto or the new framework I'm using. > Risk assessments Any tips on what to read to do these effectively? > Once you understand what is going on So I should feel safe in disregarding the advice to "avoid trying to understand the universe"? Or at least attribute it more to how I communicate about being stuck on a problem? That is kinda a relief. I really didn't understand how to put that advice into practice. > A few good books on estimation and debugging I'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'm looking to start out with being able to reliably estimate how long I can get done in 90 minutes. |
You might take a look at www.amazon.com/Rapid-Development-Taming-Software-Schedules/dp/1556159005/. Although it's 20 years old, it has some good ideas in it. It's also more about 6-month estimations than 90-minute estimations, though.