The goal of cooking meals is to have a meal at the end. Because people need to eat. The food is the solution to the problem you have.
People don't consume software, slurping up lines of code like ramen. Having a steaming bowl of software is not the end goal. The end goal is to solve some _other_ problem which may or may not, once you dig into it, require writing software, and if it does then still: more software doesn't mean more food.
Most of us get paid to write software other people have requested in order to solve their problems. Every problem software solves can be solved by a sea of pencil pushers or factory line workers or human calculators or office clerks with filing cabinets or telephone switchboard operators or typists. The world used to run that way.
It no longer does because it is extremely cheap to program a computer to do repetitive actions. Compared to previous real-estate and labor-pool costs, paying even a thousand programmers to automate work done by people is incredibly inexpensive.
The problem is already solved. Your job is to translate the solution into a well-specified, easy to manipulate series of steps for a computer to execute that can be operated in production as cheaply as possible. You are literally the last step in the race to the bottom. You are literally payed to solve the problems of translating flexible human activities into code. That's the problem you are solving.
If someone asks you to program something that they don't already know how to do, then you are solving three problems - what to do, how to do it, and whether or not it is cheaper to do in software, which it ALMOST ALWAYS IS. You should be being paid three salaries - one as a business executive, one as a business analyst, and one as a software engineer.
The people pushing you to "solve problems, not code," are people pushing you to do more work in one job role to keep them from paying three people for those jobs. As a software engineer, you should be able to assume by the time something hits your task queue that others have decided that it will be cheaper to use software to solve the problem, they were competent in that assessment, and you can start executing.
As a consultant, I frequently take on all those roles for a client. But they pay me as a consultant to do those three roles. Remember that as an employee, in an extremely in-demand field, with specialized expertise compared to the rest of the work pool, you are a sole proprietorship trading time for resources. If that trade is lopsided, you need to push back and negotiate higher pay and a promotion. Don't give away work responsibilities for free because of culture hero points.
OK then, I think the confusion is that your experience (and definition) of software development doesn't align with mine.
> You should be being paid three salaries - one as a business executive, one as a business analyst, and one as a software engineer. ... Don't give away work responsibilities for free because of culture hero points.
I don't know what culture hero points are. Anyway, while I agree those are three different roles, I don't think because the "BA" role exists the "Soft Dev" role should just ignore req gathering and demand a fully completely spec that they then in no way question: that feels like waterfall from the 2000s. In the same way I think that a BA should understand how software works to a point and use that knowledge to direct their design, a software dev should understand the problem and design and contribute to that solution. The roles are not rigid black and white barriers where you throw things over the wall to the next person, they are just places where you concentrate.
I know what you mean, but this is the wrongest thing I've seen in quite a while!
Because it ignores performance.
Try implementing a video game with human clerks.
Pinball is certainly a precursor to video games; there's other low-impact games of manual dexterity like ring toss/bocce/..., darts/target shooting. Choose your own adventure books/pencil and paper role-playing/wargames obviously predate computer gaming -- the computer just runs a timer maybe and acts as the gamemaster.
People have been playing various forms of puzzle solitaire with cards for years; Bejewelled or whatever could be done with a custom deck. Minesweeper is not different in kind from the old logic game Mastermind. Even something like Tetris seems new, but I think is similar fundamentally to a tabletop game like Boggle: randomized input + a timer to find solutions -- the geometrical nature of Tetris is kinda just an implementation detail.
But I would venture that the number of problems that are only quantitatively different -- i.e., faster -- because of computers utterly dwarfs the number that are qualitatively different, or even impossible without them.
"Reality is the only place you can get a decent meal."
Video games are simulators of things in real life that are taken to extremes because death in the real world is permanent. They do impossible things - like fight aliens - but you can definitely fight using weapons (even airsoft or nerfed counts) in contrived situations in the real world. Imagine a cast of actors and you fight them with an airsoft rifle. No computer needed.
The goal of making applications is to have a piece of software at the end. That piece of software is the solution to the problem you have.
Actually, in that very sentence of yours you explicitly repeated what I already wrote
what even is gaming