1. I worked at a bar in college where I was a grill man. There was a CS student I worked with, and he was my assistant (setting up plates for food, telling me what toppings the next n burgers got, and so on) or sometimes we switched jobs. It turns out that scheduling algorithms, queueing theory, parallelism and exception handling all map very well to the grill domain. Not metaphorically either, we literally would implement various algorithms from classes and apply them to our grilling. Led to some amusing scenes, particularly when the other kitchen workers tried to listen in on our arguments. By the end of that job, we had optimized the crap out of the kitchen by applying basic algorithms.
2. I garden... a lot. I frequently do tasks the way I would program them to be done - e.g. when to plant seed(s|lings). Turns out that all at once is a terrible way to do things. Instead a garden should be "pipelined" north -> south. Some seeds this week at the north end. Some more next week just south of that. Repeat till the end of the rows. This makes the a tallest plants at the north where they don't get shaded by more southernly plants. Also, it lengthens the "season", as the north plants can be done fruiting just as the south ones are flowering. Other techniques include A/B testing, layout algorithms and other optimisation problems around compost and mulch.
More generally, I don't even realize how natural modularizing/componentizing/factoring has become to me. I have an ex-girlfriend who I would frequently fight with over this -- well the effects of it. She would bring up a problem, and I would rattle off an on-the-fly algorithm of, what needs to be done, what order, and how the tasks should be divided, with some assumed dependency resolution. To me, this was a simple starting point, I fully expected to revise and refactor, based on missed dependencies, redundencies, and so on. Basically from my POV I would whiteboard an algorithm to get some common terms, and I would know it was a shit algorithm, like n^k or worse. To her (not trained in CS) it sounded like a decent solution, that would take a while to come up with... a well planned thing. The fights would come of it because she thought I wasn't including her in my thinking about problems we wanted to solve together (and in retrospect I get how it could look that way, particularly when she would point out a constraint I missed and I would just spit out a reworking of the original around the constraint -- doubly understandable things I considered glaring flaws could really be considered trivial since they only add a small penalty (n^2 is not terrible in runtime when n is small to begin with)). Anyway, the moral and tl;dr of this paragraph is: planning stuff is isomorphic to setting up an algorithm. Which moves us into my final stretch of rambling:
Programming is the act of describing a process (meaning sequence of actions here...), preferably in a way as to minimize the number of actions. This is now how I describe my job to people. I use examples like building things, or cooking or paperwork, or whatever, then explain how this related to the computer instructions. Turns out a lot of people actually get this (as opposed to talking about computer languages, or using fancy terms like algorithm).
tl;dr -- programming is just setting up a sequence of actions for a computer. Anything else that uses a sequence of actions can benefit from programming techniques.