One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.
Through my and other's experiences I've found that dependency injection makes things simpler when you have an architecture that is well separated.
Which means that you've got interfaces and classes that do one thing each and they need to be created and passed into other classes to enable progressively larger parts of a feature.
That's a bit further ahead but I'll try to think of how to explain it that doesn't involve a whole lot of cognitive load for the reader, thanks!
One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.
I totally agree on dependency injection.
I just added that the pattern was more important that the particular framework you are using.
And that once you know the pattern, picking up the framework is easy.
but not the other way around: struggling with Dagger annotations doesn't do much to help the reader understand the DI pattern.
also Dagger documentation is crap.
Bonus: if you explain the pattern, with Dagger as a mere illustration for Android devs, your future article will be useful for much more Dev.to readers than just for people doing Dagger on Android.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
It would be good if you do what Google never cared to do, which is to explain that using dependency intention is the important part.
Should you use Dagger or Koin or manual dependency injection?
the right answer here is: it depends on your context, there is a trade-off involved.
Through my and other's experiences I've found that dependency injection makes things simpler when you have an architecture that is well separated.
Which means that you've got interfaces and classes that do one thing each and they need to be created and passed into other classes to enable progressively larger parts of a feature.
That's a bit further ahead but I'll try to think of how to explain it that doesn't involve a whole lot of cognitive load for the reader, thanks!
I totally agree on dependency injection.
I just added that the pattern was more important that the particular framework you are using.
And that once you know the pattern, picking up the framework is easy.
but not the other way around: struggling with Dagger annotations doesn't do much to help the reader understand the DI pattern.
also Dagger documentation is crap.
Bonus: if you explain the pattern, with Dagger as a mere illustration for Android devs, your future article will be useful for much more Dev.to readers than just for people doing Dagger on Android.