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 - "inversion of control"
-
I worked on a web project a few years ago. I've refactored a large part of the architecture, added repositories to the business layer, implemented inversion of control and dependency injection etc. (took me 2 weeks).
There was a second developer in the project... he didn't understand the design patterns and the whole IoC/DI thing. Instead of asking or reading about it, he reverted all the changes while I was 3 weeks on vacation -.-4 -
How do you deal with massively poorly-performing and unknowledgeable teams?
For background, I've been in my current position for ~7 months now.
A new manager joined recently and he's just floored at the reality of the team.
I mean, a large portion of my interview (and his) was the existing manager explicitly warning about how much of a dumpster fire everything is.
But still, nothing prepares you for it.
We're talking things like:
- Sequential integer user ids that are passable as query string args to anonymous endpoints, thus enabling you to view the data read by that view *for any* user.
- God-like lookup tables that all manner of pieces of data are shoved into as a catch-all
- A continued focus on unnecessary stored procedures despite us being a Linq shop
- Complete lack of awareness of SOLID principles
- Actual FUD around the simplest of things like interfaces, inversion of control, dependency injection (and the list goes on).
I've been elevated into this sort of quasi-senior position (in all but title - and salary), and I find myself having to navigate a daily struggle of trying to not have an absolute shit fit every time I have to dive into the depths of some of the code.
Compounded onto that is the knowledge that most of the team are on comparable salaries (within a couple thousand) of mine, purely owing to length of service.
We're talking salaries for mid-senior level devs, for people that at market rates would command no more (if even close) than a junior rate.
The problem is that I'm aware of how bad things are, but then somehow I'm constantly surprised and confronted with ever more insane levels of shitfuckery, and... I'm getting tired.
It's been 7 months, I love the job, I'm working in the charity sector and I love the fact that the things I'm working on are directly improving people's lives, rather than lining some fintech fatcat's pockets.
I guess this was more a rant than a question, and also long time no see...
So my question is this:
- How do you deal with this?
- How do you go on without just dying inside every single day?8 -
I quietly refactored an entire NodeJS express in-house framework that was written in Java style (dependency injection, inheritance, inversion of control) and split it into typed, composable, parameterized, testable middlewares in 2 weeks (including some complicated ones like a custom Openid Connect flow)
Now comes the hard part: convincing the Java-devs who wrote it that it is useful2 -
A quick rant about dependency injection.
I see far too often in projects, a huge over-reliance on dependency injection / IOC frameworks which permeate throughout the entire codebase.
I cringe every time I see a constructor annotated with @Inject and 10 params.
The benefit of these frameworks is how easy they make it to manage many dependencies. What I dislike about them, is exactly that. I feel that they make it TOO easy to manage many dependencies.
How trivial is it to simply add another constructor param? exactly. And people then wonder why their dependency tree looks insane.
I am a strong believer in injecting dependencies the traditional way, via the constructor with no fancy framework. The reason being that it forces you to think more about the dependencies you are adding to your classes, and consider if they are really all needed.
The other problem I have with it, is it basically encourages you to inject everything because its so easy. The purpose of dependency injection is inversion of control and allowing classes to depend on abstraction rather than concrete implementation. All that goes out the window when you @Inject 6 different concrete classes.
Use dependency injection for its intended purpose, not as an excuse to be lazy and avoid thinking about dependencies.3 -
A lot of this might be an assumption based on not enough research on both NestJS and TypeScript, so if something here is not well put or incorrect then please feel free to provide the necessary info to correct me since I care far more about getting dat booty than I do being right on the internet :D
Sooo, a year or so ago I got a hold on the Nest JS framework. A TypeScript based stack used to build microservices for node. Sounded good enough in terms of structure, it is based on the same format that Angular uses, so if you use Angular then the module system that the application has will make sense.
I attempted (last night) to play with the framework (which I normally don't since I am not that much of a big fan of frameworks and prefer a library based approach) and found a couple of things that weird me out about their selling points, mainly, how it deals with inversion of control.
My issue: This is dependency injection for people that don't really understand the concept of dependency injection. SOLID principles seem to be thrown out of the window completely due to how coupled with one another items are. Literally, you cannot change one dependency coming from one portion to the other(i.e a service into a controller) without changing all references to it, so if you were using a service specification for a particular database, and change the database, you would have to manually edit that very same service, or define another one....AND change the hardwire of the code from the providers section all the way into the controllers that use it....this was a short example, but you get the gist. This is more of a service locator type of deal than well....actual dependency injection. Oh, and the documentation uses classes rather than interfaces WHICH is where I started noticing that the whole intention of dependency injection was weird. Then I came to realize that TypeScript interfaces are meeheed out during transpilation.
Digging into the documentation I found about custom providers that could somehowemaybekinda work through. But in the end it requires far too much and items that well, they just don't feel as natural as if I was writing this in C# or Java, or PHP (actually where I use it the most)
I still think it is a framework worth learning, but I believe that this might be a bias of mine of deriving from the norm to which I was and have been used to doing the most.3 -
Note: I had AI rephrase this because apparently it was too full of swearing or smth to be accepted and I was getting a "there was an error posting this rant". Nice that people at devrant's can't even show a clear error of WTF is going on, not even in chrome dev tool console/network requests, so maybe you're able to figure out WTF is going on and fix your post. They must be the same kind of people I'm ranting about.
-----------End of the note.----------------
TL;DR;: My coworkers are smart idiots that learn fast but can't control themselves into turning any project into a trashcan of spaghetti code and I'm burning out and want to switch for couple years to a simpler job.
I'm considering leaving my career in programming, consulting, and project management in favor of a more straightforward, manual labor job—perhaps something like baking or another role that relies on physical effort rather than constant problem solving.
I’ve reached a point where I can no longer tolerate the challenges of my current position, especially due to the dynamics with my coworkers. I long for a day where I can work for eight hours, exhaust myself physically, and then go home without any lingering mental responsibilities or ties to complex problem solving.
Over the past decade, I’ve collaborated with many people, yet I've only had the opportunity to manage an entire project from scratch on my own twice. In those rare instances, everything ran smoothly, issues were quickly resolved, and the code remained stable for years without constant complaints from clients.
Unfortunately, my coworkers, despite their intelligence, tend to overcomplicate even simple tasks. They often fall into the trap of overengineering, chasing the latest technologies and implementing unnecessarily complex paradigms, design patterns, frameworks, and techniques—even when I’ve offered simpler, proven solutions.
For example, I’ve built robust portals that handle everything from national highway finances and warehousing to HR and inventory management for major companies. In contrast, when others attempt similar projects, the resulting code becomes overwhelmingly complex and difficult to manage.
To give a few specific examples:
Example 1: The .NET Portal
We began developing a .NET portal about two months ago, which is now nearing version 1.0. Before we even started, the team had created multiple flowcharts to split the project into components like SaaS deployment, Docker integration, obfuscation, and separate portals for user administration and backend processes. Within a few weeks, they scrutinized and debated numerous authentication technologies—even though we had successfully implemented JWT token solutions in the past. The team continually shifts focus, leaving me uncertain about the final direction.
Example 2: Over-Engineering with Patterns
In another project, the team overused inversion of control (IoC) and mediation patterns, even going so far as to have an AI generate a custom message bus. Navigating this overly decoupled code is challenging; even Visual Studio’s IntelliSense struggles to provide guidance, and the code often feels like a puzzle that changes whenever I return from a break.
Example 3: Complicated Logging Implementation
We needed to add logging functionality, and I proposed a simple solution using custom exceptions that would bubble up to a central logging mechanism. Despite its past success in saving time and reducing frustration, the team decided to implement three different logging methods—one using .NET’s ILogger, another with Serilog, and a third hybrid approach. They even suggested using a rarely seen technique involving stack traces to determine which function threw an error. This approach added unnecessary complexity and only increased my frustration.
Now, even though the project is too far along for me to withdraw, I find myself feeling burned out just a few days back at work. The code has become a tangled mess, and even routine tasks like adding logging are turning into sources of intense frustration due to constantly shifting ideas and overly complicated designs.
On top of all this, I’m also disappointed with the performance of AI tools, which seem to be producing unreliable code that requires further fixes, compounding my frustration.
I’m now seriously contemplating a complete career change—perhaps even moving to a country with a better work environment, such as Denmark or Switzerland—in the hope of finding a job where the work is more straightforward and less mentally taxing and better paying4