Me: Oh I see were using a non-standard architecture on this app. I like this bit but what is this doing? never seen it before.

Him: Ah we use that to abstract the navigation layer.

Me: oh ok, interesting idea, but that means we need an extra file per screen + 1 per module. We also can't use this inbuilt control, which I really like, and we've to write a tonne of code to avoid that.

Him: Yeah we wanted to take a new approach to fix X, this is what we came up with. Were not 100% happy with it. Do you have any ideas?

**
Queue really long, multi-day architecture discussion. Lots of interesting points, neither side being precious or childish in anyway. Was honestly fantastic.
**

Me: So after researching your last email a bit, I think I found a happy middle ground. If we turn X into a singleton, we can store the state its generating inside itself. We can go back to using the in-built navigation control and have the data being fetched like Y. If you want to keep your dependency injection stuff, we can copy the Angular services approach and inject the singletons instead of all of these things. That means we can delete the entire layer Z.

Even with the app only having 25% of the screens, we could delete like 30+ files, and still have the architecture, at a high level, identical and textbook MVVM.

Him: singleton? no I don't like those, best off keeping it the way it is.

... are you fucking kidding me? You've reinvented probably 3 wheels, doubled the code in the app and forced us to take ownership of something the system handles ... but a singleton is a bad idea? ... based off no concrete evidence or facts, but a personal opinion.

... your face is a bad idea

Laravel is the worst framework ever.

Everything has to be made convenient and easy. That sounds amazing, because developers want to save time, worry less about boilerplate code, right? No more constructors, no more dependency injection, fuck all the tedious OOP shit... RIGHT?

It does one thing well: Make PHP syntax uniform and concise through easily integrated libraries such as Collection and Carbon. But those are actually not really part of the framework... just commonly integrated and associated with Laravel.

The framework itself is completely derailed: You can define code in a callback in the routes file. You can define a controller in the routes file. You can define middleware as a parameter to the route, as a fluent method to the route, you can stack them up in a service provider. Validators can be made in controllers, Request objects, service providers, etc. You can send mail inline, through Mailable objects, through Notification objects, etc.

Everything is macroable, injectable, and definable in a million different places. Ultimate freedom!

Guess what happens when you give 50 developers of various seniority a swiss army knife?

One hammers in a screw with a nail file, the other clips the head from the screw using scissors, and you end up with an unworkable mess and blunt tools.

And don't get me started about Eloquent, the Active Record ORM. It's cute for the simple blog/article/author/comment queries, but starts choking when you want more selective and performant queries or more complex aggregates, and provides such an opaque apple-esque interface which lets people think everything is OK, when in reality it's forcing the SQL server to slowly commit suicide.

Jesus Christ. Dagger2's documentation has got to be the most convoluted shit I have ever laid my eyes on.

The sheer mental gymnastics I had to do to get through this one line at 2:30 am...

Ask interviewee what dependency injection is

Starts to explain sql injection..

Some developers get over-excited about using dependency injection and make further maintenance a nightmare.

Today I'm going to work on my side project that I haven't touched in weeks.

I want to utilize Angular 2 which means I'll need to learn TypeScript. I also want to use the new .Net Core and EF Core 1.0. Oh and I want to handle authentication using JWT!

Wow, that's gonna be a lot of effort to get things off the ground... maybe instead I'll use this time to learn some new concepts. Maybe watch this episode of Fun Fun Function, or maybe this video on writing Assembly code for an app on Raspberry Pi, that sounds cool!

Actually, you know I should really teach myself dependency injection and unit testing for once. I'm so behind the times.

Well, really I should finish this book on design patterns first. Ok, where did I leave off? Page 20 I think... ehh... maybe I'll just work on my side project.

Tomorrow... tomorrow, I'll work on my side project.

WASM was a mistake. I just wanted to learn C++ and have fast code on the web. Everyone praised it. No one mentioned that it would double or quadruple my development time. That it would cause me to curse repeatedly at the screen until I wanted to harm myself.

The problem was never C++, which was a respectable if long-winded language. No no no. The problem was the lack of support for 'objects' or 'arrays' as parameters or return types. Anything of any complexity lives on one giant Float32Array which must surely bring a look of disgust from every programmer on this muddy rock. That is, one single array variable that you re-use for EVERYTHING.

Have a color? Throw it on the array. 10 floats in an object? Push it on the array - and split off the two bools via dependency injection (why do I have 3-4 line function parameter lists?!). Have an image with 1,000,000 floats? Drop it in the array. Want to return an array? Provide a malloc ptr into the code and write to it, then read from that location in JS after running the function, modifying the array as a side effect.

My- hahaha, my web worker has two images it's working with, calculations for all the planets, sun and moon in the solar system, and bunch of other calculations I wanted offloaded from the main thread... they all live in ONE GIANT ARRAY. LMFAO.If I want to find an element? I have to know exactly where to look or else, good luck finding it among the millions of numbers on that thing.

And of course, if you work with these, you put them in loops. Then you can have the joys of off-by-one errors that not only result in bad results in the returned array, but inexplicable errors in which code you haven't even touched suddenly has bad values. I've had entire functions suddenly explode with random errors because I accidentally overwrote the wrong section of that float array. Not like, the variable the function was using was wrong. No. WASM acted like the function didn't even exist and it didn't know why. Because, somehow, the function ALSO lived on that Float32Array.

