Things change quickly in the world of software development. I started my career writing in Fortran 77. I stayed fairly abreast of languages until C++ and Java. I wandered by the Pragmatic Bookshelf to see what’s new. Languages/Frameworks I’ve barely heard of include: Erlang, ANTLR, Stripes, Cocoa, Scala, Groovy and Clojure. I see that Learn to Program uses Ruby. Maybe I should start there.
And in the beginning
“The learning of a thousand languages begins with a single keystroke.” (with apologies to the original author)
So what happens when I decide to learn a new skill? What do I have to learn? What do I have to un-learn? The answers depend on several things:
- How close is the new skill to my existing skill set? After F77 I picked up C. Some parts of C resembled F77: functions, subroutines, variable typing. Others were pretty novel: pointers, main(), casting. Unsurprising my first C program looked a lot like an F77 program with “;” at the end of each statement.
- Why do I want to develop the skill? As time went by, I liked C more and more, and worked on improving my coding ability and style. I wanted to do more C and less F77, so I looked for opportunities to do C programming.
- Where will I find the time to develop the skill? Skill proficiency follows a common path from novice to expert. Learning a new skill starts by following rules (like remembering to put a “;” at the end of each statement). With enough (successful) practice and learning, I can become competent, or perhaps an expert. The journey takes time. From where will it come?
In picture form it looks like
If I have a big change, I should expect to spend a lot of time and effort on mastering the new skill. The amount of change varies based on the remaining time/effort and how much time and effort I put into learning the new skill. After awhile, my skill level should go up, and the remaining material and time/effort should go down.
As George Dinwiddie mentioned as we discussed this dynamic, it never really ends. Even experts, maybe especially experts, realize they’re still learning.
Changing Quicker
Using this picture we can look for intervention points. What can we do, add, subtract that will get me to “proficient” if not “expert” in the shortest time possible? After all, in business “time is money.”
Smaller changes should require less time. Going from Assembler to C# requires serious neural re-wiring. Java to C# not so much. Yes, there are differences between C# and Java, but it’s a smaller jump than from Assembler. Smaller changes generally don’t result in large paybacks.
Increasing the amount of time/effort will shorten the time from beginning to “proficient” as the “amount of change” will accumulate faster.
We can add training to the change effort. The training ranges from providing books/reference materials to the Brown Bag pattern to sending people to classes.
Another option would be adding a coach. XP coaches work with team members in developing skills beyond the basic language. Skills such as TDD, refactoring, maximizing the amount of code not written.
We now have a system that looks like this:
What Should You Do?
When planning a change embrace the fact that developing useful skill level takes time. If the change involves more than a single person, then everyone will progress at a different pace.
Well spent money can aid when implementing changes. Distribute books to team members. One organization I worked with offered each developer copies of Testing Extreme Programming and Agile Principles, Patterns, and Practices in C#. Send people to training and conferences.
If you’re dealing with process changes hire one or more coaches to assist the developers with the transition.