This post says that in order for somebody be able to solve a multiple-step problem, one needs:
First, a repertoire of practiced moves, which can be done with little cognitive overhead.
Second, the means to sense whether or not a move actually makes progress, or if it’s just a dead end.
(which reminds me of the “gulf of execution” and “gulf of evaluation” in UX, but that’s not what I came here to say)
I would like to add the dual of “knowing when you’ve made progress”: “knowing when you’ve made a mistake” and “recognizing which mistake you’ve made”.
For example, I have a bread machine, and there’s a very useful section where it says “if the bread is too think, there was too much flower”, and I think this kind of knowledge is invaluable when learning how to do something.
There was an image on social media showing various cookies with captions like “too much salt” etc a while back. As someone who did not grow up cooking, one thing I find very frustrating about reading recipes is that they generally assume you already know how the knobs affect the outcome, so they will say “salt to taste” or whatever without giving you a sense of how doing more or less of some step will affect the outcome and how to judge which way you went wrong. It would better to have ranges like 1tsp salt will be minimally savory and 3tbs will be crunchy so you have a sense of the parameters.
I’ve been trying to add “if you got this error, you probably did X” notes to the errors in the $WORK code I write. “You probably escaped this string one too many times” instead of “unable to parse string”, “you’re running this script inside a deployment image, but it’s only meant to run on dev workstations” instead of “git status failed”, that sort of thing.
So much this. First time I tried to build a big project at $WORK, every time I got an error than could’ve been detected earlier (at configuration time), I added a check with some explanation like “some/path/to/library/foo.h” doesn’t exist, check that $libary_root is set correctly”, and even added some message like “you probably meant this instead of that”. And all this made building the project so so much easier (especially for new or inexperienced people, but also for veterans that just don’t build that project often).
I’ve also written some documentation for setting up or modifying a continuous integration pipeline/workflow. There are so many things that can go wrong, and the feedback loop can be very long, so having a list of common errors and where they come from is very useful.
Now that I think of it, the worst is not when you don’t know how to fix a problem, the worst is when you don’t know and it takes a long time to test a different approach (like cooking).
Oh yeah, I’m currently working on another change that will cut down the time to iterate on a thing from minutes to seconds and I got so much “holy shit I wish we had this three months ago” feedback from it.
Yes, few weeks ago I shortened a CI pipeline from 2 hours to 20 minutes insert feels-good meme, and converted every remaining manual step to one-liners command line (that I will further automate next time I work on this). And I had the same reaction of “holy shit I wish we had this three twleve months ago”
I know I’m getting further away from the main subject, but: I think it’s (roughly) always worth automating something, because you’ll always learn something, and that compounds even faster that the time you save by making processes faster.
Somehow this made me imagine “lobste.rs for crows”, with headlines like
This post says that in order for somebody be able to solve a multiple-step problem, one needs:
(which reminds me of the “gulf of execution” and “gulf of evaluation” in UX, but that’s not what I came here to say)
I would like to add the dual of “knowing when you’ve made progress”: “knowing when you’ve made a mistake” and “recognizing which mistake you’ve made”.
For example, I have a bread machine, and there’s a very useful section where it says “if the bread is too think, there was too much flower”, and I think this kind of knowledge is invaluable when learning how to do something.
What to you think about this? @hwayne
There was an image on social media showing various cookies with captions like “too much salt” etc a while back. As someone who did not grow up cooking, one thing I find very frustrating about reading recipes is that they generally assume you already know how the knobs affect the outcome, so they will say “salt to taste” or whatever without giving you a sense of how doing more or less of some step will affect the outcome and how to judge which way you went wrong. It would better to have ranges like 1tsp salt will be minimally savory and 3tbs will be crunchy so you have a sense of the parameters.
I’ve seen that image, and I found it very useful.
And yes, the best recipes tells you what can go wrong and how to avoid it
instead of telling you the life story of some random person.I’ve been trying to add “if you got this error, you probably did X” notes to the errors in the $WORK code I write. “You probably escaped this string one too many times” instead of “unable to parse string”, “you’re running this script inside a deployment image, but it’s only meant to run on dev workstations” instead of “git status failed”, that sort of thing.
So much this. First time I tried to build a big project at $WORK, every time I got an error than could’ve been detected earlier (at configuration time), I added a check with some explanation like “some/path/to/library/foo.h” doesn’t exist, check that $libary_root is set correctly”, and even added some message like “you probably meant this instead of that”. And all this made building the project so so much easier (especially for new or inexperienced people, but also for veterans that just don’t build that project often).
I’ve also written some documentation for setting up or modifying a continuous integration pipeline/workflow. There are so many things that can go wrong, and the feedback loop can be very long, so having a list of common errors and where they come from is very useful.
Now that I think of it, the worst is not when you don’t know how to fix a problem, the worst is when you don’t know and it takes a long time to test a different approach (like cooking).
Oh yeah, I’m currently working on another change that will cut down the time to iterate on a thing from minutes to seconds and I got so much “holy shit I wish we had this three months ago” feedback from it.
Yes, few weeks ago I shortened a CI pipeline from 2 hours to 20 minutes insert feels-good meme, and converted every remaining manual step to one-liners command line (that I will further automate next time I work on this). And I had the same reaction of “holy shit I wish we had this
threetwleve months ago”obligatory xkcd: https://xkcd.com/1205/
I know I’m getting further away from the main subject, but: I think it’s (roughly) always worth automating something, because you’ll always learn something, and that compounds even faster that the time you save by making processes faster.