And because you're using WASM to be fast, you're typically trying to overwrite things that do O(N) operations or more. NO ONE is going to use this return a + b. One off functions just aren't worth programming in WASM. Worst of all, debugging this is often a matter of writing print and console.log statements everywhere, to try and 'eat' the whole array at once to find out what portion got corrupted or is broke. Or comment out your code line by line to see what in forsaken 9 circles of coding hell caused your problem. It's like debugging blind in a strange and overgrown forest of code that you don't even recognize because most of it is there to satisfy the needs of WASM.

And because it takes so long to debug, it takes a massively long time to create things, and by the time you're done, the dependent package you're building for has 'moved on' and find you suddenly need to update a bunch of crap when you're not even finished. All of this, purely because of a horribly designed technology.

And do they have sympathy for you for forcing you to update all this stuff? No. They don't owe you sympathy, and god forbid they give you any. You are a developer and so it is your duty to suffer - for some kind of karma.

I wanted to love WASM, but screw that thing, it's horrible errors and most of all, the WASM heap32.

I forgot what it was like to have a productive day!

I’m rewriting the Apple wallet pass code to make it fully customizable instead of mostly static, and it’s beautiful.

The code was horrible tangled spaghetti before (and soo slow) but now it’s clean and fast and modular and absolute bliss to spec. Yay, dependency injection!

I actually had fun working today! 😊
It’s been the first time in months.

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 -.-

When you feel like your falling behind because at work you don't unit test, use dependency injection or pretty much anything the devs in the community discuss.

Built my own IoC container for C#. This taught me way too much about SOLID principles and dependency injection that i could give lessons now 😂

I'm still using my own IoC in my projects... It's great 🤘

When I was in college OOP was emerging. A lot of the professors were against teaching it as the core. Some younger professors were adamant about it, and also Java fanatics. So after the bell rang, they'd sometimes teach people that wanted to learn it. I stayed after and the professor said that object oriented programming treated things like reality.

My first thought to this was hold up, modeling reality is hard and complicated, why would you want to add that to your programming that's utter madness.

Then he started with a ball example and how some balls in reality are blue, and they can have a bounce action we can express with a method.

My first thought was that this seems a very niche example. It has very little to do with any problems I have yet solved and I felt thinking about it this way would complicate my programs rather than make them simpler.

I looked around the at remnants of my classmates and saw several sitting forward, their eyes lit up and I felt like I was in a cult meeting where the head is trying to make everyone enamored of their personality. Except he wasn't selling himself, he was selling an idea.

I patiently waited it out, wanting there to be something of value in the after the bell lesson. Something I could use to better my own programming ability. It never came.

This same professor would tell us all to read and buy gang of four it would change our lives. It was an expensive hard cover book with a ribbon attached for a bookmark. It was made to look important. I didn't have much money in college but I gave it a shot I bought the book. I remember wrinkling my nose often, reading at it. Feeling like I was still being sold something. But where was the proof. It was all an argument from authority and I didn't think the argument was very good.

I left college thinking the whole thing was silly and would surely go away with time. And then it grew, and grew. It started to be impossible to avoid it. So I'd just use it when I had to and that became more and more often.

I began to doubt myself. Perhaps I was wrong, surely all these people using and loving this paradigm could not be wrong. I took on a 3 year project to dive deep into OOP later in my career. I was already intimately aware of OOP having to have done so much of it. But I caught up on all the latest ideas and practiced them for a the first year. I thought if OOP is so good I should be able to be more productive in years 2 and 3.

It was the most miserable I had ever been as a programmer. Everything took forever to do. There was boilerplate code everywhere. You didn't so much solve problems as stuff abstract ideas that had nothing to do with the problem everywhere and THEN code the actual part of the code that does a task. Even though I was working with an interpreted language they had added a need to compile, for dependency injection. What's next taking the benefit of dynamic typing and forcing typing into it? Oh I see they managed to do that too. At this point why not just use C or C++. It's going to do everything you wanted if you add compiling and typing and do it way faster at run time.

I talked to the client extensively about everything. We both agreed the project was untenable. We moved everything over another 3 years. His business is doing better than ever before now by several metrics. And I can be productive again. My self doubt was over. OOP is a complicated mess that drags down the software industry, little better than snake oil and full of empty promises. Unfortunately it is all some people know.

Now there is a functional movement, a data oriented movement, and things are looking a little brighter. However, no one seems to care for procedural. Functional and procedural are not that different. Functional just tries to put more constraints on the developer. Data oriented is also a lot more sensible, and again pretty close to procedural a lot of the time. It's just odd to me this need to separate from procedural at all. Procedural was very honest. If you're a bad programmer you make bad code. If you're a good programmer you make good code. It seems a lot of this was meant to enforce bad programmers to make good code. I'll tell you what I think though. I think that has never worked. It's just hidden it away in some abstraction and made identifying it harder. Much like the code methodologies themselves do to the code.

Now I'm left with a choice, keep my own business going to work on what I love, shift gears and do what I hate for more money, or pivot careers entirely. I decided after all this to go into data science because what you all are doing to the software industry sickens me. And that's my story. It's one that makes a lot of people defensive or even passive aggressive, to those people I say, try more things. At least then you can be less defensive about your opinion.

