Over the last two weeks, I’ve been waist deep in what has been, for me, a completely new client side development platform. We have several projects underway at present that leverage Dojo as the framework for rich client GeoWeb applications and, simply put, we’ve got more Dojo work than our two resident experts can handle at present. Time to roll up my sleeves and learn something new!
Since I’m a botanist by training, and not a classically trained programmer by any stretch, I don’t typically look at a new technology and say “Gee Whiz, this looks an awful lot like <pick your poison> that I learned back in University”. I’ve got sort of a free form learning process that works for me, and usually get’s me up and running and useful in a relatively short period of time…a matter of days if I have examples and a pattern rather than weeks. And after doing this for 10 years or so, it seems that you still can teach an old dog new tricks.
The cone of silence
The learning process, especially at age 35, does not benefit from distractions. I still can’t believe I could sit on my couch and watch a movie while studying in college or camp out in a noisy coffee shop and write portions of my thesis in graduate school. Now, it’s less about the TV or background noise and more about email barrages, social networks, and the new, new thing on YouTube. Perhaps the single worst feature of my Twitter client (TweetDeck) is that it is constantly squawking when new updates roll in. When I need to learn something new from the ground up, the cone of silence get’s invoked.
This doesn’t mean I don’t talk to my coworkers or answer my wife’s calls…quite the contrary, I’m usually asking coworkers plenty of questions and since my son has a health condition I always take calls from the wife. What it does mean is that I shut down my Twitter client, fire off a courtesy email to the rest of the company (and stop answering email), and buckle down for a day, or two days, or three if that’s what it takes. If a coworker is physically on fire and I have the only fire extinguisher, I respond. If not, then it’s going to be a day or two before I can get to that proposal you want me to work on. There are no ad hoc requests allowed from outside the office I physically sit in. Removing all extraneous distraction keeps me focused on the task at hand and allows me the deep dive that I require to wrap my head around something new. This cone of silence is also an excellent tool when up against a deadline on any project.
Find room to spread out
I can’t learn a new technology at home after work. I can read a book about it and make some notes and commit some of it to memory, but I can’t kick back, spread out, and mentally digest things. Wife, two dogs, cat, four year old…you get the picture. There’s a lot going on at home and working there usually means a single monitor machine or the netbook, and not a lot of room to make a mess. Learning something new is when our developer rigs at DTSAgile really shine: Comfy chair for exercising the typical bad posture of a developer; Big desks with plenty of room for scribbling things down in a notebook or two; Three monitors to spread out your IDE, Google, help system or API documentation, sample databases, etc., etc.; Additional desk space reserved from the latest offerings from O’Reilly or Wrox; Real estate for half drunk coffee from yesterday as well as today’s lukewarm addition to the collection.
I need room to roll up my sleeves and work. Having multiple information sources in front of my face at the same time speeds the learning process for me and is simply more time efficient. I’ve gotten to the point now where it’s actually an annoyance to have to hunt and peck on the Windows taskbar to find that great Google search result or pull up one of 5 sample VS.NET solutions I’ve got going. Call it ADD, call it information overload, it works for me…but it only works if I’ve got room to spread out, both in the digital world, and the physical one. If I’m truly going to leverage the wealth of information that’s available, I certainly need a big palette to work from, and an even bigger canvas to spread it on.
Know where you’re going
It helps immensely to have an example of how things ought to look when I’m done writing code. This doesn’t necessarily mean the user experience manifested in the UI or in the behavior of the service boundary, but rather the appearance and organization of the code. Knowing enough to write a dojo.subscribe() is one thing, but where is the best location to put that code given the context in which it will run? In a *.js file for a widget? In the page itself? In some generic widget controller? Dojo can be used to simply add a few shiny bits to a web client, but it is frequently used as a fully object oriented client application framework, making good patterns and practices very important.
Having reference implementation code, either from a previous project my team has done, or from another source is usually critical. If the technology I’m learning is fresh in the market, then I’m happy to give things a little more thought and blaze new trails, but if someone has gone down the path before me, then I definitely want a fully wired example to work from. Fortunately in this case, my coworkers had been doing Dojo development for awhile so I had a couple of good solutions to work from. Cheating? Lazy? Maybe, but why in the world would I not try to benefit from the previous experiences of others. It’s just good sense to know where you’re going…that way at least you’ll know when you’ve arrived.
Breaking stuff
I’m a tinkerer, and have been since childhood. What good is a perfectly working model, RC car, or a piece of software if you haven’t taken it apart, broken it, and put it back together again? One of my best resources during the learning process on a new technology is my tendency to tinker, pull things apart, and see what makes them work. Sure you could read about about the difference between dojo.hitch() and dojo.connect(), but it is infinitely more revealing to test drive both methods to see what works and what doesn’t.
My shop is in the consulting business, which means we need to be experts in lots of different technologies and we need to achieve that level of expertise quickly as technology evolves. The long and short of it, is that I learn best when I’ve gotten to the point of a working piece of software…and then go one step further. I have found over the years that the difference between kinda’ getting something, and really grok-ing what’s going on, lies in my tendency to want to break stuff and then put it back together so that I know what all of the component pieces and parts are doing. In the long run, this generally increases my code quality and readability because not only have I taken the time to learn what to do with a given technology, but I’ve also learned what not to do.
References and tutorials
I don’t think it’s too much of a stretch to say that for most developers these days, Google is the most valuable reference book on their desktop. However, those of you who have already jumped into the deep end of the Dojo swimming pool probably realize that:
- The API is not particularly well documented with comprehensive explanations and examples when compared to other APIs (JQuery, Prototype, etc.)
- There are two chief resources online for Dojo: The Dojo Campus (www.dojocampus.org) and the Dojo Toolkit Site (www.dojotoolkit.org), neither of which sits on a particularly speedy server or offers a comprehensive how-to library.
All Dojo peculiarities aside, even if I was learning ASP.NET MVC, Entity Framework, PERL, Python, Ruby or any number of other well documented technologies or APIs, I certainly wouldn’t rely entirely on what online resources could teach me.
Perhaps it’s because I was raised at a time when you still went to the local bookstore to find a good read, or perhaps it is because of the countless hours I spent working in my grandmother’s small town bookstore, I still like to have reference books around. Having two or three books on the technologies I’m actively working in means I can take a book to lunch and read up on a particularly hairy topic, I can look long and hard and dissect an example without blinding myself staring at the LCD, or I can take a volume home and read before nodding off at night. Absorbing information from multiple sources can only help the cause of learning new technology, and for me the thumbing of pages will always hold something that a scrolling a mouse wheel never will.
Conclusions
So there it is…you can in fact teach an old dog new tricks. While my learning process is probably not as organized and logical as that of others, it does work for me, and has allowed me to keep pace with what is turning out to be a rapidly changing technological landscape. What’s next? Well, the cone of silence is off so there’s probably a couple of proposals in my near future, but the Dojo work is nearing completion, it works well, and I can see Silverlight 3, Entity Framework, ADO.NET Data Services, and probably some Flex in my near future. I think I need a cup of coffee and a fourth monitor.
