You’re not writing code, you’re solving problems

And I get that. I have hobby projects because it's nice just to go wild and code for my own entertainment. My home lighting system is a custom Scala actor-model daemon, because 5 years ago I thought Scala was cool. (In retrospect: nope!) Building things is fun.

But when I'm on the clock, I've learned to be relentless in understanding actual users and their needs, and ruthless in pruning back the many things I'd like to build down to what actually serves people.

That's not easy even in the best of cases. And in companies that have waterfall-ish leanings or command-and-control managers, it's often impossible. So a lot of programmers learn to build whatever they're told, regardless of whether it solves a problem. And a good chunk will do it in ways that entertain them, because when managers drain all meaning out of a job, we are forced to find ways to create some for ourselves.

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.

I mean, think of all the mediocre, industrial-grade food you've eaten over the years. School lunches, maybe. Low-grade franchise food. Whatever's in the vending machine. How many people involved in making that are focused on the experience of the person eating the food? As opposed to maximizing revenue, or just doing whatever the manager says, keeping their head down, and getting out at quitting time?

Or let's think of all the food we've eaten that was made to please the cook, not the eater. A friend has an aunt that every year sends a giant box of absolutely terrible Christmas cookies. They're like iced cardboard. The important thing to the aunt is feeling like a big giver, not the experience of the eater. Or on the other end, consider fancy chefs who make tell-me-I'm-clever food, where the presentation is dramatic, but the actual taste is not so great.

Every time I cook for others, I see it as an opportunity to really see the person, to find the best intersection between my skills versus their desires and needs. And it's the same for software.