Dependency Injection Frameworks are absolute shit. I have yet to encounter one that doesn't make code take hours to understand or debug, and usually requires a debugger to even begin to unravel it. Not to mention the "context" god objects that just are glorified versions of passing an array from function to function. You guys aren't avoiding global state you're just making it a clusterfuck. Stop being stupid for 2 minutes software development "progress" challenge. Level: impossible.

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?

When you have a ton of business logic in one of the main services. Good or bad?

As I was refactoring a class in a TypeScript project, I changed calls from `this.config` to `this.getConfig()`.

Suddenly, the tests were failing as somehow the live credentials were used from within the test.

Digging deeper I discovered this.

interface Base {
public config;
public getConfig();
}

So far so good. Wondering why config needs to be public, though nothing too shabby, let's look further:

class MyImpl implements Base {
constructor() {
this.config = this.getConfig()
}

getConfig = () => someGlobalVar;
}

┻━┻︵ \(°□°)/ ︵ ┻━┻

Why would you do this? This breaks dependency injection completely.

In the tests, we were of course doing:

testMe = new MyImpl();
testMe.config = testConfig;

So even though you have a getter, you cannot call it safely as the global var would take precedence. It's rather used as a setter within the constructor. WTF.

Sad part is that this pattern is kept throughout the entire codebase. So yeah for consistency!?

(And yes, I found a quick workaround by doing

getConfig = () => this.config || someGlobalVar;

though still, who in their right mind would do something like this?)

It’s late, and stupid RSpec has decided to only mock calls to a particular method in some specs but not in others.

`allow(object).to receive(:method).with(resource_arg).and_return(“some\ntext”)`

Works in a few specs, but not the rest. Why? Who the fuck knows. Probably some shared state between specs that isn’t supposed to happen.

HAHA JUST KIDDING

After refactoring my specs to use unique ‘resource’ names for each call because I’ve had shared state issues before.

and after refactoring my model code to remove a lot of now-unused dependency injection (because maybe it was mocking a different object than got passed in?)

Guess what?
When creating my mock objects, I forgot to link them together. That’s it. A 14-character change. And suddenly they all pass.

Asdjklfajg.
Time for bed.

The Singleton vs Dependency chain

A very good read if you want to learn about dependency injection in .Net. (I might have an older version of the book though)

How could you explain the purpose of dependency injection to 5 years old child?

Developers who think complex code is good.

"Oh, lookie here, I can swizzle methods and inject dependencies in the runtime!"

"Although we have no valid use case, let's use dependency injection and follow the commandory stateor patterns because I watched a video."

Just because you learn something new that looks cool does not make it practical, you tosser.

# Retrospective as Backend engineer

Once upon a time, I was rejected by a startup who tries to snag me from another company that I was working with.
They are looking for Senior / Supervisor level backend engineer and my profile looks like a fit for them.
So they contacted me, arranged a technical test, system design test, and interview with their lead backend engineer who also happens to be co-founder of the startup.

## The Interview

As usual, they asked me what are my contribution to previous workplace.
I answered them with achievements that I think are the best for each company that I worked with, and how to technologically achieve them.

One of it includes designing and implementing a `CQRS+ES` system in the backend.
With complete capability of what I `brag` as `Time Machine` through replaying event.

## The Rejection

And of course I was rejected by the startup, maybe specifically by the co-founder. As I asked around on the reason of rejection from an insider.

They insisted I am a guy who overengineer thing that are not needed, by doing `CQRS+ES`, and only suitable for RND, non-production stuffs.

Nobody needs that kind of `Time Machine`.

## Ironically

After switching jobs (to another company), becoming fullstack developer, learning about react and redux.
I can reflect back on this past experience and say this:

The same company that says `CQRS+ES` is an over engineering, also uses `React+Redux`.
Never did they realize the concept behind `React+Redux` is very similar to `CQRS+ES`.

- Separation of concern
- CQRS: `Command` is separated from `Query`
- Redux: Side effect / `Action` in `Thunk` separated from the presentation
- Managing State of Application
- ES: Through sequence of `Event` produced by `Command`
- Redux: Through action data produced / dispatched by `Action`
- Replayability
- ES: Through replaying `Event` into the `Applier`
- Redux: Through replay `Action` which trigger dispatch to `Reducer`

---

The same company that says `CQRS` is an over engineering also uses `ElasticSearch+MySQL`.
Never did they realize they are separating `WRITE` database into `MySQL` as their `Single Source Of Truth`, and `READ` database into `ElasticSearch` is also inline with `CQRS` principle.

## Value as Backend Engineer

It's a sad days as Backend Engineer these days. At least in the country I live in.
Seems like being a backend engineer is often under-appreciated.
Company (or people) seems to think of backend engineer is the guy who ONLY makes `CRUD` API endpoint to database.

- I've heard from Fullstack engineer who comes from React background complains about Backend engineers have it easy by only doing CRUD without having to worry about application.
- The same guy fails when given task in Backend to make a simple round-robin ticketing system.
- I've seen company who only hires Fullstack engineer with strong Frontend experience, fails to have basic understanding of how SQL Transaction and Connection Pool works.
- I've seen company Fullstack engineer relies on ORM to do super complex query instead of writing proper SQL, and prefer to translate SQL into ORM query language.
- I've seen company Fullstack engineer with strong React background brags about Uncle Bob clean code but fail to know on how to do basic dependency injection.
- I've heard company who made webapp criticize my way of handling `session` through http secure cookie. Saying it's a bad practice and better to use local storage. Despite my argument of `secure` in the cookie and ability to control cookie via backend.

