I’m ready to confess. It’s time to lay it all on the table. Ready?
I can’t keep up!
Wow, that was liberating! I think I should start a taxi service for developers.
There is so much going on in the world of software, how can I keep up with it all, while still making progress in my job? I can’t shift with the winds of what’s new or popular–even if it makes sense–they just shift too fast, it seems, and there’s no way I can be productive at work and keep up with all the new stuff. Goodness knows I try.
Here’s a list of things/buzzwords I really want to learn or use but haven’t had the time, or more importantly, haven’t had a real project that I could practice on. Growing in your software development abilities and experience relies on mentoring and apprenticing, after all. I wholeheartedly believe that. That’s why I work to surround myself with incredible people.
1. TDD - Test Driven Development
For a while now I’ve been at the point where I see the great benefits to TDD, and would love to do it, I just don’t know where to start. I need to really learn it. And by learn, I mean "be mentored". I can read about it, but implementing it on a project takes it to a ‘hole nutha level‘. And if I don’t know what I’m doing, I can’t implement it on a real project at work.
2. DDD - Domain Driven Design
This is a tough one, as it’s not really a technology or methodology, but more of a way of thinking. Which always makes me wonder: am I thinking this way? Should I be, if I’m not? How can I apply this way of thinking to my projects, considering that in many cases I’m adding features to existing products that haven’t necessarily been designed this way?
3. BDD - Behavior Driven Development
No comment. I think I just need one or two more xDD acronyms to investigate.
4. DI/IoC - Dependency Injection/Inversion of Control
This feels pretty basic, and I understand the concepts and at least grok the list of available frameworks. But in my experience it’s an architectural decision that if you don’t make from the start of an enterprise project, well, good luck getting it in later without a significant effort. And doing this right plus learning one of the existing frameworks takes a large investment that frequently I don’t have. At the moment we’ve chosen to use CAB (and related technologies) at work for our new projects, and I’m on the learning curve for it right now. I wish I was more well-rounded.
5. ORM - Object Relational Mapping
Basic stuff, right? Not for me. I work on a real-time system, not so much a database driven one, although I have done a lot of database-related work in the past. ORM doesn’t apply to me as much right now, but if you work on anything but a real-time system you’re probably using one. I’ve been learning NHibernate lately with CodeCampServer, and it’s definitely a stretch for me. I think the real problem is combining the ORM with DDD. ASAP, PDQ. FYI.
6. AOP - Aspect Oriented Programming
Another "nice to learn" idea, but I have trouble making time to learn it, not to mention how to apply it.
7. A bunch of stuff from this list (though not nearly everything)
Stuff like refactoring (specifically how to apply it successfully to large projects), proper and structured integration of LINQ and dynamic languages (if at all), what I’ll call "reasonable agile" — non-extreme agile practices, visual modeling/model-driven design, evolving architectures, etc.
You might notice that some of these things on my list aren’t exactly new or groundbreaking. This is a confession, after all. Would it be confessing to say that I don’t know much about Astoria? Nah, most people don’t. So… does anybody else struggle to learn and incorporate stuff like this? What about those who don’t? Got any suggestions for me, and people like me? What are some good sources that a random developer on the Internet can find for being mentored in practices like TDD?
* Disclaimer: I have to limit the term "software developer" to what I am: a non-consultant, full-time developer leading a team of 8 (within a dev organization of 130+) working on a mature and complex product with a release cycle of 12-18 months, and handling escalated support cases–you can’t not mention support! Oh, and I have a family and a life. 
January 30, 2008 at 15:09
fully agree. It feels like there is two new technologies everyday. I’m still on .net 2.0
January 30, 2008 at 16:38
it’s all about trajectory. hang in there.
January 30, 2008 at 17:58
Alot of those acronyms are still in the roughing out stage and/or are only use for enterprise architects. I wouldn’t worry too much about most of them.
As for TDD, I’m with you on this one. But you have to have years of experience to be able to do TDD correctly and efficiently. At my skill level, I prefer Test During Development. Keep your methods short, document them as you write them, then test the assertions you make in your documentation. You should be jumping between the three constantly.
And as far as ORM frameworks go, look at Subsonic. It uses the Active Record pattern (you forgot that one) for mapping relational data to objects. Spend an afternoon trying to implement it yourself and you soon figure out how powerful and easy Subsonic is to use.
January 31, 2008 at 02:59
Do you think that with this very fast paced advancements in software philosophy, technology and methodology -many of them conflicting with each other and often in themselves- is there a place for the practices of old? Today I was working on an IEEE 380 based SRS document for a web application. An standard from the past century! I think it is ABSOLUTELY inadequate for ANY modern application.
I think what I’m trying to ask is when do a standard, technology or framework become obsolete? My guess is that in this Age of the Beta, it is when it stops moving, but what do you think? I don’t really have much experience yet.
January 31, 2008 at 05:30
If you are looking for TDD references / mentoring, you could look at the following web sites:
http://www.testdriven.com/
http://www.agilealliance.org/articles_by_category?id=31
http://www.softdevarticles.com/modules/weblinks/viewcat.php?cid=47
January 31, 2008 at 05:37
The fact you are looking at them and considering the benefits is a great start.
Like you I haven’t used a number of these but I know where they might come in useful.
If I need to be able to allow components and services to be switched to as-yet-unknown providers once shipped I’ll use the services of IoC but building it in with no clear picture normally results in a woefully overengineered or inadequate interface plus additional code complexity.
Mentoring is a great way to get in but yes, it cam be tricky to get.
Is this a sign that programming is maturing now that we are seeking to be an apprentice to a master craftsman?
[)amien
January 31, 2008 at 05:45
Nice post, I totally agree….!!
January 31, 2008 at 05:57
I echo the SubSonic recommendation simply because SubSonic is a much simpler ORM, designed to be simple. Watching the soniccasts on www.subsonicproject.com will get you up to speed really quickly without bogging you down too much with implemenation details.
The other thing I would say is that I believe our job titles are due for a change. For instance, nobody can be a web developer any longer, that title infers (through years of misuse and neglect) that the person knows everything about every technology related to the web, which used to be be possible, but isn’t now. We need to free ourselves from this mental burden a little and allow ourselves to not worry about technologies which don’t involve us.
Whilst knowing about other technologies is critically important, we can’t specialize in all of them. It’s just not possible, as Bruce Lee would say, Absorb what is useful. Discard what is useless. In this context that refers directly to “what helps you get your job done” the truth is, if something is truly useful (and you at least know enough about it), you’ll end up using it.
January 31, 2008 at 07:53
Thanks everybody - this is some good advice! And it’s good to know I’m not alone…
January 31, 2008 at 09:37
Man … I just sleep less. Some advice I got when I was a junior was take it all in @ 10000 feet so you know where to look when the rubber meets the road. As a developer IMO the skill to come to speed fast in anything is most important. I call this being and Instpert (Instant Expert).
January 31, 2008 at 10:38
I totally agree. So what is a person to do when you aren’t in a big shop and the amount of mentors is very limited? What if you are the person leading the charge into new ways of doing the same old thing? I still haven’t figured that out yet.
January 31, 2008 at 12:15
You know what buddy, I don’t even discuss terminology or paradigm-shifts anymore. I just keep reading all the content that I can get time for, and trying to understand all the little pointers I can. Then try to use the latest technology available in whatever projects i am making, and then trying to putting in all the things I am learning in the project…
It’s a funny life to live if you’re software developer.
I’ve got bloodshot eyes and these days I am looking for a better algorithm for the problem called life.
Enjoy!
January 31, 2008 at 17:56
I totally agree….!!
February 1, 2008 at 10:45
I agree, to much to learn and not enough time to do it. I think the real talent anymore is picking and choosing what is important to know and learning it quickly. You can’t possibly learn it all, so choosing what you do learn is critical. The guy who knows everything just doesn’t exist anymore, we are all specialists.
February 1, 2008 at 18:37
I agree Aaron, there’s so much to keep up with, and time always lacks. So far I didn’t find a way to cope with it yet, but I try to read and experiment as much as I can, and hopefully first or then I will know EVERYTHING
February 2, 2008 at 10:28
I have been doing software development for a very long time (>35 years) and have seen a lot of stuff come and go. One conclusion I’ve come to is that most development/design methodologies are basically worthless. Here’s the problem: they are invented by software developers/designers/architects and not by psychologists. If you invent an algorithm for a computer and test it extensively, you can be fairly certain that it will work on any computer. But people are different and just because some developers do very well with a particular methodology doesn’t mean it’s suitable for everyone. People are not computers and there’s no development methodology that suits everyone.
February 6, 2008 at 01:11
As far as TDD goes, just try it on a project. Download NUnit, read the quick start guide, and write some tests. This will be hard at first. You will get better with practice. You’ll also gain a better understanding of the need for Dependency Injection when you want to test your classes in isolation.
February 16, 2008 at 03:50
Hey Aaron!
I think a key to success in our profession is continuous learning but you need to do it in a way that you can sustain.
1. Alternate between breadth and depth of knowledge.
2. Alternate between skills that are directly applicable to your job and skills that might add to the foundation of your knowledge base.
3. If you can, only study things that you find interesting.
4. When learning new methodologies such as TDD, don’t entirely re-tool your workflow, instead incorporate the new ideas in an evolutionary manner. I think methodologies are most powerful when they are immature and still half-baked and became less powerful as they became more formalized. TDD is an execellant field to study because it leads to the discovery of cool techniques such as “mock objects”.
5. You will be sacrificing recreational time for your studies so you should try to make your studies a form of recreation, otherwise you risk burn-out.
Some types of skills are not necessarily fodder for our resumes but increase our productivity. Like learning your IDE better or learning a scripting language.
Another facet is deciding to be an “early-adopter”. As an early-adopter you incur some risk that you might not see a return on your investment, if the skill does not garner any demand. Again, mitigate the risk by chosing a new skill that you find interesting and that adds to your general knowledge base.
As we mature in our careers and find ourselves in positons such as architect, the problems compound as we began to consider “systems of systems”. Middleware, databases, require breadth of knowledge and the ability to work with others who will be the depth.
Thanks for letting me spout off. I probably blog on this stuff myself.