>Strangely I seem to have built all of my software without dependency injection
I'm going to guess that you've most likely used dependency injection without even thinking about it. It's one of those things you naturally do because it makes sense, even if you don't know it has an actual name, frameworks, and all that other stuff that often only makes it more confusing.
You must not work in an object-oriented language, then? (Which is very possible.) Or did you mean that you have never built software with a dependency injection framework?
Yeah I once got a job and after I got the job when they found out I'd never done dependency injection they said "we'd never have hired you if we knew that." Mind you that same manager also believed no code should ever be written if it doesn't have a test written first - real code is only ever an outcome of writing something to match what a test expects - poof - all the fun and creativity went out of programming there in an instant.
My philosophy of programming is "there's no right way to do it, do what works for you and makes you happy and if someone tell you you're doing it wrong, pay no attention - they're a bully and a fool".
This isn't about bullying someone into writing tests, it is about creating value that lasts over an extended period of time.
The value of tests doesn't generally come from when you first write them. It comes from when you're working on a codebase written by someone else (who has long ago quit, or been fired).
It helps me understand and be able to refactor their code. It gives me the confidence to routinely ship something to production and know that it won't break.
What confidence would you have on written tests by the person who left long time ago? Having tests (somebody else wrote) could mislead you in believing they got your back.
I’m not sure what point you’re trying to make. This is clearly better than having no tests at all. It’s not like I’m flying blind, the tests are right there, and I can read through them. If the coverage isn’t good enough, I can always add more. And let’s not ignore the fact that the presence of tests in the first place means someone gave a damn.
That only works if if what you're doing actually works - not just in terms of producing code that works once, but in terms of producing code that's maintainable. I don't know for sure that you're a "terrible programmer", but you're saying all the things that the terrible programmers I've worked with tended to say.
I think I can understand the boat you're in, bro. Both of the things that you don't do, I also didn't do for quite a long time, and I didn't particularly see the value in doing them (once upon a time); but I've been on a journey to make them part of how I code, and I'm pretty sure that I'm a better coder now than I was back then.
Writing tests for nearly all my code, in particular, is these days the only way I roll - and as for TDD (i.e. write the test and let it fail first, then write the actual code and make the test pass), I do it quite often, and I guarantee you that - contrary to your opinion - it makes coding a whole new kind of fun and creative. Dependency injection I still consider myself less of a ninja at, but I've done it (and seen it done) enough times now that I get it and I see the value in it.
I think it's a bit stupid for an employer to say "we'd never have hired you if we knew you had no experience in X" (sure, this doesn't apply to all skills, but I'd say it applies to quite a few). If you're worth hiring, then you'll pick up X within a few months on the job. I'm grateful to several past employers of mine, for showing me the ropes of TDD and DI (among many other things).
Anyway, I'm not saying that the above things are "the (only) right way to do it", and please don't take my above ramblings as making a judgement on your coding prowess. I agree, do what works for you. I'm just saying that there's always more to learn, and that you should always strive to be open-minded to new skills and new approaches.
What is there to be a "ninja" about when it comes to DI? As the article explains in the beginning it just means that you initialize and pass something into whatever depends on it instead of initializing it inside that thing.
It's too complicated of a term for what it is because we generally don't say we inject arguments into a function when we call a function.
But maybe you mean patterns building on that, e.g. repository/adapter patterns.
Not really. Frame or not frame a house would be a core requirement if the jobs needs that. Having used DI is not a core requirement. It is something you can learn in 2 hours if you are experienced. It might be like a carpenter not having used a specific tool but instead used another tool and there is a 4hr training at the local college on how to use the new tool.
Or like a pilot doesn't get a job because they flew a slightly older Airbus model and need to do some sim time.