This quote made my day.

"Dependency Injection" is a 25-dollar term for a 5-cent concept. [...] Dependency injection means giving an object its instance variables. [...]."

Best : .NET core 1.0 is publicly released

Worst : DI went over my head.

Will try to get it this year.

As someone who didn´t work with dependency injection in almost all projects before:

I legitimately sat here for half an hour and asked myself how to fucking access a new database context...

Me:
You can´t just add that to the constructor.
Dependency Inection:
Yes you can!

dependency injection is for pussies, real programmer downloads only required library files into tidy folders.

That this one component being object orientated is necessary and good design.
We have uh interfaces, theyre contracts.

Spoiler: it wasn't, I could have written it in half the code and half the time. But no, we gotta have those patterns, can't miss on dependency injection!

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 useful

Proactively seeking out new knowledge: mostly podcasts and watching what's new on github.

keeping an open mind: just because some pattern is industry proven doesn't mean its necessarily the better,

Testing: write a test describing a problem then trying to write slightly different solutions (eg. One that leverages service location, another that emphasize dependency injection..),

Forced & timed breaks: keep hydrated, don't get stuck "spinning the wheel".. :)

If I interview one more guy who thinks dependency injection is wholly "those spring annotations" and nothing else, I think I might scream.

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.

Good oop is hard to implenent and keep track off in my experience.

I have seen projects so hard which have such large hierarchies and reused components that even the most minimal change breaks an entire change. Dependency injection is a pretty cool tool to use, but I have seen more people fuck it up and make something that supposedly removes tightly coupled components be the extreme opposite.

Remember your basics people. Fuck

Ok everything is good now. Happy thoughts...nuthing but happy thoughts

A sweaty furry sodomizing a dead dog would still be less disgusting than the codebase on which I have to work, some highlights are:
- The same class repeated 40 times with little variations instead of using some decent parametrization
- Inexistent encapsulation and separation of concerns, most changes requires to modify and recompile 2-3 indipendent Maven projects
- Abuse of inheritance which instead of being used to create "is-a" relationship as it should be it's used to reuse some methods of a class in another instead of using Spring dependency injection as we should be

It would be understandable in a 20 years old legacy projects but in something which started 2 months ago it drives me mad, I tried to fight to change it but in the big enterprise to which I'm "body-rented" it's impossible

I messed up between Dependency Manager and Dependency Injection and looked a bit of a tool.

I would rather create a circular inheritance class for my last task before I'm out of the company. And make some changes to the dependency injection module. Leave it blank documentation. So the one who take my position after me would get enough lesson and reason why he's not to join the company.

!RANT

Oh, the SORROW that is JEST! 😡

Endless days have been swallowed by the abyss in my quest to configure Jest with TypeScript and ECMAScript modules instead of CommonJS. Triumph seemed within my grasp until - BAM! - suddenly the tool forgets what "import" or "export" means. And the kicker? On the CI, it still runs like nothing’s amiss!

Allow me to elucidate for the uninitiated: Jest is supposed to be a testing safeguard, a protective barrier insulating devs from the errors of their peers, ensuring a smooth, uninterrupted coding experience.

But OH, how the tables have turned when the very shield becomes the sword, stabbing me with countless, infuriating errors birthed from Jest’s own design decisions!

The audacity to reinvent the whole module loading process just to facilitate module mocking is mind-boggling! Imagine constructing an entirely new ecosystem just to allow people to pretend modules are something they're not. This is not just overkill; it's a preposterous reinvention of a wheel that insists on being a pentagon!

Sure, if devs want to globally expose their variables, entwining everything in a static context, so be it. BUT, why should we, who walk the righteous path of dependency injection, be subjugated to this configured chaos?!

My blood boils as the jestering Jest thrusts upon me a fragile, perpetually breaking system, punishing ME for its determination to support whole module mocking! A technique, mind you, that I wouldn’t touch with a ten-foot pole, because, you know, DEPENDENCY INJECTION!

Where are the alternatives, you ask? Drowned in the abyss, it seems! Why can’t we embrace snapshots and all the delectable integrations WITHOUT being dragged through this module-mocking mire? Can’t module mocking just be a friendly sidekick, an OPTIONAL add-on, rather than the cruel dictator forcing its agenda upon our code?

Punish those clinging to their static contexts, their global variables – NOT those of us advocating for cleaner, more stable practices!

It’s high time we decouple the goodness of Jest from its built-in bad practices. Must we continue to dance with the devil to delight in the depth of Jest’s capabilities?

WHY, Jest, WHY?! 😭

Database assisted Dependency Injection... How does that sound?

Android Java came a long way since I've stopped programming for it 5 years ago. Now you've got nice dependency injection, storage helpers and good hybrid solutions. So, curious as I am, I asked to work on some bug fixes in the Android application at work. Bad choice.

"Welcome back!" said the nullpointers, "We've missed you!"

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.

After going through the regular process of talking to HR/Recruitment and passing the casual interview with a team-mate for cultural compatibility, I got the task of grilling a candidate on some technical matters. This being a PHP job, we got to talking about PSRs (PHP Standards Recommendations).

