Curriculum Vital - How do Developers Like to Learn?
Posted by InnerWorkingsSD Times
By David Rubinstein, SD Times
May 1, 2005
How do developers like to learn? Many read books that are relevant to their practice. Others rely on co-workers or developer Web sites to pick up tricks and shortcuts, and still others attend technical conferences to learn from the vendors of the software they use.
There is, though, one thread that runs through all the choices: Developers like to learn from other developers. Don’t give them academics. Don’t give them so-called “experts” in a field. And for heaven’s sake, don’t give them marketers. Developers truly believe that unless you’re a developer or you’ve been a developer, you don’t know the trouble they’ve seen.
Fran McKeagney learned this while at CBT Systems, a California-based company providing interactive education software. “We had a hard time reaching software guys,” he said. “We just weren’t getting usage with the software guys.”
When he founded InnerWorkings in 2002 with the goal of providing educational tools for developers, he learned his audience had been rejecting training materials written by technical writers. “It was clear to the developers that these people didn’t make a living writing enterprise code.” The learning industry just didn’t adequately support the developers, he said.
Since that time, numerous educational and training Web sites have arisen, and books and downloadable tutorials remain plentiful. Attendance at technical conferences is finally rebounding to levels not seen since the dot-com implosion. Many of these are created by developers for developers. JavaOne, Tech-Ed and myriad other user conferences provide hands-on learning. DevX, IBM’s alphaWorks and MSDN all have large, thriving developer communities. But McKeagney says something was lacking - the ability to work at your desk, in a tool you use, at your own pace, to improve your skills.
Something else was missing, he believed - a way to get a developer from the competency he or she showed to get a job to becoming much more effective on the job. “Classroom teaching is conceptual,” he said. “It’s like reading a book on building a house and then going out and doing it.” Developers, they learned, are being challenged like never before, being asked to “do more with less” even if their skill sets aren’t quite up to par in certain areas.
So McKeagney and his team developed software called the InnerWorkings Developer Interface, which includes something they call the Inferent code-judging engine. The software provides users with challenges that describe the objective and offer a problem statement, and the developer builds the application and runs it. There are constraints as to what not to do as well as links to reference materials, hints and an e-mail link to a personal tutor.
After the application is built, the user clicks on the “judge” button, and a score is returned. If errors were made, very specific feedback is returned. “It’s a safe learning environment, but it’s real-world,” said Brian Finnerty, director of product marketing.
InnerWorkings has collaborated with Microsoft to integrate its software into Visual Studio. The first practice set of challenges deals with developing for ASP.NET; currently, there are eight hours of coding challenges, involving such topics as Web controls and exception handling. By the end of the year, the company hopes to have hundreds of hours of practice sets; Finnerty said the next sets in the works are for Web services and object-oriented design and development.
For people worried about having a development process forced upon them, McKeagney said the reference materials and judging engine are based on Microsoft Patterns and Practices Group information and the Microsoft curriculum. In the future, he added, the tool might be able to accommodate a company’s best practices, so that the training of new employees becomes more standardized. Armed with US$8.8 million in Series A venture funding, that should happen sooner than later.
Listen, I certainly understand people who hate being forced to change the way they do things. I started in this business writing my stories on a Royal manual typewriter. Then I was forced onto an IBM Selectric, which had a unique set of characters that had to be typed into the text to instruct a scanning machine what to correct or omit.
Since then, I’ve had to learn a number of different applications, each with different nomenclatures and symbols for typesetting instructions. And I went kicking and screaming every time. If it were feasible, I’d go back to my manual typewriter in a heartbeat. Has learning these different systems made me a better writer? Microsoft Word certainly has made it easier to clean up my mistakes, but it doesn’t help me with story organization, sentence construction, or those colorful turns of phrases we writers live for. But it hasn’t hurt me either. So if learning some new best practices can make you a more efficient programmer, without hurting you from a creative perspective, the benefits are clear - if not to you at first, then certainly to your company. Old dogs, like the one seated here, can always do with some new tricks.
David Rubinstein is editor of SD Times. This article was reprinted with permission from SD Times May 1, 2005.
