To solve problems. Coding is the means to an end, not the end itself.
> careful configuration of our editor, tinkering with dot files, and dev environments
That may be fun for you, but it doesn’t add value. It’s accidental complexity that I am happy to delegate.
You can also solve problems as a local handyman but that doesn’t pad the 401K quite as well as a career in software.
I feel like there’s a lot of tech-fetishist right now on the “if you don’t deeply love to write code then just leave!” train without somehow realizing that most of us have our jobs because we need to pay bills, not because it’s our burning passion.
I would claim that I love coding quite a lot. The problem is rather that my bosses and colleagues don't care about what I love about it. It is rather appreciated if you implement tasks fast with shitty code instead of considering the fact that tasks are easy to implement and the code is really fast as a strong evidence that the abstractions were well-chosen.
Thus, I believe that people who just do it for the money have it easier in the "programming industry" than programmers who really love programming, and are thus a big annoyance to managers.
I thus really wonder myself why companies tell all the time about "love for programming" instead of "love for paying the bills" and "love for implementing tasks fast with shitty code", which would give them people who are a much better culture fit for their real organizational processes.
If I order something to be delivered, I don't care what model of car the delivery company uses. Much less what kind of settings they have for the carburetor needles or what kind of oil they're using. Sure, somebody somewhere might have to care about this.
That's also how people like me see programming. If the code delivers what we need, then great. Leave it be like that. There are more interesting problems to solve, no need to mess with a solution which is working well.
People that realize this care about their oil type and what tire they put on. People that do not, pay it forward when that crash does happen and they don't know how to recover, so queue up the war room, etc...
Even if you're not dogfooding your own software, if you do not take care of it properly, the cost of changes will climb up.
How do you mean? If the software works, then it's done. There is no maintenance and it will continue working like that for decades. It doesn't have corrosion and moving parts like a car. Businesses make sure not to touch it or the systems it is depending on.
Then there’s the fact that the user’s needs fluctuate. Imagine having to pay for a whole another software because the current code is spaghetti and full of hardcoded value and magic constants. It worked, but now you want a slight adjustment, but that can’t no longer be made unless you’re willing to rewrite the whole thing (and pay for it). That would be like having to buy a whole new car, because you moved to the house next door, as the car is hardwired to move only between your old place and where you work.
Sure, if you test it and see that there is no issue with updating, then you can update if you want. But neither the OS or the hardware or anything else should get any priority over the business-crucial software you are running. Even with hardware failures, the better option is to get older hardware for replacement if newer hardware has compatibility issues.
Now, you might argue that it doesn't matter because it's not the users who pay you, it's the company. But, well - some people have professional standards. It's rather unfortunate that this is apparently not compatible with "doing business" in this day and age, at least outside of very narrow niches.