As he seemed to take pride in his knowledge of PSRs, I decided to focus more closely on that.

So we got to a recomendation regarding dependency injection containers. Nothing special, and he seemed to know his stuff. At that point, he made a statement that parts of that recommendation were a bit stupid.

Now, I hate to put people in their place, but his statement did not match what that specific PSR stated. So I gently tried to correct him. The candidate, being on fire thus far, pointed out that I should trust him on this, as he clearly knew his stuff.

Again, I didn't like having to do this, but I also did not like him having a misconception about a topic he was, otherwise, really on top of...

So I asked him to trust *me*, as I was one of the writers who contributed to the standard.

The true test here, of course, wasn't if he knew all the minutia of every standard but how he would react to being corrected.

We, as developers, are wrong all the time. Its how we learn and evolve. So being able to accept that is vital.

Sadly, he did not respond too well and sunk into a bit of a sullen silence. At first I though maybe I'd scared him or that he was afraid of having made a gaff but it soon turned out he genuinly did not like being wrong.

Sadly, I had to advise against hiring him.

FUCK THAT FUCKING ECLIPSE DEPENDENCY INJECTION FUCKUP SHIT.

How are you supposed to work with @Preference when it is not in the FUCKING TARGET PLATFORM, and adding it BREAKS THE WHOLE FUCKING PROJECT.

Which update site does it provide anyways for Eclipse Neon!?

Every damn tutorial out there does not talk about that shit or is outdated as fuck!!

AAHHHRRGH! *injects a keyboard as dependency into the FUCKING 💻*

My visceral hate of Spring.Net burns with the force of a thousand suns.

Almost everything it does is done wrong or solved better by other solutions.

Specifying which classes to instantiate from .xml files? Sure why not, compile type safety (the whole reason for using a static programming language) is obviously overrated and dependency based injection is surely impossible!
And for extra bonus points, now our client code must be aware of the internals of the service classes, and all of their references as well, because, encapsulation? Who cares.

Have you made an typo? Good fucking luck finding out from which of the 100 config files we have floating around...

And, because it has baked in AOP and Transactions its woven into the fabric of the project like a tapewom.

Of course this may just be how our "special snowflake" project uses Spring.

What makes it more painful is that I love good DI tools (ninject, castlewindsor, autofac, there are so many...) and we're stuck with this turd because 7 years ago some java devs couldn't be arsed to learn a new library...

Dependency injection and RX java and all are cool.

But I like to do good object oriented programming.

And now there are kids in start ups who see devs doing good object oriented programming as retards.

Android as a platform provides everything that you need. Why abuse a simple app with all fancy stuff when you can accomplish stuff with simple oops which takes the same amount of time ?

Am I the one feeling this way ?

I hate this modern fad of "composed" , "modular" extension/plug-in development. ALL I want to do is add two dropdowns to a phpBB forum, one for users and one for a single admin setting.

Guess what? I need TEN fucking files to make this extension work. Fuck your fucked dependency injection, fuck learning your whole bloody "ecosystem" (kill me already), fuck having a "tutorial" that doesn't explain what half the settings are...

It really drives me nuts that I have to spread my code over so many files to make this work.

That said, I don't really hate phpBB, but maaaaaaaan, making the simplest, dumbest thing is unnecessarily complicated.

/rant

Am I the only one to think companies asking questions such as those for technical interviews don’t understand what software engineering/development is about ?

- How many layers does a webservice have?
- What framework do you use for unit testing ?
- How do you do dependency injection ?

Essentially questions that they deem black and white but really aren’t. Besides isn’t the core of the work to just adapt and learn while being smart about what things you implement ? I don’t get these questions for me it’s a sign that a company doesn’t understand the work I’ll be doing.

I think for a technical interview I’d much rather spend my time on a difficult algo question in the language of my choice for 30mins - 1h than 20mins answering close minded questions that don’t have to be.

This rant is mostly due to the fact I’ve done a few interviews with two companies and both behaved like that, I’m 100% certain I had the skills to do the jobs they were offering me (they both contacted me first) but both ended up denying me because my knowledge on their specific questions wasn’t detailed enough. I could have learnt their stack in about a week so I don’t know why that mentality exists.

I might be wrong about the core of the work though… what do you think?

I know that DI(dependency injection) is probably just another good pattern out there like many others, but dear lord have I been burned on it with acumatica. Acumatica just loves having friggen magic crap everywhere with no damn explanation(*may be in a blog post somewhere but that’s no replacement for good documentation).

I believe they use AutoFac in C# on an asp.net server. They love to utilize reflection and injection and in turn the server takes multiple minutes to startup whilst it dynamically registers everything, as well on any individual pages.

Development is a pain in the ass on this damn system.

I’m constantly having to dive into the damn code using dotpeek to understand what the fuck they are doing and it’s often friggen stupid shit. They like to reinvent the wheel a fair bit.

I am just student looking for job, and got this pre interview test:
Develop an Android or iOS app with login and password input field, download button, place for image we prvided.

... reading further:
What we are looking for in the code ?
internal quality:
-consistent formatting of the source code
-clean, robust code without smells
-consistent abstractions and logical overall structure
-no cyclic dependencies
-code organized in meaningful layers
-low coupling and high cohesion
-descriptive and intention-revealing names of packages, classes, methods etc.
-single small functions that do one thing
-truly object-oriented design with proper encapsulation, sticking to DRY and SOLID principles, without procedural anti-patterns
-lots of bonus points for advanced techniques like design patterns, dependency injection, design by contract and especially unit (or even functional or integration) tests

