"When did you start creating solutions that were completed sooner, performed better, and/or solved more problems than you or others originally expected?"

This question implies that poor resource estimation skills are a sign of a good programmer. I contest that suggestion.

If you finished sooner than you expected, what was wrong with your original timeline estimate? If you "performed better" than expected, why did you underestimate performance in the first place? If you "solved more problems" than expected, why didn't you correctly explore the problem space to begin with?

Learning the answers to these questions, each time you don't do exactly what you expected, is important as well. Learn to do exactly what you set out to do, with the resources you intended to do, exactly as planned. If you can't, work on your design skills, or your planning skills until you can.

When you do exactly what you intend to, with the resources intended, and the product works exactly as designed, then you've got a solid development process. When you can do that, then working out what you want to accomplish is all that's left; it's a hard job, too, but easier than most of the others.


In reply to Re^2: Reading the manual and knowing if you are getting good by Anonymous Monk
in thread Reading the manual and knowing if you are getting good by ghenry

Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":