Coulda, Shoulda, Woulda

I’ve been in Cambridge the past couple of days; two very long days at a Software Carpentry Boot Camp sponsored by Women in Science and Engineering (WiSE) of Boston. It was an intense time of learning, more akin to climbing the Mount Everest of learning curves than a classroom experience. Fortunately, the instructors divided the attendees (120 of us in all) into three groups based upon experience. I’m a novice in the realm of programming. I know my way around web design and its associated HTML, XML, and CSS, but when it comes to using “the shell” (as I’ve learned the terminal window is called), I’m a newbie.

Spending time writing out code to add numbers only makes me think, “Isn’t this why Thomas Edison invented the calculator?” Somebody already did this work for me. Still, I also once took an auto mechanics class so that I could learn how my car runs. I changed the oil a couple of times, then thought that there’s a reason Jiffy Lube exists, and let it go at that. There’s obviously a part of me that’s intrigued by how things work. There’s a part of me that definitely likes knowing that if I really wanted to, I could take the reigns (busted timing belts and erased hard drives aside).

It was that part of me that led me to sign up for the camp. In my work on research teams, I hear many of the same issues expressed when it comes to data management, information management, work flow and communication. I keep thinking to myself that surely there HAS to be a way to solve some of these problems, yet when I go hunting for the answer, I too often find myself limited by my abilities to work with open source programs that just might do the trick. My rationale for the self-inflicted alpine quest is that if I can learn enough to at least talk intelligently to someone who knows more about programming, then I’m better off than I was on Sunday.

And after the sprint to the top of the past two days, I’m happy to report that I’m at least there. Knowing more than I did on Sunday, that is.

I learned many things that are – fortunately for you, my reader – available online at the Software Carpentry website. Beyond the classroom instruction, they offer many self-paced learning modules, links to more information, suggestions on groups to join and/or where to find support. This is a marathon (to switch sporting event metaphors) that we’re on. Those books might claim that they can teach me Python in a day, but … well, we’ve obviously never met, me and the authors of said books.

But I did learn a good bit about the shell, “an interactive interpreter: it reads commands, finds the corresponding programs, runs them, and displays output.” That last sentence alone was new to me. I’m on my way!

I also learned about the scripting program, Python. Python is a dynamic programming language that lets you write “small programs quickly, and be able to manage the complexity of larger ones;” programs like C++ or Fortran. I learned that there are a ton of Python programs (modules) available, all ready to be plugged in to help the knowledgeable person accomplish a task or two. And again, that was my goal going in, i.e. to become knowledgeable enough to know that somebody else has already written the tool that can help me. And after the practice of boot camp, I at least know how to play with them enough to not destroy my computer.

Quick aside: On Sunday night, I dreamt that my computer literally blew up in my face. Ka-BOOM!! Pieces everywhere. I ducked and covered my head, escaping any real injury. Pre-programming camp anxiety, Dr. Jung?

I learned about GitHub and how individuals and teams can use it to share and/or collaborate on projects that involve coding. I learned about version control, something we librarians know an awful lot about already. I learned about SQL and found myself dragging up old tricks from days of building databases in Access, back when I managed HR records for a company. I remembered how much I’d forgotten about writing queries in that format. I also couldn’t help but notice how much of what our instructors taught in this section is what I teach when I’m instructing students and researchers on using PubMed. Same principles, really. Good query construction is good query construction.

Which brings me to a really significant thing that I learned – perhaps the most significant, in terms of relevance to my work as an informationist and the whole world of embedded librarianship that is open to our profession. The boot camp was taught (with the help of a whole bunch of roaming helpers) by two PhD researchers (bioinformatics and biology) who learned most of what they know because they taught themselves. Why did they teach themselves? Because they had to do somethings for their work that they  just knew could be done easier, more efficiently, and better through the use of certain programs.

Hold it! Scroll back up the page and re-read what I wrote in the third paragraph. Go ahead, I’ll wait…

Did you see it? I took this class because I sit on research teams where people continually express the need(s) for something to get done, yet no one has the time and/or inclination to solve the problem. In other words, I am sitting in the exact same seat that the two women who were standing in front of the class for these days once sat. They are both scientists and neither one computer scientists. I doubt that when either of them began studying whatever their discipline is, they anticipated becoming programming instructors. But they did. They are. Because no one else could/would. They took the initiative.

This was an incredible insight for me. I knew that a lot of young students in the Graduate School of Biomedical Sciences know computing. I assumed it’s because they studied it formally. I assumed it’s because it’s something that came along in their tool kit as scientists. What I’ve now learned is that this isn’t the case at all – or at least not in the vast majority of cases.

Scientists learn things because they need to learn them to solve a problem. If we take the initiative to learn the same things, imagine the value we suddenly bring to a team that has no such person on it already. Both Tracy Teal and Sarah Supp, the lead instructors in my class, admitted that they had opportunities in their careers open up to them because they had taught themselves these skills. It’s not a skill set that every scientist automatically has. They added it to theirs.

The audience for this boot camp was scientists and engineers, colleagues of Tracy and Sarah and the other instructors in the other classes. They see the need to bring these lessons to other scientists, because it’s clearly (1) missing and (2) beneficial to both the individual scientist and research as a whole. As an embedded librarian/informationist, I wasn’t their target. I doubt that they could have even imagined why I was there (along with a couple of other familiar faces). But what they don’t know is that there are others out there, people like me and others doing similar work, who can take these same lessons and apply them to the research teams that we are part of.

Some of the teams where I’m working have programmers on them, but not necessarily to do the things that I’m brought on to do. Further, they are often computer programmers and lack the specific science background that an informationist brings to a team. They have a really advanced skill set in programming and I’m hardly one to take on that role, but for other projects; projects within the greater Research Project, I’m pretty sure that I can learn enough to bring something that’s valued to the team. That’s what I saw in the researchers who taught me the past days. And it was a great, unexpected lesson!

————————-

One other thing that I was reminded of last night that also just happens to have some relevance:

As I was in the big city of Boston on the same evening that my friend, Suzy Becker (you might recall her as my hero from a post a few weeks back) was giving a reading / signing to promote her new book, One Good Egg, at Brookline Booksmith, I slogged across town on the hottest day of the year (because that’s what friends do) to enjoy the event. Plus, there was free cake. In a short documentary by Mollie West, Suzy mentioned that she tries to take advantage of the early hours of the day, writing and drawing before her inner critic is awake. I jotted down a note that it’s a good rule to follow in the context of learning something as daunting as programming, too. I need to try and set aside time during each week, preferably early in the morning, to work on honing my new skills before my inner “you’ll never learn how to do that!” self gets going. Message to heart.

Tags: computer programming, database query, Git, GitHub, Python, Software Carpentry, SQL, Team Science, version control, women in science and engineering