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 - "rigid code"
-
'Hey I found a bug in your code, it's probably a typo, see here.'
Me: Oh right, yeah. How stupid of me. Thanks, I'll push it.
'It's okay. You can push it or I can do it too after you push the changes we just discussed. I actually simplified one of your methods.'
Me: You, what... ?
(You crammed multiple lines in a single line with your stupid as fuck, rigid constructs, removing my error handling, loosely coupled service, in the name of simplification?)
' Yeah it's just four lines in a single function now, no need to call the function again and again.'
Me: (No... Just no. This totally undos whatever little I could do to avoid supporting your idiotic object in the first place.)
Oh... okay, we'll see. I'll let you know.
What life.
Life in a company full of ignorant, inflated egos is no joke.
Details:
I created a service that reads a configuration file and returns the configuration. This person needs five entries for his app logic. He collected them in a object. Quite alright. Except that the class prototype is shitty. I, like a normal person, made my service return a value based on input. I was asked to incorporate this awful object so that I can return the five entries together, which is awful because the service is not supposed to know about how the entries are clubbed. It should most certainly not know about the data members of the object!4 -
Drupal makes me want to go back to the moment that life first crawled out of the ocean, and shoot that first land-dwelling organism in the head – just to make sure that the animal kingdom never evolves to the point where a crime as ghastly as Drupal can occur.
Drupal somehow manages to be both unforgivingly, bureaucratically rigid, and an anarchic, spaghetti-coded mess – at the same time. Other frameworks are toolboxes. Drupal is a series of windows at the IRS or MVA – and it *will* take you days to figure out which series of forms you have to submit, with which boxes checked, in order to accomplish your goal.
The documentation is complete and utter trash.
It models content in a way that makes all sorts of assumptions about your use case. And those assumptions don't have anything to do with *how websites are actually designed and built*. In 20 years of building websites, I've never *once* wanted to use anything resembling the bizarre data model that Drupal *forces* you to use. Nor have I ever thought "gee, I wish my platform forced me to stop writing code every 20 seconds, so I can use an atrociously designed point-and-click interface".
I ask the community how to accomplish [insert extremely fucking basic task here], and they say: "well, you just install these 17 modules, glue them together with a bunch of configuration that couples your database to your code, and then shrug at the hideously broken HTML/CSS that comes out, because we give exactly zero shits about UX! isn't it great how Drupal makes things so easy?" Like, no – literally *every other framework on the planet* allows you to accomplish the same thing with just a few lines of code.
Most of the community seems to have little or no experience with other frameworks – so they seem solipsistically unaware that these are even problems. If your platform has been stabbing you in the arm for as long as you've been building websites, then you're just gonna assume that being stabbed in the arm is part of developing websites, you know? They seem oblivious to the fact that things are *so much easier* when your platform just lets you build whatever abstractions you need, instead of forcing its own weird-ass, undocumented assumptions on you.
Uruururrrrrrrggghgh. I can't understand how anyone defends this piece of garbage. If you're a Drupal developer reading this – please, for the love of God, try learning another framework. Once you've spent a couple of weeks learning saner ways of doing things, you'll never look back. I cannot comprehend how Drupal is still a thing.4 -
How do I convince a dev department to take source control, peer code review and unit tests seriously?
I'm a recent software grad with internships that recently started at a smallish company (less than 20 employees but has been around for 10 years, with most senior non-mgmt employee around 6 years). I've been working here for less than a year (approx 5 months) and I love the company - lots of talented and passionate people.
We are a creative industry with a handful of devs and one of the issues I'm seeing is that often devs are working in silos. I'm trying to make suggestions to upper management like encourage more usage of source control, documentation, etc and most of the senior devs are pushing back - saying that they don't feel that it is necessary and due to the fast moving nature of our projects that all this would be a total waste (they were so fast on the idea of not having PR's because it would be "too much of a blocker").
I understand that a large part of this has more to do with shifting the culture in the department and that can be very hard to do, especially since i'm fresh out of school, but I see these devs have so much potential but it seems that they think having these implementations in place would mean more rigid rules and bureaucracy.
I've been speaking to some of my engineering friends and they're pretty much all just telling me that I am shooting myself in the foot if I continue to stay at this company because I'll be behind skill wise, but part of me isn't ready to just give up yet.
looking for some advice10 -
I was asked to make proof of concept small frontend app with some simplified requirements, they asked me because it should be written in the stack I done most of my career work with. I do it in 3 days instead of 5, using those 2 days to optimise the app and explore different approaches. I noted down my findings, what to avoid and reasons and also what is good to use and reasons and shared with everyone.
We waited for the project to start, I started working on another project in the meantime and there was a big rush to make project go live etc., so I was consumed 100% on that new project.
So they put in charge backend php developer to do frontend js work. I said ok, do you need help in starting out? Nah, my proof of concept repo is enough.
4 days before that small project goes live they asked me to do code review. All things I noted down to avoid are in the codebase, few bad practices but everything is over-engineered (in a very bad way), some parts should be more flexible as current setup is very rigid, having almost all kinds of CSS, I saw SASS, CSS variables, 2 different CSS-in-JS tools with some additional libraries that is used to toggle classes.
I don't know how to approach this as I am not asshole as a person and I don't want to say to my colleague that his codebase is completely trash, but it is.
The worst parts: They called me to help finish the app and budget is almost spent!
I would rewrite the whole app as the state of the current app is unusable and everything is glued with bad Chinese ducktape that barely holds.
Additional points because it won't bundle as everything is f**ked.
I am seriously thinking of duplicating master branch and refactor the whole fricking app but won't do that as I am burning midnight oil on other two projects. Don't worry overtimes are paid.
I hate those shitty situations, this project was supposed to be tiny, sweet and example of decent project in this company but it is instead big fat franken-app that will be example how smart it is to avoid putting backend dev to do frontend work (I also agree for vice versa)! -
The Coding Apocalypse: A Dev's Rant
June 14, 2024
Okay, gather ’round, fellow code warriors, because it’s time for a good ol' developer rant. If you're reading this, chances are you’ve already faced the dragon that is modern software development, and you’re somehow still using "Agile" as a life preserver while the ship is sinking. So let's dive into the chaos that our world has become.
Here’s the thing: We’re living in a paradox where every other day there's a shiny new framework promising to be the “ultimate solution” while ignoring that it's just recoil from the last big mess. I mean, can we talk about JavaScript for a second? I’m pretty sure if you stand still long enough, a new JavaScript framework will spontaneously generate from the void. Do we really need another one?
And don’t get me started on Sprint Planning. It’s like playing Tetris with stones while blindfolded, hoping that all the blocks land perfectly. Spoiler: They don’t. The product manager’s eyes glaze over as they nod approvingly to your estimates, secretly extending deadlines in their minds. The 'flexible' deadlines then become rigid, unattainable goals, and who gets the heat? The devs, of course.
Also, can we address the insanity of microservices? Sure, splitting a monolith into microservices sounds fun—until you’re drowning in API calls and Docker containers. Debugging a distributed system is like trying to untangle a pair of headphones made of spaghetti.
Oh, and if one more person asks if we’re "leveraging AI" and "blockchain technology" for our simple CRUD app, I might lose it. Sometimes, folks, the wheel doesn’t need reinventing. It just needs a little grease.
Finally, remote work. Blessing and curse. Sure, I enjoy the freedom of working in my PJs, but the endless Zoom calls are killing my soul. Breakout rooms? More like breakdown rooms. The Slack notifications? Let’s just say my sound settings have a hair trigger on mute these days.
So here’s to us, the devs. The ones who stare into the abyss of JIRA tickets and laugh in the face of mounting tech debt. May your coffee be strong, your code refactored, and your deployments ever in your favor.
End rant. Back to the trenches. 🚀💻6 -
My most recent workaround occurred last week.
We have a demo very soon and I had to change our iOS app to use a new Web API endpoint for uploading content.
Long story short: The existing code is so awful and rigid and dependant on Core Data that I ended up having to completely bypass the service layer of the app and implement the new endpoint as a raw HTTP request. Its gonna take a long time to refactor the existing service layer. All because the new endpoint has a different content type.