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?
Writing your own framework or using an existing one?
design;design patterns;learning;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.I've seen a great talks once about how to learn something quickly (sorry, can't find it):Follow the 20-80 rule: learn just the 20% you need that cover 80% of the use cases. Do not get stuck in details. Understand the basics and work with those until you hit a wall. And you probably will hit the wall at some point. But you will have covered a lot of ground by then. If there's no way to cover most of your use case with little use of the tool, then it's the wrong tool for the job and chances are, there's a better one out there.Do not learn too many things at a time. You say right now you don't need any of the tools you think are good. That's ok. Your next step is not to try them all out at once. Pick one. The one that seems most useful for the task at hand. Apply it. When you get a grasp of it, proceed by recursion.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.A few advices, although not all are specific to programming:Get rid of your ego. That's a life time challenge tackled step by step. But you will need it. If you're less worried about the image of yourself you're trying to project, you'll have more time for thinking about what you have to say. Most people will return the favor with respect.The question that's really important is: What can you do? How you do it, is completely irrelevant. All that matters to your boss, your users and people who build their code on yours is how quickly you can do it (i.e how much it costs), how flexible it is in the face of changing requirements and how usable it is (from a user perspective or when interfacing from other code). Whether you use a 3rd party tool or reinvent the wheel every time from scratch doesn't matter. The perceivable consequences do.Do not be bothered by assholes. The vast majority of those who have acquired noteworthy skills as developers (or any area) know how much time and work it takes. Most will go out of their way to help you if you ask them (and then really let them help you). Only a few will try to demean you. More often than not, those are the people who feel a need to compensate for their own lack of skill.Do not assume that there are many people who successfully put together a general purpose frameworks on their own. By successfully, I mean that people will use it and contribute to it and the mainstream will largely consider it as one of the out-of-the-box solutions for a particular problem. By that time, the project has usually been iterated for at least half a decade, having undergone constant review and enhancement by many people and with feedback of literally thousands - most of all the involved people being quite experienced. And most of the time, it's a successor or knock-off of some other technology that went through the whole maturation process already. There's no shame in using that. To the contrary: if it solves your problem, not using it is a waste of resources. It's often a sign of arrogance or ignorance or the combination of both.That being said: there's a lot of bloated frameworks out there that suck. As Douglas Adams once pointed out the titchyness of the human brain is best illustrated with how amazed it is by big things. When people see a big framework with a lot of documentation, they assume it must be good. The opposite is often true. It's often an indicator of over-engineering.But usually, for any given common problem you will often find a well-tested well-designed solution already available.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?When a tool get's the job done, use it. Understanding the job is the tricky thing. That's the first and most important step. Then you need to pick your tools. And then do it. And then you might realize that your understanding of the job just got better, so you need to add/substitute some tools and parts of the program. The likelihood of this happening is part of the job and is an important factor in choosing your initial toolset.Would you rather have a crash in a 50 year old car to appreciate all the safety built into a modern one? I don't think so. You have your own slices of hell coming anyway. There's absolutely no need to ask for more trouble.You must always choose what to know, but also what not to know. This is the foundation of information hiding, which is the divide and conquer of complex systems. Your programming language already is already a big white cloud high up in the abstractosphere of planet ugglydetailia. You look at things from an abstract level, because your brain can actually only function this way. It's how you deal with the real world and it's quite sensible to apply that to programming.Also, knowledge in itself is worthless. Value comes from understanding. Which quite often involves the knowledge of what not to know ;)