At the risk of just jumping on a single point:

> I build things for people to use and maintain.

Maintenance. Maintenance. Maintenance. That's the key. It is the lack of that mindset which is killing our home world. Ultimately, it's just expression of not having to pay for your externalities.

It also kills software dev. If software devs were actually held to account for their legacy (software, hah), then we'd have a lot less shitty (and shitty+, shitty++, etc) software.

In context of this, I've always been thinking that software engineers should be held way more liable -- like those of the physical engineering disciplines. In order to enforce good software engineering practice, there must be either incentives or disincentives (carrot or stick) that have clear consequences on the engineer himself/herself. Otherwise there is nothing stopping them from producing bad work. It may be unintentional and the code perhaps is simply sloppy (but still works).

This is just a thought (and may be unpopular): practices differ wildly from one company to another, and between enterprise software vs hacky side-projecty node apps, nonetheless, maybe it's time to standardize software good practices across the entire industry and enforce them, making them not just "good" practice, but mandatory practice.

If you create liability traps, the price of everything goes up and many things do not get made at all.

It's like saying that tents shouldn't exist and people shouldn't use bicycles even though they are great tools for certain jobs.

Nobody wants to pay for space shuttle levels of software engineering. It costs a lot in labor time to produce less results.

The cost of bugs varies wildly. I do not want my FADEC to have the bugs my word processor has but I do want the word processor to have more features.

What is the deal with maintenance engineers thinking every engineer ought to be one? Can't you agree it takes all types or is there something about maintenance that preempts such thoughts?

Edit: Maybe I should go around pretending hackers and poets have the moral high ground.

I think it's contempt for people who won't stand by their work. Maintenance engineer implies a very long term relationship with code but you can't get some self-aggrandizing butterflies to support something they wrote a month ago. The truth should be somewhere in between.

When you're young it's easy to derail your complaints by implying you are not smart enough to appreciate the magnificence of the code. I tend to take Feynman's position that if you're really so great, your solutions will be obvious.

There is certainly room for art in our world.

I'm just saying that what companies sell as products should not be made in the "art" mindset. Is that clearer?

hard agree.

I remember once coming across a 3rd party web API whose documentation stated you could configure something like 50+ settings with it. Only about half of them actually changed the configuration, the other half I had to actively go in and start doing things like shutting down the service, updating various files, and then restarting.

When I realized this I just thought to myself, how in the world does your pride as a developer even ALLOW you to ship something that bad.

Another example is PoSH (Powershell SSH). The author just randomly changed how he does things, and changed the defaults, so one day things that worked before just stopped. You now had to configure it to have the old behavior. WHY!?!

Then I realized that if you issue a shutdown command over SSH via PoSH it would hang until the timeout was hit. I then found myself maintaining a custom version of PoSH to work around the issue. I even went as far as to describe the issue, and my fix, for the author, but to this day I don't think they ever actually fixed it. The day when we can natively use SSH from powershell can't come fast enough.

The point being that things are always so damned brittle. And the worst part is that I don't think it gets better the lower down the stack you get. I've ran into plenty of these types of issues in C and C++, it's a mindset and it drives me nuts.

Openssh server and client are included in windows 10 as an optional feature for a while already.

If you don't watch your users struggling with your product then you can tell yourself all sorts of delicious lies about how awesome you are.

If you have no empathy then you can watch them and dismiss it as user stupidity. Which is never an attractive look.

>I am a maker. I build things for people to use and maintain.

So you're dev ops?

Jokes aside, do you really have a passion for maintaining projects? This is something I deeply struggle with and any advice on the subject I would be deeply grateful for.

I thought I could deal with it and enjoy a project in the long run if it had no bugs, so I worked on some of the code the internet runs on, where even putting in one bug would make parts of the internet go down world wide. (Which I did do btw. Sorry.) I both hated and loved that job, but in the end, even in a "bug free" code base, so maintaining it was only feature requests for the most part, I still lost passion over time.

I switched to Data Science, writing code I know will be scrapped. I write mockups to analyze data. It's a lot of fun! But to me it's just running away from the issue.

How did you gain passion for maintaining code bases? If you have a story, it would mean a lot to me. I'd love to hear it.

You don't need passion for maintaining projects to have compassion for the people who need to maintain your projects (whether or not that's also you).

As you point out, though, some code actually doesn't require maintenance. But at the same time, that's not always the code you think.

> do you really have a passion for maintaining projects?

I don't. I have a passion for clearing roadblocks and that means different things at different times. Sometimes that means automation.

I think you parsed that sentence in a different way than I intended. I think a legitimate handoff is part of building a tool for someone. We have people who run the gamut from rent-seeking to dropping the mic and walking away.

I did interpret incorrectly. Thanks for the clarification.