In the past I’ve had to take development teams and build their skills. It was part of what I was hired to do. “Build an app, and at the same time make our developers better.” I’m back at it again and today I had a chat with someone online about where do you need to start.
First you need to know what your goals are. Usually I find that management is, by asking me to make their developers “better”, looking to increase quality, decrease development time and increase maintainability. All of these are pretty vague and there’s certainly no one day course for each one, let alone all of them. So where do you start then?
One of the first lessons I learned while at basic officer training was that before getting my section/platoon/company working on a task I needed to know what their skills (special or otherwise) were. The lesson was all about resource management. I’m starting a new project complete with a new (to me) development team and once again I’m being asked to make them “better”. I could go into a meeting room right now and tell them all how they should be doing TDD, BDD, DDD, SOLID, etc. Some (most I hope) of you will agree that these are practices that can make you a better developer. It would be far more prudent of me to walk into that room and ask instead of state though. I should take the lessons of my Drill Sergeant and initially put effort (and not much will be needed) into evaluating what skills (special or otherwise) the team has. That knowledge is going to set the foundation for how I will approach making these developers “better”.
One of the questions raised in the conversation I was having today was “When we talk about things that we can throw at developers to learn, something like DDD is (sic) beneficial. By the time someone reads the ‘blue book’ they should know quite a bit. Where would you place it (sic) relative to SOLID or the other good practices?” This raised the question of what knowledge in what order when dealing with under trained developers.
For me the whole idea revolves around one thing building on another. Yes you could dive straight into DDD, but wouldn’t it be easier if you understood something about SOLID, or OO Fundamentals? So what is my preferred order then? Depending on what the developers skills are I may start in different places, but usually the order would be something like this.
- Tooling. Understanding and being effective inside Visual Studio and other tools that are used every day.2. OO Fundamentals. Abstraction, Encapsulation, Polymorphism and Inheritance.3. DRY. Simple code reuse techniques.4. SRP. Single Responsibility is the foundation (in my mind) for all that follows.5. OLID. The rest of SOLID.6. Coupling. Why developers should care and how they can deal with it effectively.7. Application Layers. How to use logical layering to build more flexible applications8. TDD. With the foundation for good design acquired, developers are ready to learn how to apply those design skills.9. DDD. How to think about business and translate it into code.10. Frameworks. With the foundations built through this list, I feel developers are ready to understand how to use tools such as nHibernate, StructureMap, log4net and others.
I made the mistake that most developers have; jumping straight into frameworks. While it didn’t set my career back, I did need to take a step back and put concerted effort into building my way back up to frameworks again. The best part? With all of the fundamental and foundational knowledge, learning almost any framework is quite simple.
You can’t expect to blast into a room full of developers and expect them to follow this (or any list on this topic) to achieve overnight success. It’s going to take time. Time, effort and commitment. At least the transition from one learning topic to the other will be logical and smooth.