external quality:
-the app should be fully functional, with every state, user input, boundary condition etc. taken care of (although this app is indeed very small, treat it as a part of big production-ready project)
-the app should correctly handle screen orientation changes, device resources and permissions, incoming calls, network connection issues, being pushed to the background, signing deal with the devil :D and other platform intricacies and should recover from these events gracefully
-lowest API level is not defined - use what you think is reasonable in these days
-bonus points if the app interacts with the user in an informative and helpful way
-bonus points for nice looks - use a clean, simple yet effective layout and design

... I mean really ? and they give me like 2 days ?

At first i was told to go to college BY PEOPLE WITH NO COLLEGE because i wouldnt be able to find a job without degree

Like a sucker i fell for it and believed in those LIES so i sacrificed my life for school

Then later i found out PEOPLE WHO FINISHED COLLEGE told me i just need knowledge in order to be hired, and turns out degree is unimportant

Like a sucker i fell for it and believed in those LIES so i studied and worked on practical projects and gained knowledge

Now when I try to get hired, they admitted that i am able to complete complex projects and i know how to solve the problems even if i see them for the first time. But they rejected me because "im not sure why the car leaks oil".

I have to understand and know what the whole framework is doing under the hood, how everything works, how dependency injection works under the hood, SOLID principles under the hood, decorators how they work under the hood etc.

So now it turns out
- sacrificing life for school is not enough
- sacrificing life for degree is not enough
- sacrificing life for learning and gaining knowledge is not enough
- now the new trend is i have to know not only how to drive a car like a professional formula F1 driver, i also have to be a mechanic and know how to fix the car if it breaks.

MATRIX IS A BIG FAT BULLSHIT AND A LIE.

I feel like they're looking for a senior developer knowledge to pay him junior developer salary

WTF IS THIS BULLSHIT?

I sacrificed 10 days of my life for their bullshit to build this project from scratch as a technical interview. They never said congrats on all the parts that were built right, but only complained about the small portion of bugs i didnt have time to fix.

ALL OF THIS FOR A SALARY OF $1500/MONTH THAT I ASKED. THATS LESS THAN 20,000$ A YEAR. THEY EITHER GAVE ME AN OPTION TO WORK FOR WAY LESS (500-600$/month) OR CALL THEM BACK IN A FEW MONTHS.

I JUST FINISHED COLLEGE AND THEY EXPECT ME TO HAVE 20 YEARS OF SENIOR DEVELOPER EXPERIENCE.

WTF IS THIS SLAVERY BULLSHIT?

HAVING A 500$/MONTH AS ENGINEERING SALARY WITH A DEGREE IS BELITTLING OF THIS JOB.

NO I DONT LIVE IN INDIA I LIVE IN SERBIA. MY DOG IS SICK AND IT COSTS 100$ A DAY JUST FOR HIS TREATMENT. HOW AM I SUPPOSED TO SURVIVE WITH A SLAVE SALARY IN THIS ECONOMIC CRISIS.

I DON'T UNDERSTAND

Fighting a CDI dependency injection problem that makes no sense. The only thing that sucks about the magic of DI is troubleshooting it when it doesn't work.

I'm getting pretty fed up with dependency injection and having to do work in Loopback; why cant it just work!

What if instead of getting the pfizer or moderna vaccine, you got a VaccineProvider in your arm instead?

Now you can swap out whichever vaccine you like

Let's call it... Dependency Injection

> As a developer in the Go world, I would recommend you to embrace idiomatic Go patterns and avoid dependency injection.

google literally created a DI lib for go.

Started doing CakePHP because of a project I’m taking over. What in the world is that? Dependency injection? Separation of concern? Single responsibility? What did I get myself into…

F*** Symfony, dependency injection and EmberJS.

Am I doing this right?

Hey guys, first time writing here.
Around 8 months ago I joined a local company, developing enterprise web apps. First time for me working in a "real" programming job: I've been making a living from little freelance projects, personal apps and private programming lessons for the past 10 years, while on the side I chased the indie game dev dream, with little success. Then, one day, realized I needed to confront myself with the reality of 'standard' business, where the majority of people work, or risk growing too old to find a stable job.
I was kinda excited at first, looking forward to learning from experienced professionals in a long-standing company that has been around for decades. In the past years I coded almost 100% solo, so I really wanted to learn some solid team practices, refine my automated testing skills, and so on. Also, good pay, flexible hours and team is cool.

Then... I actually went there.

At first, I thought it was me. I thought I couldn't understand the code because I was used reading only mine.
I thought that it was me, not knowing well enough the quirks of web development to understand how things worked.
I though I was too lazy - it was shocking to see how hard those guys worked: I saw one guy once who was basically coding with one hand, answering a mail with another, all while doing some technical assistance on the phone.

Then I started to realize.

