| It comes down to experience really. The more you are exposed to, if you are paying attention, the easier it becomes to relate to previous events, which can help inform estimates. If you don't have a spec, get a spec. A Senior engineer may be more reluctant to help you with implementation direction without knowing the requirements. Sometimes you need to do research to give an estimate. If someone asks you in person, or over e-mail, and you honestly don't know ask them if you can get back to them. Do not give them a number. Do the research, then reply. If you're relying on external APIs or Frameworks etc. You need to factor in Risk Assessments that include what happens if the fit is wrong, or the interface changes mid project, etc. When it comes to debugging a lot comes into play, system design, documentation, experience with the code. "I don't know" is an acceptable answer until you understand what is going on. Once you understand what is going on, you then estimate the fix based on the code. Giving a number before you understand what you are fixing in detail is a bad plan. I am exceptionally experienced with a certain code base and system. You may be experienced with a different code base. You're more qualified to handle estimation on what you know. That said, if you honestly don't know, say that. Don't low ball the amount of work if you actually have no idea how long it will take. There are a few good books on estimation and debugging, look around maybe they'll give you a few ideas. |
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.