3 ms·

For me, it really helps to have external structure in which to learn. I had fooled around with computers, but I don't consider that I really learned how to pro

by dmoney 17y ago

For me, it really helps to have external structure in which to learn. I had fooled around with computers, but I don't consider that I really learned how to program until CS 101. Getting a job and learning what a big disgusting mess software can sometimes be was another big step. Finishing projects I start on my own is a lot harder. I started composing a longer response to this, but it's getting too long for a comment one thing from it. Maybe I'll post it when it's done. Here's a paragraph from it: One thing I continue to learn is how bad I am at estimating. I think the key to estimating how long a software project will take is not to lie to yourself. It's easy to be overly optimistic about your ability to keep things on schedule by working extra hard or being extra smart (step 1, step 2, ... and then a stroke of genius happens... step 4: profit!!!). Software complexity (and hence development time) grows non-linearly with feature set. When you're thinking about squeezing in one more little waffer-thin feature, you have to trust your gut when the little exclamation point or question mark appears over your head. Also, estimating (and re-estimating) takes time. Giving estimates off the top of your head is a recipe for disaster.

hga 17y ago
Hmmm, it wasn't until almost 20 years after I had started programming that I could make solid "off the top of my head" estimates (by the end of the project (C++ multithreading server), per item I was accurate within 30 minutes). I think it's both a matter of experience including some on the particular project and eliminating the unknown unknowns. Doing the latter is my first priority in a project, e.g. by getting something working end to end ASAP. Also, to avoid the "working extra hard" trap (what, you aren't already working as hard as it makes sense???), you must always make the estimates in man-hours, not The Mythical Man Month. Then and only then should someone try to turn that into a calendar schedule, allowing for inevitable downtime and so on.

by dmoney 17y ago

hga 17y ago

Hmmm, it wasn't until almost 20 years after I had started programming that I could make solid "off the top of my head" estimates (by the end of the project (C++ multithreading server), per item I was accurate within 30 minutes). I think it's both a matter of experience including some on the particular project and eliminating the unknown unknowns. Doing the latter is my first priority in a project, e.g. by getting something working end to end ASAP. Also, to avoid the "working extra hard" trap (what, you aren't already working as hard as it makes sense???), you must always make the estimates in man-hours, not The Mythical Man Month. Then and only then should someone try to turn that into a calendar schedule, allowing for inevitable downtime and so on.