All projects are a disorganized mess, not only the legacy ones - actually the "green" products are quite worse.
Dependency injection hell: it seems like half of the code has been written by a DI fanatic and the other half by an assembly nostalgic who doesn't really like this new hippy thing called "functions".
Architecture is so messed up there are methods several THOUSANDS of lines long, and for the love of god most people on the team don't really even know WHAT those methods are for, but they're so intertwined with the rest of the codebase no one ever dares to touch them.
No automated test whatsoever, and because of the aforementioned DI hell, it's freaking hard to configure a testing environment (I've been trying for two days during my days off, with almost no success).
Of course documentation is completely absent, specifications are spread around hundreds of mails and opaquely named files thrown around personal shared folders, remote archives, etc.

So I rolled my sleeves up and started crunching as the rest of the team. I tried to follow the boy-scout rule, when the time and scope allowed. But god, it's hard. I'm tired as fuck, I miss working on my projects, or at least something that's not a complete madness. And it's unbearable to manually validate everything (hundreds of edge cases) by hand.

And the rest of the team acts like it's all normal. They look so at ease in this mess. It's like seeing someone quietly sitting inside a house on fire doing their stuff like nothing special is going on.

Please tell me it's not this way everywhere. I want out of this. I also feel like I'm "spoiled", and I should just do like the others and accept the depressing reality of working with all of this. But inside me I don't want to. I developed a taste for clean, easy maintainable code and I don't want to give it up.

I'm an iOS developer and I cringe when I read job specs that require TDD or excessive unit testing. By excessive I mean demanding that unit tests need to written almost everywhere and using line coverage as a measure of success. I have many years of experience developing iOS apps in agencies and startups where I needed to be extremely time efficient while also keeping the code maintainable. And what I've learned is the importance of DRY, YAGNI and KISS over excessive unit testing. Sadly our industry has become obsessed with unit tests. I'm of the opinion that unit tests have their place, but integration and e2e tests have more value and should be prioritised, reserving unit tests for algorithmic code. Pushing for unit tests everywhere in my view is a ginormous waste of time that can't ever be repaid in quality, bug free code. Why? Because leads to making code testable through dependency injection and 'humble object' indirection layers, which increases the LoC and fragments code that would be easier to read over different classes. Add mocks, and together with the tests your LoC and complexity have tripled. 200% code size takes 200% the time to maintain. This time needs to be repaid - all this unit testing needs to save us 200% time in debugging or manual testing, which it doesn't unless you are an absolute rookie who writes the most terrible and buggy code imaginable, but if you're this terrible writing your production code, why should your tests be any better? It seems that especially big corporate shops love unit tests. Maybe they have enough money and resources to pay for all these hours wasted on unit tests. Maybe the developers can point their 10,000 unit tests when something goes wrong and say 'at least we tried'? Or maybe most developers don't know how to think and reason about their code before they type, and unit tests force them to do that?

Couldn't sleep most of the night because was thinking about dependency injection (Spring) and unit testing...

And came to the thinking that pretty much every time you need to create a new method it should be in a new class, wrapped with and interface?

So then how do you decide whether to create a new class/interface vs a private method in an existing class?

I mean seriously, learning dependency injection using dagger 2 was unnecessarily hard wtf.

Why are devs at google making it hard for android developers? They release libraries so frequently and completely overhaul everything. It was fine till a limit. Now again they are releasing jetpack compose which is a completely new thing. I don't have problem learning new things but the rate at which they release new stuff is far swift than other frameworks. For example they release a new dependency injection hilt while recruiters still look for dagger 2. Android is just getting overwhelming. What are your thoughts?

Dependency injection is the most useless piece of crap ever invented. Convention over configuration my ass.
It simplifies nothing a good architecture and pattern can't solve. It's just the current trend but it's the hugest pain in the ass I've ever experienced. It just adds complexity to the project.
I think it's just a thing for masochists and lazy devs, but then why not sticking a huge dido up your ass it's the same fucking thing.

We are dependent on dependency injection and package management... which also comes with a lot of dependencies installed by another package manager

I'm trying. I'm really trying to understand you Dagger 2. But every time I read articles, look at source code and just try to understand how your magic works, I end up copy pasting the sample code. And then I don't know what I even did ffs.
Maybe it's so damn hard for me because I don't understand Dependency injection? But I think I do... What can I do to understand you? Please tell me?
Especially when my use case requires nested fragments and isn't just that typical inject fragment to activity sample...

And now I have to fill in all of the injected fields in my integration tests by hand because I can't figure out how to fucking make you piece of shit do the motherflipping injection!! Fuck.

I need painkillers... My head starts hurting

Completed whole code in spring framework and client asked when will you add dependency injection. :/

Saturday morning, trying to set up an automated testing environment on my own since at the workplace it's not considered something useful and time should be spent on other stuff. Yay.
Been there another couple of times, both times failed due to poor, overcomplicated architecture that makes use of DI in the very places it shouldn't (and vice versa)... but then I finally found where the DB access is configured and thought "well, let's try tomorrow to automate this bitch".
...turns out, the db access object is injected indeed, but... from a static, deeply nested configuration file, that's referenced EVERYWHERE and embedded in the project core dll.
So basically I can't use a mock DB without changing it in the original config and recompiling the actual project I'm testing, not the test project itself. WTF?!
Or maybe I'm missing something... god, I hope it's me missing something here.
I hope so much to be wrong...

My project setup:
-Entity Framework (Code first)
-Autofac (Dependency Injection)
-Asp.Net MVC C# with service layer pattern.

How is your setup? :)

I hate it, when symfony stops the execution without any hint if you configure a dependency-injection with a non-existing class or a call on a function that does not exist.

