Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Search - "guardrails"
-
1. Move to new house
2. Setup electricity account to auto-pay every month
3. Wait
4. Receive "disconnect" notice from electric provder
5. WTF
6. Call. Oh, yeah, our website doesn't tell you that you have to pay your first month's bill before you can setup auto-pay. It's in the fine print.
Okay people, here's my rant - if you manage a website that supports auto-pay and you're not PREVENTING your customers from signing up for auto-pay until there is a $0 balance in the account, then you're doing something wrong. Don't let your customers think they're about to loose their electric service because of a frontend guardrails issue.7 -
A manager, a mechanical engineer, and software analyst are driving back from convention through the mountains. Suddenly, as they crest a hill, the brakes on the car go out and they fly careening down the mountain. After scraping against numerous guardrails, they come to a stop in the ditch. Everyone gets out of the car to assess the damage.
The manager says, "Let's form a group to collaborate ideas on how we can solve this issue."
The mechanical engineer suggests, "We should disassemble the car and analyze each part for failure."
The software analyst says, "Let's push it back up the hill and see if it does it again."1 -
I think I just realized what my biggest gripe about our career paths that I hate the most.
This is something that has worsened over time, especially the last 2 to 3 years.
As developers, we have far too many options. Some of the most powerful apps are written with languages that have hard, and I mean HARD, guardrails in place. If the app is written in a language that does not meet this criteria usually a framework has been used to install those guardrails.
We just get our minds so wrapped around the possibilities and the opportunities in the software, that we just can't focus on the end result. We're like puppies that are excited about something and we just piss all over everything.
In my career I have met far too many developers that don't have the capacity and mental fortitude to take control of their actions. Because of this I think the only way for us to stop this corruption, that I feel we are nurturing, the solutions/services that we use need to push back on us and install those guardrails for us.
All this came from a change that Microsoft put in place that seems well intended, but introduces yet another choice and a multitude of opinions in how you release code.
It used to be a simple check box. If it was checked it was pre-release, if it was unchecked it was a production release. That's it. On or off. The simplest choice you ever needed to make on a release.
Now though, there are two check boxes. One for a pre-release and one for a latest release. You can also not check either for some "ephemeral" release? So now something as easy as on or off has been made into a difficult decision on how this works within my pipeline. Now every time I make a release I have to ask myself, "which one do I check?"
I shouldn't need to spend more than a second to identify a path forward on simple shit like this, but here we are with a third choice.
Can we just stop overcomplicating shit?6