Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
Search - "pull requests"
Excerpts from "Bastard devops from hell" checklist:
- Insistently pronounce git with a soft "G" and refuse to understand people not using that pronunciation, the same goes for jithub, jitlab, jit lfs, jitkraken etc.
- Reject all pull requests not in haiku format, suggest the author needs to be more culturally open minded when offending.
- increment version numbers ONLY based on percentage code changed: Less than 1% patch increment, less than 5% minor increment, more than that major version increment.
- Cycle ALL access keys, personal tokens, connection strings etc. every month "for security reasons"
- invent and only allow usage of your own CI/CD language, for maximum reuse of course. Resist any changes to it after first draft release23
Repositories with 1k+ issues and / or 50+ pull requests are basically lost causes I would think..
1. Hard to recover properly
2. The same people that let it come to that point won't be the ones to be able to recover it in the first place
'lost cause' as in the project will just slowly because worse and worse in most ways, not that it's outright useless / non-functioning / ..
Does anyone have a counter-example of such a project that did recover?
In regards to h3rp1d3v's rant
“We mob every thing so that means we don’t need pull requests, because by the time the code is committed it’s had plenty of pairs of eyes on it”
Well, I beg to differ.
Today I read through some of this spaghetti mobbed code to look into a performance issue. Wasn’t supposed to but bored stiff so I ‘went dark’ and did it without the mob.
After about an hour I figured out it runs a few lines of dubious code and if there’s an error it tries many times over with an exponential back off.
And each run of the methods will fail for sure because of how it’s written.
Someone must’ve seen this problem but instead of realising it can never work, they’ve wrapped it in retries and back offs.
So many back offs and retries that it just sits there doing this for 25 minutes.
But yeah. The mobbing works great guys, keep churning out this quality code. 😂😂😂
Can’t wait to see the back of this joke job.4
I took a job with a software company to manage their product, which was a SaaS property maintenance system for real estate, social housing, etc.
There was no charge to real estate agents to use it but maintenance contractors had to use credits to take a job, which they pre-purchased. They recharged their credit costs back to the real estate agent on their invoice).
Whether this pricing model is good or not, that's what it was. So, in I came, and one of the first things management wanted me to deal with was a long-standing problem where nobody in the company ever considered a contractor's credits could go into the negative. That is, they bought some credits once, then kept taking jobs (and getting the real estate agent to pay for the credits), and went into negative credits, never paying another cent to this software company.
So, I worked with product and sales and finance and the developers to create a series of stories to help get contractors' back into positive credits with some incentives, and most certainly preventing anyone getting negative again.
The code was all tested, all was good, and this was the whole sprint. We released it ...
... and then suddenly real estate agents were complaining reminders to inspect properties were being missed and all sorts of other date-related events were screwed up.
I couldn't understand how this happened. I spoke with the software manager and he said he added a couple of other pieces of code into the release.
In particular, the year prior someone complained a date on a report was too squished and suggested a two-digit year be used. Some atrocious software developer worked on it who, quite seriously, didn't simply change the formatting of that one report. No, he modified the code everywhere to literally store two-digit years in the database. This code sat unreleased for a year and then .... for no perceivable reason, the moron software manager decided he'd throw it into this sprint without telling me or anybody else, or without it being tested.
I told him to rollback but he said he'd already had developers fixing the problems as they came up. He seemed to be confident they'd sort it out soon.
Yet, as the day went on more and more issues arose. I spoke to him with the rest of the management team and said we need to revert the code but he said they couldn't because they hadn't been making pull requests that were exclusive to specific tickets but instead contained lots of work all in one. He didn't think they could detangle it and said the only way to fix was "play whack-a-mole" when issues came up.
I only stayed in that company for three months; there was simply way too much shit to fix and to this day I still have no idea the reasoning that went on in the head of anyone involved with that piece of code.2
Something I hate about working in the team is that the code reviewer will stall the time and leave a lot of pull requests unreviewed. As more code changes more commits and more pull requests.
The code base is conflicting with each other, what the fuck? I hate this.6
My manager says you shouldn't be doing archaeology work looking at old pull requests and git diffs to figure out how things work.
Are there scenarios when this is useful? How common are they in your day to day?5
Writing my first code review. Even though it really is a nice review and I'm happy with the solution code, I still somehow feel like an asshole for each critique I make. Maybe it's unavoidable with code reviews / pull requests?3
It's funny when you MUST create two pull requests (from feature to ART main and from ART main to dev) also if the feature is just one because you need to respect the shitty flow.
#Suphle Rant 4: Laravel closing the gap II
I had expected rant 4 to come at least, some days later. Apparently, I'd miscalculated how fast things work in this wonderful world of software. In an earlier rant, I wrote about how dismayed I was to learn laravel had implemented one suphle feature I'm very proud about. They call it Premonition. Idk if it's officially rolled out yet but you can do a search among accepted pull requests for what it's all about
Well, today, I've just seen a draft from one of their maintainers showing one of the things suphle was designed to do: https://twitter.com/enunomaduro/.... They can't integrate it with this pattern since php doesn't have generics, so it'll either get trashed or with plastered as some band aid. In suphle docs, I explicitly indicated the data structure/typing for that feature is a polyfill for the absence of generics
I think I can get away with it because of where I'm using it (model authorization instead of custom exceptions/throwable operations, in general, like theirs)
I don't feel as distraught as I did on finding the Premonition thingy. Am I impressed with these things dawning on them? Ffs Laravel was invented in 2011. It's incredulous to think it gave me hell for years. Waited ~2 years for me to fix all issues in a brand new framework, only to magically gain iq points and start improving their work
It's weird and brutal. If they keep figuring stuff out, it may not be long before there are no features unique to suphle. Then, my worst nightmares will come to life. I will argue there's one thing nobody will ever copy, not without rethinking the mvc architecture in its entirety.2