Tag Archives: Team Science

Learn Something New Every Day

27 Aug

My spouse recently got a call from a couple of faculty members in the computer science department at the college where she teaches. Lynn teaches in the art department; graphic design, motion design, typography, and the like. The computer science guys wanted to explore the possibility of her teaching a course in data visualization. Knowing that I have both an interest in the topic, plus the need to fumble through learning it (and using the new-found skills) for my job as an evaluator, she asked me what I thought about the opportunity.

Lynn knows enough about data visualization to know there’s a computer programming aspect to it. The computer science guys know enough to know there’s a design element to it. They all know that there’s math involved, specifically statistical analysis. I also suggested that it involves writing and/or journalism. She was hesitant – and rightly so – to jump on board without thinking and talking it through, because what she is an expert in is only one area of a multi-disciplinary field.

“It’s team science,” my boss, Nate, said when I shared the story with him. Exactly. And in many ways it’s an example of how the ways we traditionally teach, research, and work need to be re-examined and re-worked.

Too often, I find, we search for collaborators within our own circles of expertise. Librarians collaborate with other librarians. They might be from different types of libraries or different library departments, but often we’re all librarians. Researchers collaborate with other researchers. Scientists with other scientists. In some ways, it can be argued, this is team science (or team-based work), but it falls short of the ideal.

At it’s best, team science brings together experts from across different disciplines to work on problems that simply cannot be tackled by any one group. Think about a health problem like obesity. It’s huge and as such, touches upon so many different aspects of life. Addressing it requires everyone from geneticists to behavioral psychologists to nutritionists to exercise physiologists to public policy makers to urban planners to educators to medical doctors to parents to science writers to … it’s probably easier to identify the experts not needed than those who are. The point being that some of the most successful efforts at addressing obesity are those that bring as many of these fields of expertise together, to work together towards a solution. (The UMass Worcester Prevention Research Center is an example, close to home for me.)

But back to data visualization, what I’ve found is that those who do it best are either freakingly gifted (there’s always an Edward Tufte in any area) or they’re smart enough – and talented enough – to assemble good teams for the work. As I’m seeking to discover the best resources to learn and practice the skills for this job, I’m continually reminded to look across lots of different disciplines. I look to evaluators (Stephanie Green and Chris Lysy), graphic designers (Nigel Holmes), business intelligence consultants (Stephen Few), journalists and journalism professors (David McCandless and Alberto Cairo, respectively), artists (Manuel Lima), statisticians (Nathan Yau), doctors (Hans Rosling), and the people in my very own Quantitative Health Sciences Department. I read things by people who are good presenters, experts in visual communication, and those skilled in improvisation. In other words, while I’m limited in resources to actually form a real team of experts to do data visualization for the UMCCTS, I’ve learned enough to seek them out from across lots of corners so that I can do a better job. (I’m also lucky enough to be working in an environment where people don’t mind me trying things out on them. It’s a benefit of being in academia.)

Thanks to Chris Lysy’s (DiY Data Design) weekly creative challenge, this week I practiced using design icon arrays to report on the findings of a course evaluation with a small (n=15) class size. We get so hung up on “big data” that it’s easy to forget the real challenges of working with and presenting the results from small data sets. I really enjoyed taking this challenge and putting it to use. Here are a couple of examples. For the sake of privacy, I’ve redacted the questions being reported.


Sample Arrays

Now, here’s one lesson that I learned for the next time that I use this visualization device. I need to make them like this:

better copy

This example allows me to better show that each response is represented by a single box, thus 11 people answered “Yes” and 4 answered “Somewhat.” Live and learn. Every day.

Next Tuesday, I’m taking a workshop on creating podcasts. It’s something that I’ve wanted to try and I found a 2-hour, evening class in Boston. Stay tuned to see what that new learning might bring. 

Coulda, Shoulda, Woulda

25 Jun

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.

Learning Curve

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.

Absence Makes the Heart Grow Fonder

6 Jun

I’ve been away from work for almost a week, spending time with my father and doing those things that make people say, “Oh, you are such a good daughter,” despite the fact that I wasn’t feeling like one. Watching your parents age, as well as helping with things that come along with the aging process, is difficult. It can bring out both the best and the worst in you.

outofficeThe time away also made me miss my Librarian Hats blog. I missed time with my teams and I missed time in the library. I missed my projects and the work that I’m doing and the weekly sharing of that with all of you. It’s great to get away. Anyone who knows me knows that I’m hardly one to shy away from a break from work and I’ll never turn down a good vacation, but it’s also a really nice feeling to know that I’ve come to a place where I enjoy my work so much that I miss it when I’m away. Fortunately, I know a lot of people in this profession who feel similarly. It’s a nice bonus for being a librarian.

Last week, before leaving town, I had the chance to speak at a staff development day for the librarians at Tufts University in Boston. I always like getting to meet colleagues outside of the health sciences and/or medical library world. While Tufts Medical School librarians were present at the event, so were others from their different libraries, making the meeting a great chance to hear about some ideas, projects, innovations and tools that I don’t usually stay up to date on. Discovery tools and on-demand purchasing are the kind of topics that don’t make their way across my radar, so it was a nice opportunity to hear about them.

Two librarians shared their experiences being embedded in different programs and projects. Regina Raboin, Data Management Services Coordinator and Science Research & Instruction Librarian for the Tisch Library at Tufts described her work as part of the faculty teams for 4 different undergraduate courses. A couple of things that Regina said that really struck me, (1) “I was part of the team” and (2) the courses that she was embedded in were all multi-disciplinary in nature. A couple were in environmental studies and the other two were seminar courses. In other words, the classes involve bringing together faculty from different parts of the campus – different schools, different disciplines. This reminds me of what I’ve experienced in my work as an informationist, i.e. all of the studies and projects that I work on require a lot of different kinds of people with different skill sets in order to be successful. I wonder if this isn’t an important key to librarians finding a home on research teams. When the team is made up of people from lots of backgrounds, no one discipline and/or skill set dominates. Team members naturally look to the expertise of the different members, making the skills of the embedded librarian and/or informationist not stand out as such a foreign thing, different from everyone else.

Jane Ichord, a clinical librarian for the Hirsch Library of Tufts Medical School shared her experience being embedded one day each week, attending rounds and working with the pediatricians and other providers at one of their hospitals. Jane also mentioned a few things that I wrote “blog” next to in my notes, my reminder to myself to expand on the thought in one of my posts here. First, she said that when she was first asked to take on this role it was several years ago and while she really wanted to do it, the administration and structure of her library at the time were not in the right place for it to happen. More recently though, things changed and she was given the okay to pursue the role. One cannot stress enough how important this is in the success of embedded librarian programs. Library administration has to be supportive in time, structure, direction, and mission for these programs to work. Librarians wanting to become embedded have to feel empowered to make a lot of decisions on their own. They have to know that it’s okay to be away from the library. They have to be assured that their bosses trust them to build relationships. I feel really fortunate in my current position that this is true, but like Jane, it wasn’t always the case. We weren’t always ready for me (or others) to take on this role. However, when I heard my director say that she would give me the role of informationist on the mammography study whether we got the NIH grant or not, I knew that she was fully supportive of the work. It’s that kind of attitude that gives a librarian the feeling of autonomy necessary to become fully embedded in a team.

Lastly, Jane said regarding her Mondays at the Floating Hospital, “It’s changed my life. Well, it’s changed my work life.” When it comes to my own experiences as an informationist, I can’t say it any better. I have the job today that I always wanted in a library, even when I didn’t know it existed. Heck, even before it did exist! And I’m happy to be back at it today.