[stackghost]

>Business objectives should override engineering policies when the two are in conflict, at least if you're a business owner who wants to make money.

This bush league kind of attitude is why people insinuate that most software development is not "real engineering".

When Boeing or NASA lets making money get in the way of good engineering practice, people die.

[mooreds]

> most software development is not "real engineering".

Most software development doesn't have anywhere near the real world impact of the Boeing/NASA engineering you reference.

Good engineering practice recognizes the risks and scales the effort to match it.

A CRUD app for internal users has a different set of requirements than a revenue generating SaaS app, just like a backyard fence has different building criteria than a highway bridge.

[stackghost]

Sure, I understand the stakes are lower for blog plugins than for aircraft.

But being a professional means you do the thing even when the stakes are low. You don't decide to cut corners because you feel like it, or because it's more profitable. Mullenweg is not professional.

[kelnos]

That's not what being a professional means at all.

You adjust your approach depending on the stakes. That shouldn't be a controversial take.

You're using "cutting corners" as a pejorative, but ultimately if the stakes are low, you may -- perfectly reasonably -- decide to allocate less time/resources to particular activities, and more to others. You can call that "cutting corners", and you'd be right, but there's nothing necessarily wrong about that: it depends on the circumstances. And there's certainly nothing "unprofessional" about it.

For the mostly-vibe-coded script to reencode a bunch of my own video files to save disk space, I skimmed the result to make sure that it wasn't going to overwrite or delete anything it shouldn't. Cutting corners? Absolutely. Perfectly fine and sufficient? Absolutely.

For the software that I write that I intend to distribute to others, that could cause data loss or other unpleasant problems for them if I get it wrong, I write the code myself, I understand how it works, and I might write tests and/or get someone else to review it, depending on my own judgment of what needs to be done.

Recognizing the difference between the the situations in the prior two paragraphs is what it means to be a professional.

[stackghost]

>You adjust your approach depending on the stakes. That shouldn't be a controversial take.

At no time have I suggested that one cannot adjust one's approach. That's a straw man you invented.

I'm refuting the point that business considerations should always trump engineering considerations because profit.

[kstrauser]

Sure, but in this case, the engineering consideration was whether a specific plugin should be added to the list of other suggested plugins. It was literally just a business decision of whether to configure it to be one of the featured options users might want to install.

[tomnipotent]

What does cutting corners have anything to do with the topic at hand? The situation isn't about devs getting the time to do something right, it's about programmers making a non-engineering decision that was overruled by the business in the businesses best interest. That's perfectly reasonable.

[asdfasgasdgasdg]

> But being a professional means you do the thing even when the stakes are low.

Not the way I understand "being a professional." All engineering, and all professions, entail the balancing of interests. There are some hard and fast rules*, like "don't do things that will kill your users." And there are some other things that are more guidelines than absolutes, such as "we don't ship feature changes in release candidates." Serious organizations understand that sometimes guidelines like the latter need to be violated for overriding business purposes.

*Even the "don't kill your users" thing is not an absolute. No car is perfectly safe, for example. We could add three more feet of crumple zone to the front and the back, but we don't, because even in safety tradeoffs have to be considered.

[zephen]

> But being a professional means you do the thing even when the stakes are low.

Being a professional means that you adjust what things you do according to the stakes.

For example, in software dev, you usually have tests for the code. Do you have tests for the tests? No? Why not? Why aren't you doing "the thing?"

In chip development, I usually had tests for the tests, because the stakes were higher. But I didn't usually have tests for the tests for the tests.

[brobinson]

"died in a blogging accident"

[zephen]

Although humorous, this also leads to a provocatively interesting line of thought which is completely tangential to the engineering discussion.

Blogging accidents, usually involving tik-tok videos, selfie sticks, and rugged terrain or wild predators, get all the attention, but probably pale in comparison to medical or mental health issues faced by the average blogger.

For comparison, studies of police officers in the US have found that heart disease, cancer, and suicide are the leading causes of deaths.

[brobinson]

It was a reference to this: https://xkcd.com/369/

[balamatom]

RIP American democracy, we hardly knew ye.