The only reliable debugging is supported for di configuration of constructors.

It feels like, "oh. You wanna call a function or give us the classname via dependency-injection? Good luck yankee!! Better know your shit xD"

Am I the only one having a really hard time grasping code when it involves more than just a few classes devided into several files?! I simply can't follow what happens when method a in class b instantiates class c and d while implementing interface e injection dependency f and extending class g...!?

Does this make sense?

Just received code review from interview technical task. 50 percent of it was because of encapsulation (that 5-8 variables could have been private instead of public). 20 percent was about shit that was expected but missing (error validation, dependency injection). It was missing because it was not specified in app requirements and also noone said that I have to build a production level application for a simple interview here. 10 percent was nitpicking about formatting(I used default intellij formatter) and one ide error that appeared because of project importing. And only 20 percent of feedback was actually constructive and useful. Cool. Also developer said that he was shocked that I made loading animation but didnt call it in my app. However I made it, but if you have fast internet connection it doesnt show up. I mean if you run my app on a phone with gprs connection u will see that damn animation. What Im supposed to do slow down the app so u could see it? But we are building production level app here no? Shit. It feels like he applied double standards to me or something. Half of review nitpicking about useless details and another half about shit that is expected to be in the app but was not even communicated. Also I did not get developers contact so I could ask him what the fck he wanted from me.

Writing unit tests and need to deal with static methods, which are using dependency injection.

The feeling you get when you have to refactor a 'refactoring effort of a common library for a better unit test coverage', because someone forgot to factor in apps using dependency injection.

DI containers have feelings too!

Dude, stop using dependency injection for your loggers. We don't need to inject that crap. Just define it and be done.

I'm not a web dev, but I hear a lot of talk about dependency injection from fellow devs on the web scene. Wtf is it? Please explain it to my smooth brain

when you merge changes from other branch, made by other team, and see that huuuuge old project is now basing on dependency injection instead of one singleton- manager approach. Even merge conflicts look beautiful!

How should I explain to my colleagues why to use a object oriented approach or even dependency injection when they write mostly only static methods in our projects?
Points like testing and maintenance don‘t sadly work.

I'm trying to understand Dependency Injection.
can I say dependency injection represent a class that is dependent of another class?

Dependency Injection

Why is it, that #Java Spring AOP are this stupid:

When accessing parameters at a joined method, it is not guaranteed, that they are in the right order.

Some guy thought it would be a good idea to use fcking "System.arrayCopy" because of performance during dependency injection-based aspect-oriented programming.

Roast me but when doing give me a solution to get the right ordered args.

A self-proclaimed 'Technical Architect' who didn't understand how Objects behaved in Java. The same guy also decided it was a good idea to check a config file for each environment into git, instead of using dependency injection like we had done everywhere else.

So I am working on a Java library with minimal dependencies. Everything goes well until you dont want clients knowing how to construct the internal objects and you dont have a depenency injection framework to help.
Unit testing becomes that bit trickier

Dagger is such a useful lib but it's also a giant mindfuck

If you use PHP with DI, in a single cli application, why don't you go get pegged with a catus.

- source wasting an hour trying to debug, why DI keeps feeding wrong arguments to objects

Msal.js. I give it 3/10..

The docs are duplicated, and in various states of out of date. Half the library seems to be undocumented based on how many edge case bugs I've hit, it offers a popup login but you have to have a set specified white list of urls you can launch the popup from which makes a popup login pointless...

Ontop of that my colleagues shat the bed on it and fucked the whole implementation including the azure b2c setup... We do not even have a backend app listed in the azure b2c apps. The redirect also won't work if you don't instantiate an object in a hidden iframe of your own website that fetches a token... This does not make life easy when you use a SPA framework and you have already implemented a whole pipeline abstracting the creation of this object behind layers dependency injection.. Nice.

After sifting through endless shit I finally have a solution. What a week.

This is a TypeScript question, but that shouldn't matter.

Would you use dependency injection to get access to your controllers inside your router files, or would you just import them?

Is there a book I gotta read to understand the freetype documentation? What the hell! I've gone through the documentation and there are like 6 different units being used here. I understand that text rendering is one of the more difficult problems in CS, but there's gotta be an easier way to learn this stuff.

FFS what is the standard with dependency injection with Android. Is it dagger2 or kodein. Last 2 days googling about and it seems like it's dagger2 yet others say it's kodein. Kodein is newer I guess so less written about it. Seems like every 2 weeks it's something new. No wonder I can't pick this up. It changes faster than Trump can fricken tweet.

Like first mvc then mvp then mvvm then mvi what's next mve? 😵

So flustered. As last post I feel like giving up. Every time you try to learn some new "standard" creeps out from CS major ass crack. Is it the same for IOS. Maybe I should sell a kidney for a Mac book.

I'm gonna have an interview that will include talking about php. Problem is, I haven't touched php in 5 years. What do I need to know to sound like I know what I'm talking about? "Mmm yes I really like Laravel dependency injection, it makes managing dependencies so much easier"?

Hangfire, Autofac and Web API ! Only if i can figure out this shit😖😖

When I ask someone what is Spring Framework, and `Dependency Injection` in answer is kind na 'F' word to me. Dammn!!

Ever feel like asp.net core dependency injection is cumbersome to setup correctly. Well worry no more!