This question already has an answer here:
I know there are similar questions to this one, and I've read most of them. Most of the answers to these questions are talking about "cost-effectiveness" and "time-saving" aspects of the frameworks, which are huge reasons in favor of using frameworks.
I'm a pretty new .NET developer and I'm trying to learn stuff like WPF, MVVM, layered architecture design, dependency injection, logging, database access, test-driven development, and many more different technologies/techniques.
Most of the resources that I find regarding such topics start with an extremely simple example to "show" why you should use given technology/technique, which honestly looks quite ok with that simple example, but doesn't really make sense for someone who didn't deal with real-world problems these technologies/techniques help with.
After the simple example that makes me wonder what that specific technology/technique really solves, they usually go on and say "Hey, you know what, there's a framework for that called ..., let's just use it for the rest of the examples." Dependency injection? Just use Ninject. You want to fake stuff? C'mon just use Moq. MVVM? You're kidding me? just use MVVM Light Toolkit!
Which is great, really. All these tools, I'm sure, make the life easier for all the developers out there. But my problem is,
- I'm trying to use TDD, but I have never experienced the problems people experienced while they were developing stuff without TDD, which in the end made them come up with such a technique. I understand the concept behind, theoretically I can see why it was created, but in practice I am not experienced enough to see a code that would benefit from TDD. Because I haven't seen much.
- I have never had problems developing a huge application that I needed to de-couple stuff and went "Oh my god! That is ridiculous! I need to find a technique so that I won't have this much trouble next time." and found out about "Dependency Injection". All the small things that I have developed so far worked fine without the need of dependency injection.
- I have never written a WPF application that made me feel like things should be easier, presentation layer should be separate, there should be data binding. Hell, I haven't even written one WPF application!
So all these things make me think like I am going to use all these tools, without experiencing first-hand any real world situation that cultivated the creation of them.
But at the same time, I can't try to write a huge business application in WPF without using MVVM or a good layered-design and experience all the problems people experienced in the past to appreciate all these new technologies/techniques. Because there are people out there developing stuff, getting further ahead, releasing things that work. I'll be left behind because of my obsession with trying to learn everything out there to learn. And besides, these things are not easy to learn without first experiencing the problems yourself.
But then, at the same time I have those nightmares that I start working in a new company and people tell me "You can't code your own MVVM framework? You always need to use Prism? Hahahahaha!" and they go around pointing and laughing at me in circles.
I feel like I'm a lesser programmer. I feel like I don't have what it takes to create a framework on my own. I feel like I am only able to put things together, which are created by other "better" people.
I would like to ask all the experienced people out there, what strategies have you used throughout your career? Do you always use existing frameworks? Do you create pet projects to learn about why those frameworks exist?
To make a long story short, what constitutes the thin line between using a framework and creating your own? And more importantly, how do you close the knowledge gap that automatically comes up if you use a technology/technique without seeing the real-world problems they help with?