Craftsmanship Tour: David W. Allen
« XML Crash Course
» Craftsmanship Tour: Jim Ray
Code: craftsmanship tour, graphs, NearbyGamers, software craftsmanship
I’m in Grand Junction, Colorado because it seemed as good as any a place to start traveling. I have family in Denver and plans to ski, so why not tour the state a while? Once I knew I was coming to Grand Junction, I remembered GitHub can be searched by location and I got curious, so I did the search.
One result? If there’d been a hundred people I’d have been done right there, but if there’s exactly one person, well, why not say hi? So I sent an email that I think sounded like this:
I realize I’m a complete stranger and the idea of wandering into people’s offices to work with them for a day sounds perfectly ridiculous, but would you like to grab coffee, talk code, do some pair programming?
Perhaps I didn’t come off quite so badly because David said “what the hell” and invited me to meet him for his workday at Traders Coffee.
A side story: I happened to arrive before him and was looking around for him, and couldn’t see him. But I saw a woman surfing Stack Overflow! I thought maybe this was someone David knew and invited along, so I had an awkward conversation where it quickly became clear she had no idea who I was or why I was introducing myself. If I’d been thinking quicker I’d have invited her to join us or at least given a business card, but my generic nerdly social phobia overwhelmed me and I excused myself. If you’re reading this and someone interrupted your Stack Overflow session to ask if you knew a guy you’d never heard of, sorry for the confusion, but if you’d like to grab coffee, talk code, maybe do some pair programming, I’m in town until Friday afternoon.
As David and I sipped delicious lattes, I learned that he’s a mechanical engineer who got into software development around ten years ago as his job changed. He’s self-taught, he cracked the books and started experimenting. Along the way he attended some Construx Seminars. Construx is the software firm started by Steve McConnell, the giant who strides above programmers bestowing books of wisdom and lore, so that gave David a good grounding.
A lot of our conversation was about how David has found it hard to improve his craft without other, ideally better, programmers around to work with. It’s referenced by the community aspect of the Software Craftsmanship Manifesto. Programmers improve their craft by improving each other’s craft.
As an example, David told me about his startup project veloGraf. He and another developer are using graph algorithms to analyze social networks and I soon realized I only know enough graph theory to hang onto the ankles of the conversation. I hadn’t thought about it before, but David pointed out that game tags on NearbyGamers form a highly cyclical graph. Gamers add edges to the graph by listing what games they’re interested in playing and tags self-referentially describe themselves (eg. Dungeons and Dragons is tagged as a an RPG).
I demoed the site’s most computationally-expensive page, which shows gamers who share tags, sorted by distance. This page required some hacking to avoid a gigantic couple of joins that would’ve dragged in most of the rows in the RDBMS, but David chuckled because it’s the sort of problem a proper graph database doesn’t even notice. He’s tracking millions of nodes with many times more edges in order to extract interesting connections. The simple analyses he pointed out flaws in common algorithms that were obvious to him but surprising to me. I managed to give him some fodder for experiments to improve his algorithms, which says more about the value of a little collaboration than it does my graph chops.
David told me a tale of (mild) woe from a previous job. An experienced cowbody coder was developing the core of a product while supposedly mentoring interns. In reality, they were restricted to working on small, ancillary tasks so as not to destabilize the core or distract the cowboy. How do you fix this?
My best guess (share yours in the comments, please – it’s not an uncommon scenario) was to task the interns with adding automated testing. The cowboy will think of it as menial work, but the interns will be exposed to the whole system and have reasons to have conversations with him. And probably better to start with acceptance testing than unit testing to preempt the cowboy from whining that using unit tests to verify that his code works (as opposed to hack and hope and oh yeah, I forgot those two things were related) slows down his brilliance.
There’s a complacency I’ve seen that’s sort of related to the Blub Paradox. When a programmer succeeds at building their first product or two, they often get an panglossian sense of competence. They may think, “I’m good at my job, there’s people telling me I should learn these things, but I’m good at my job without them, ipso facto I don’t need to learn more.” Unless they’re around a noticeably better programmer or especially introspective, they may never realize how much more there is to learn and the possibility of much greater skill.
I think this is where net negative producing programmers come from. I joined a project with an NNPP once. I watched all commits to the repository (everybody does this, right?) and I realized nearly his every commit added a bug or the strong potential for future problems. There was feedback available in the rising bug count and frustration of trying to improve the codebase, but he didn’t have the experience to know that this experience was abnormal. (Or at least improvable.) As I and other developers started cleaning up the code, he recognized what had been happening and decided to reinvest in his career by attending training.
I think this is why the nascent software craftsmanship movement has such potential. Programmers need to make steady improvement, however small, a core value of the profession. Currently there’s a “well, it works” when practice and mindful improvement could be a precept. The likeliest way I see that happening is masters of the craft mentoring apprentices. Every craft has its share of “just get it done”, but it doesn’t have to be the dominant culture.
Update: David has blogged his thoughts on our wide-ranging conversation.