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).
I’m not sure I understand how this relates to your original question. Everyone’s job exists at some level because they have a comparative advantage doing it, and specializing in it, compared to other people doing it for themselves. Even doctors have doctors and lawyers have lawyers.
I’m a consultant with a background in physics and materials science. Companies set themselves goals: growth, emissions reduction, and improving sustainability are the ones I focus on most. They work with my employer so a neutral third party can explain to them the landscape of technological options, legal constraints, market and policy trends, and range of business models and plans available to achieve those goals. Often the relevant entities are well outside the company’s normal set of customers, suppliers, and competitors. Also, we can put them in touch with the right people once they choose how to proceed, and over time we put in the work forming and maintaining those connections so we’re well-placed to do this more efficiently than they can do themselves.
My job also includes telling people when they’re asking the wrong questions, and helping educate them and their company. In that capacity I provide an outside view, and try to find and point out what are to them the unknown unknowns. “Humans are not automatically strategic” is a rough approximation of why my job exists.
I’m not sure I understand how this relates to your original question. Everyone’s job exists at some level because they have a comparative advantage doing it, and specializing in it, compared to other people doing it for themselves. Even doctors have doctors and lawyers have lawyers.
Programmers are part of the economy and this was an explanation of some things programmers do, so by transitivity it is a partial explanation of what the economy does?
My original question was not “why do economic transactions exist, rather than everyone just doing what they personally need?”. It was “what does the economy do?”, i.e. which activities are executed within the economy?
Then in that case, the focus on job activities is way too narrow. The answer to “which activities are executed within the economy?” is roughly “all of them, except those things which literally can’t be bought and sold, even on the black market.” And that is a very small and shrinking set. Every choice to do something for myself is also a choice not to hire someone else to do it, there’s no neutral opt-out decision, even if measures like GDP don’t accurately capture household production. Technically with modern medical technology I could even use money to outsource my breathing, eating, blood circulation, and blood filtration. Economics is a totalizing approach to explaining how we assign and distribute scarce resources across every choice we make.
So in that sense I’d say that “what the economy does” is provide options and incentivize people to take those options, in full generality.
The answer to “which activities are executed within the economy?” is roughly “all of them, except those things which literally can’t be bought and sold, even on the black market.”
Yes but I would like to have a conprehensive list of all activities people engage in. Rather than just abstracting it into “all of them”.
Sorry if that came off rude, it just seemed like a kind of question I would never expect anyone to ask. It’s not like there’s one ready-made somewhere, and it’s not like anyone could type one out. No matter how many examples anyone gives you, you’ll still be missing almost all of them and need the abstractions anyway. And if you have internet access and have lived a reasonable number of years as a human, you already have a sufficient basis to know that, and also to build on without such a list.
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).
I’m not sure I understand how this relates to your original question. Everyone’s job exists at some level because they have a comparative advantage doing it, and specializing in it, compared to other people doing it for themselves. Even doctors have doctors and lawyers have lawyers.
I’m a consultant with a background in physics and materials science. Companies set themselves goals: growth, emissions reduction, and improving sustainability are the ones I focus on most. They work with my employer so a neutral third party can explain to them the landscape of technological options, legal constraints, market and policy trends, and range of business models and plans available to achieve those goals. Often the relevant entities are well outside the company’s normal set of customers, suppliers, and competitors. Also, we can put them in touch with the right people once they choose how to proceed, and over time we put in the work forming and maintaining those connections so we’re well-placed to do this more efficiently than they can do themselves.
My job also includes telling people when they’re asking the wrong questions, and helping educate them and their company. In that capacity I provide an outside view, and try to find and point out what are to them the unknown unknowns. “Humans are not automatically strategic” is a rough approximation of why my job exists.
Programmers are part of the economy and this was an explanation of some things programmers do, so by transitivity it is a partial explanation of what the economy does?
My original question was not “why do economic transactions exist, rather than everyone just doing what they personally need?”. It was “what does the economy do?”, i.e. which activities are executed within the economy?
Then in that case, the focus on job activities is way too narrow. The answer to “which activities are executed within the economy?” is roughly “all of them, except those things which literally can’t be bought and sold, even on the black market.” And that is a very small and shrinking set. Every choice to do something for myself is also a choice not to hire someone else to do it, there’s no neutral opt-out decision, even if measures like GDP don’t accurately capture household production. Technically with modern medical technology I could even use money to outsource my breathing, eating, blood circulation, and blood filtration. Economics is a totalizing approach to explaining how we assign and distribute scarce resources across every choice we make.
So in that sense I’d say that “what the economy does” is provide options and incentivize people to take those options, in full generality.
Yes but I would like to have a conprehensive list of all activities people engage in. Rather than just abstracting it into “all of them”.
I’m starting to think I’m talking to an AI and not a human.
Why?
Sorry if that came off rude, it just seemed like a kind of question I would never expect anyone to ask. It’s not like there’s one ready-made somewhere, and it’s not like anyone could type one out. No matter how many examples anyone gives you, you’ll still be missing almost all of them and need the abstractions anyway. And if you have internet access and have lived a reasonable number of years as a human, you already have a sufficient basis to know that, and also to build on without such a list.
Wait, wouldn’t such a list be extremely long?
In theory yes, but I don’t expect anyone to be able to create a full list, so I expect to only end up with a few items on it.