I'm going to give one of the easy answers that probably a substantial amount of the respondents here can give: programming. Partly the point is to illustrate what sort of answer I am looking for.
One of the main tasks a programmer handles is fixing bugs. Often bugs are discovered because the user has encountered a situation where the program does something undesirable (for instance crashing or giving the wrong output). Usually this just annoys the user and nothing more happens, but sometimes the user reports the error and what they did before it happened to customer support, and then customer support enters it into a list of tasks that the programmers can look at.
The programmers may estimate the priority of various bugs that are reported. This priority can be estimated by various things, such as how commonly users report the bug (or statistically how common it is in logs emitted by the program), how severe it is described in affecting the usability of the software, and how much programmer time it is expected to take to solve it.
The bugs (and other tasks such as features) etc. are then assigned to programmers in the team based on things like familiarity with the parts of the software (often programmers mainly work with only one part of the programs they make), and the programmers work to fix them.
Typically the first step in fixing a bug is to reproduce it, so we know how to tell that it has been correctly fixed, and so we can inspect the program while it runs to figure out why the bug happens. The programmer may try to follow the steps that the user described in order to reproduce the bug, or they may use their knowledge of how the program works to infer different ways of reproducing the bug. If they cannot reproduce the bug, they may decide not to fix it, or send questions back to the customer to get more info on how to reproduce it.
In order to understand how the bug happens, they may read the code to see if they can deduce the rules that caused the bug. They may also run the program in a step-by-step manner, seeing how each variable affects each other. At times this can be difficult, for <complex reasons that I'd ideally explain but I'm on my phone right now so cutting it out for brevity>.
Once the bug has been understood, the programmer has to come up with a fix. Sometimes fixes a simple, e.g. changing the code to eliminate a silly programmer mistake. Other times the bug originates inevitably from other logic, and one has to break that other logic to fix it. The bug can also occur due to missing code, e.g. maybe only a special case was handled in the past, but now a more general case should be handled.
The fix must then be written into code, which involves a bunch of complex problem solving that I'm not even sure I know how to describe in non-technical terms. It's pretty important though so I should probably return to it after I'm off my phone. (Or if you feel like describing it, dear reader, I would encourage you to do so in a comment.)
Often programmers will also write a piece of code that can test the fix. This means that over time, the project can end up accumulating enormous numbers of automatic tests. And that's the next step: typically after a change is made, all the tests are run to ensure that nothing breaks.
Before the code is made a permanent part of the project, typically other programmers on the team will look at it and give comments on how to make it easier for them to understand, how to make it faster, and so on, such that the final code is reasonably good.
While doing all of these things, programmers typically have to manage a lot of technical things. For example, if the programmer is working on a web app, then the web app is typically run by multiple programs that work together. In order to run the app to e.g. reproduce a bug, the programmer may therefore need to configure the different pieces so they know how to find each other. Often configuration is partly handled by automatic tools, but these tools are often buggy and the programmer has to know how to navigate around those bugs.
This isn't a complete description of what programmers do, rather it is a description of one slice of programmer work (solving bugs).
IDK if it's historically true, but I've read that the origin of coinage was to make it possible for governments to automate the provisioning of their armies. Instead of directly controlling it all, you mint coins, give them to soldiers, tell the soldiers what they're responsible for, and make a law that every citizen has to pay a certain amount of those coins in taxes each year. Directly or indirectly, everyone has to do something to benefit the soldiers in order to get those coins.