• BCsven@lemmy.ca
    link
    fedilink
    arrow-up
    0
    ·
    2 months ago

    I Prefer a playbook to a recipe card. The playbook should spell out the goal and the 'why’s of the steps. Because if the process throws an error due to upgraded code etc, then you can be stuck at step one with no path forward. With some playbook annotation you at least know expected out come and why you are running a command etc.

    When I have gone to docker hub I always view multiple images and see what their writeup is like. Some just assume you 100% know all dockers subtleties, some have a one liner, but there will be a helpfull soul who spells out what steps to do, and what the best options to set etc. Like a mini tutorial.

    I find the mini tutorial to be widely beneficial, because it removes the blackbox nature, and gives new onboarding users a chance to grasp the concepts docker works with.

    It’s like the difference between going to a mechanic that has you sit by the coffee machine in the office while they change your brakes and they come back and say “I swapped the new pads in”, vs them pulling up a chair in the shop and explaining the process “here I’m wirebrushing the back of the wheel and the hub, to make sure when it goes back on there is no corrosion debris stopping a parallel fit…now I’m applying high temp grease so that the hub and wheel don’t sieze together from corrosion and make next removal easy”

    The info is probably useless to a seasoned mechanic that had a broken hand so had somebody else do their brake work, but highly useful to the next gen of person that can absorb it and know whats and whys.

    • It’s like the difference between going to a mechanic that has you sit by the coffee machine in the office …

      Good example. I just wanted to add that the place I go to for tyres, if there’s some kind of issue (like with balance or alignment), sometimes they even take me into the workshop (where customers are usually not allowed) to show me what the issue is.