Developers, Developers, Developers, Developers
Brad Feld posted a request for resources to help teenagers learn to program on his blog, and after writing my comment I got to thinking about my own history doing software development. Brad’s question has been one on my mind lately because my cousin’s 15-year-old kid (my first cousin once removed for those keeping score at home) has been wanting to learn to program applications on his iBook for quite some time. His Dad knows some other people who have given him pointers, but more than a few times in the last couple years we have had lengthy IM sessions about his frustrations in trying to get the machine to do something meaningful. I have pointed him at several resources, and I think he’s starting to get into it, but the bottom line is that programming computers involves a lot of mundane and often maddening minutiae. Trying to start with building Cocoa-based applications on the Mac as your first programming task is probably the wrong way to go, but my attempts to get him to start with javascript in a web browser (where he’d get much more instant gratification while learning some basic concepts of variables, looping, conditionals, functions, expressions, etc.) have failed.
Mind you, I am not what I would consider a “real” programmer. Sure, I have several years of hands-on experience building database-driven applications on the web. I can get my hands dirty with most web-related technologies and just about any RDBMS, and I have decent experience in application architecture, software lifecycle, and various other trappings of the software developer. But, it would be downright disrespectful to the talented software engineers I have had the pleasure to work with over the years to think of myself as a true peer. My schtick has generally been more to know enough about the nuts and bolts to have a meaningful conversation (and to be an effective manager) but then be able to cross over and go deep on market positioning and brand strategy discussions (something that most of the software engineers I know would avoid like the plague).
I remember when we were selling the first company I started (an asset sale, to be specific). At the time my partner and I were still writing most of the code for our clients, and the Managing Director of the firm acquiring us (our new boss) had a talk with us about the choice we would face about stepping out of hands-on development work. Basically he was saying that once you head down the path of management you have to accept that your technical skills will become progressively obsolete and eventually be all but useless. I’m not sure I totally agree, and I do try to get my hands dirty in code once in a while just to try out new stuff, but his basic point is certainly valid. As I have moved on to various non-technical roles I have found that my hands-on experience is still invaluable in helping me to understand the implications of various management decisions around software projects. Such an understanding is far too often lacking in those making such decisions around software projects — ask any developer you know if you doubt me. I even once started writing a book that was a primer on the software process and culture for non-technical business managers (hmm, perhaps fodder for future blog posts…). Hopefully my natural geeky tendencies will give me enough lasting street cred to avoid PHB syndrome….
(By the way, for those of my readers not steeped in geek culture, the title of this post refers to, well, you should see it for yourself [and don’t miss the remix])