4 ms·

Could you elaborate? I'm not sure what it means to apply these to software development (at least, 1 and 3). Also, what does drainage mean in this context?

Jtsummers 3y ago
Retrospection, orientation, and I'll re-phrase the last one as "maybe stop digging that hole before it's so deep you can't climb out." (I'm guessing on that last one, not heard drainage used that way either.) Retrospection: Periodically examine what you've made and how, identifying the good, the bad, and the ugly. Try to structure your future work to produce more of the good and less of the bad and ugly. Orientation: Periodically check to see if you're making what you meant to make, is what the customer wanted you to make, and is still what the customer wants you to make. "Stop digging": Ok, you have a bit of code that's almost right, but it fails some tests. Add an extra conditional here, copy/paste a function there, change a constant in the copied code, voila problem solved. Oh, failing another test, let's repeat, and repeat. In the end you have 10x (or more) the necessary code and anyone looking at it would, rightfully, mock you for copying a 10 line function multiple times to make "render_with_black_background", "render_with_blue_background", "render_with_green_background", etc. when you, maybe, could have made it a parameter (with a default value) instead. It's related to the previous two in the sense that if you're actually retrospecting and periodically orienting, you probably won't dig the hole too deep.
082349872349872 3y ago
1/ "look backwards" - for hiking, literally do so, so it'll look familiar going the other way. For software, remember when and where you've made arbitrary decisions, so you can revisit them and try a different branch when current development isn't working. 3/ "never leave your drainage" - a river-system drainage. for hiking, go downstream when lost: this will narrow the area you might be in, and tends to take you towards civilisation rather than away from it. for software, more metaphorical: debug by figuring out what's working as expected and ruling it out, thereby narrowing the area the bug might be in; the equivalent of leaving a drainage —hiking across a pass into new drainage— would be "fixing" an issue based on what you think the problem is, rather than what you know the problem is, only to wind up with a system that still doesn't work, and now not having any idea if odd behaviour comes from the original problem or from the "fix".

Jtsummers 3y ago

Retrospection, orientation, and I'll re-phrase the last one as "maybe stop digging that hole before it's so deep you can't climb out." (I'm guessing on that last one, not heard drainage used that way either.) Retrospection: Periodically examine what you've made and how, identifying the good, the bad, and the ugly. Try to structure your future work to produce more of the good and less of the bad and ugly. Orientation: Periodically check to see if you're making what you meant to make, is what the customer wanted you to make, and is still what the customer wants you to make. "Stop digging": Ok, you have a bit of code that's almost right, but it fails some tests. Add an extra conditional here, copy/paste a function there, change a constant in the copied code, voila problem solved. Oh, failing another test, let's repeat, and repeat. In the end you have 10x (or more) the necessary code and anyone looking at it would, rightfully, mock you for copying a 10 line function multiple times to make "render_with_black_background", "render_with_blue_background", "render_with_green_background", etc. when you, maybe, could have made it a parameter (with a default value) instead. It's related to the previous two in the sense that if you're actually retrospecting and periodically orienting, you probably won't dig the hole too deep.

082349872349872 3y ago

1/ "look backwards" - for hiking, literally do so, so it'll look familiar going the other way. For software, remember when and where you've made arbitrary decisions, so you can revisit them and try a different branch when current development isn't working. 3/ "never leave your drainage" - a river-system drainage. for hiking, go downstream when lost: this will narrow the area you might be in, and tends to take you towards civilisation rather than away from it. for software, more metaphorical: debug by figuring out what's working as expected and ruling it out, thereby narrowing the area the bug might be in; the equivalent of leaving a drainage —hiking across a pass into new drainage— would be "fixing" an issue based on what you think the problem is, rather than what you know the problem is, only to wind up with a system that still doesn't work, and now not having any idea if odd behaviour comes from the original problem or from the "fix".