Teach While You're Learning Yourself

There's a (pretty reasonable) theory that the best way to learn is from the experts. They know what they're talking about, right? It makes sense, and those who have studied and worked in an area for years have valuable insights to share. They know the pitfalls, the broken assumptions, the brilliant hypotheses and they can communicate them.

But the experts have their disadvantages. The fundamentals are so ingrained in them, so second nature, that they speak a different language. A technical term on their lips has an intricate history, labyrinthes of connotations. The neophyte, on the other hand, has but glimpsed the adumbrations. They've learned a term only to find out their understanding was slightly askew. Their confusion is laden with value, with the very undulation of learning. It should be harnessed while it's prime.

Enough Abstraction Already

I'm engaged in a community of librarians who are steadily leveling up their technical skills. A lot of this happens in the Library Codeyear Interest Group (come to the Python Preconference at ALA!), but also on the ACRL Tech Connect blog where our posts are less prophets handing down commandments than regular ol' librarians sharing their inchoate knowledge.

A specific of example is the Codeyear IG's GitHub Project, which I started (though feedback from participants and Andromeda Yelton has been invaluable). I started the project despite being mediocre at Git and GitHub. I am not a software developer. Sure, I have a deceptive number of projects on my GitHub account, but I'm thoroughly amateur and still make embarrassing mistakes.[1] But that hasn't hindered the project's efficacy: we've had ten people complete the Getting Started tutorial and many more read the Tech Connect blog posts on it. If nothing else, it's upping the community's exposure to and understanding of awesome tools like GitHub.

Part of the success of the GitHub Project, I hope, is my ability to write for beginners. Having just started using version control myself, I'm hesitant to employ Git terminology which is familiar to people coming from other VC systems but not to people new to the whole class of software. For instance, rather than write something like git commit does just what it says: it stores the current contents of the index in a new commit along with a log message from the user describing the changes it's obvious that the commit command finalizes our changes and adds them to the project's history is a better explanation. But even with my valuable inexperience, I still assume familiarities that don't necessarily exist. An early participant noted that the keyboard shortcut to exit the git log command was never mentioned (it's the letter q, by the way). This is precisely the sort of key detail that is lost on experienced users. I'm no command line expert, but I know that q exits the less pager. It was a real hangup for me when I was learning, but now that I press it several times a day, it's cognitively absorbed. I forgot that it was something I had to learn, once upon a time.

Old News

Pedagogy has known that experts do not make great teachers for awhile. We've all heard of the move away from the "sage on stage" to the "guide on the side," which is related to the critique of top-down knowledge transmission. Other current movements, like "flipping the classroom" where lectures occur outside of class while time in the classroom is used for group projects, also come to mind. But we often fail to carry these lessons over to professional development; when you schedule conference sessions, do you look for Delphic panels like Top Tech Trends or amateur confessionals like Drupal Fail? More importantly, do you stop yourself from writing to a listserv, tweeting, blogging, or proposing conference sessions because you feel too inexperienced, too fraudulent?

A lot of librarianship is learning, whether it's how to teach information literacy or how to code, and we benefit as a community when everyone shares their own lessons. Go forth and edify, ye novices.

Footnotes

1.^ The history of my fork of a dotfiles repo has damning evidence. There's weird looking stuff if you run git log --pretty=online -n 50 --graph for what should be a fairly straightforward project.