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 - "regressions"
-
A repressed memory just popped into my head:
At my former job I tried to explain a problem I was having to the tech lead. Then, without fully understanding the problem, he decided to rewrite my code that I had been working on for weeks. His code, that took him 2 days to write, went straight to master without peer review.
He introduced about 10 regressions…
Queue the client meeting where the client says “These bugs came back, and we thought they were fixed already…” (They demo the bugs)
So obviously I say “I’ll let Techlead address that one.”
He just mumbles some stuff, and goes quiet for the rest of the meeting. Finally, when the meeting was wrapping up we hear “It’s Fixed!”
Everyone was like ???
“That bug from earlier, it’s fixed, it should work now….”
Would you believe this guy decided to code during the entire meeting, clearly missing important feedback and information that would help him understand the problem. Again, pushing to master without review….
Not to mention that we were talking about 10 regressions…6 -
During a company wide status meeting where all product managers, architects and directors assemble:
Me: *A product architect leading a team of devs*
Directors: So are there any issues or risks you see in delivering the next build in target time for Client 1?
Me: There are too many changes in feature requirements. First they said we can use a shared NFS for storage. Now they are asking to switch over to SFTP pull mode.. blah blah..
Directors: Oh I see.. well we can support both solutions then.
Me: But the deadlin..
Directors: *ignores what I say* Will be a good marketing point for future.
Me: But there are too many regressions in integra..
Directors: *ignores what I say* We should also meet deadlines. That is the most important thing.
Me: Its not as easy as 1+1=2.. The team needs more time to..
Directors: *ignores what I say* Ok lets move on to the next point. What about Client 2?
Me:4 -
"LeT's uSe gRaPhQL!" They said.
"It EliMinAtEs cOmpLeX aNd vErBoSe REST coDe!" they said.
Me sitting here for hours waiting for the backend team to fix major regressions every time they push the smallest "updates" to staging... 🤡
Call me a boomer but I can't help but feeling graphQL makes things MORE complex than REST... either that or the backend devs have no idea what they are doing17 -
Days since last issue from 3rd party library: 0
It doesn't get any better than this folks!
It just makes me even more joyful to know that said companies library earns them 1000x figures of what my company earns! Yay software! -
Product manager: When building new features, we find we have bugs that reappear in other parts of the app where the bug was solved before. We have to find a solution to this issue.
Dev: These are called regressions, they happen all the time in software development.
Product manager: ...
Dev: Fuck outta here! Its friday!3 -
In most businesses, self-proclaimed full-stack teams are usually more back-end leaning as historically the need to use JS more extensively has imposed itself on back-end-only teams (that used to handle some basic HTML/CSS/JS/bootstrap on the side). This is something I witnessed over the years in 4 projects.
Back-end developers looking for a good JS framework will inevitably land on the triad of Vue, React and Angular, elegant solutions for SPA's. These frameworks are way more permissive than traditional back-end MVC frameworks (Dotnet core, Symfony, Spring boot), meaning it is easy to get something that looks like it's working even when it is not "right" (=idiomatic, unit-testable, maintainable).
They then use components as if they were simple HTML elements injecting the initial state via attributes (props), skip event handling and immediately add state store libraries (Vuex, Redux). They aren't aware that updating a single prop in an object with 1000 keys passed as prop will be nefarious for rendering performance. They also read something about SSR and immediately add Next.js or Nuxt.js, a custom Node express.js proxy and npm install a ton of "ecosystem" modules like webpack loaders that will become abandonware in a year.
After 6 months you get: 3 basic forms with a few fields, regressions, 2MB of JS, missing basic a11y, unmaintainable translation files & business logic scattered across components, an "outdated" stack that logs 20 deprecation notices on npm install, a component library that is hard to unit-test, validate and update, completely vendor-& version locked in and hundreds of thousands of wasted dollars.
I empathize with the back-end devs: JS frameworks should not brand themselves as "simple" or "one-size-fits-all" solutions. They should not treat their audience as if it were fully aware and able to use concepts of composition, immutability, and custom "hooks" paired with the quirks of JS, and especially WHEN they are a good fit.