jonathan@researchcomputingteams.org
Issue #140 was controversial, but not for the reasons that I thought it might be. In the last two weeks I’ve had now had several people flat-out deny this claim:
There are core facilities all over your institution which get much of their revenue from fee-for-service quite successfully.
saying, essentially, that such a tawdry arrangement would never be tolerated at their institution. In each case, googling “[Institution] core facilities” returned lists of teams that nonetheless did exactly that.
I’m not at all surprised that we still have so much to learn about other technical research support teams even within our own institutions. I’d like to change things, though.
One of the recurring themes of this publication is that isolating ourselves by type of work we do is a mistake. That’s true whether we’re considering growing RCD silos between compute, software, and data, or existing silos between (say) RCD teams and biomed cores and data science institutes and stats help desks.
From funding to working with research communities to product management to technology, all of our needs are the same, our goals are intertwined, and our boundaries are growing fuzzy. We have much to learn from each other and how we approach our common issues, even if we chose to use different methods.
In the coming months, I’m going to try something a little different. I’ll see if I can interview members of different sorts of teams so that we can see how the various kinds of groups handle these shared challenges. I’d like to start with a bioinfo core leader. I’d also like to interview research software, HPC, data management, and data science team managers. Let me know if you’d volunteer - I know that there are several members of each community who are readers! We can do it in an anonymized version if that’s a worry.
Lack of awareness isn’t the only problem I see about our relationships with other teams. I’ve been in a couple of meetings this week where other teams were referred to as competitors. And that’s not really right, either.
Our goal, as leaders of our research computing and data teams, is to advance research and scholarship as best we can.
But the scientific needs of an entire research organization are almost limitless, while our teams’ resources are very much limited.
That means there’s going to be valuable work, useful work, interesting and challenging work, work our team could help with, that our team is nonetheless not going to do. Meeting all of everyone’s needs is not and has never been an option available to us.
Our competition, such as it is, isn’t other technical research support teams. Our competition is that research going unsupported. Our competition is students and postdocs spinning their wheels trying to do something they don’t yet have the tools or knowledge for, spending too much time to do a poor job. Our competition is less and worse science.
To fight that competition, the true competition, we need to not just know about but actively collaborate with other teams, inside and outside our institutions — even from the private sector. We need to be prepared to redirect researchers to those other teams when they can get better help there. And in turn, we need to focus our energies where our team is the one best equipped to help.
None of this is to say that our institutions and funders don’t sometimes put us into competition with those other research support teams - for a new hire or for operating funding. But the knowledge of those other teams allows us to position ourselves in the context of our research institution and research community, which makes it easier to advocate for ourselves and our teams in that context. And the existence of these other teams which allows us to nurture a specialty, which amplifies our impact by focussing our growth and our efforts.
And now, on to the roundup!
Prepare for Workplace Conflicts with a few “Go-To” Conversation Starters - Karin Hurt
It’s pretty common, especially for those new to leadership positions, to know generally the right thing to do, but not know have the right words at hand to nudge things in the right direction. Having short little scripted phrases filed away that you practice using can be invaluable, especially in heated situations.
Here Hurt outlines twelve such phrases for you. I was just going to excerpt those that were particularly useful for us, but that’s all of them! The article explains when and how to use them, and variants.
Remote Work Conference - Stanford University
Interesting set of talks on remote work and remote collaboration, which has long been a thing but is now getting even more attention. Interesting talks here on remote knowledge work (including science collaborations, which apparently were measurably less productive than colocated teams until about 2010 or so).
There was a short section on hybrid work here, too. Work on hybrid teams is just starting - we don’t even have widely accepted words yet for the different arrangements that all fall under the umbrella term of “hybrid”. But right now there’s more opinions than facts about hybrid work; it’ll be good to keep an eye on sessions like these to see what does and doesn’t work, and how we would know.
Leadership SLAs - Aviv Ben-Yosef
Establishing service-level agreements with ourselves is surprisingly effective for some people. “I provide feedback within one business day”, “I give everyone on my team at least one piece of feedback per week”, “I respond to clients by the end of the day”, “I make two hours a week for professional development”… there is a lot of research supporting this kind of commitment as a way of driving behaviour. (Maybe it’s a bit cliché, but I find writing them on sticky notes and putting them on my desk works very well for at least beginning a behaviour change). Ben-Yosef gives some examples in this article.
#42: How to Answer Hiring Manager’s Questions in Interviews - Candost Dagdeviren
Moving into leadership positions is the first time most of us in research have ever had to answer behavioural interview questions. A commonly recommended framework for answering those questions - Situation Task Action Results, STAR - is one good way of communicating answers to (many) questions of that form. (It’s a handy outline for clearly structuring short work-related “what we did and why” stories in general, in fact).
Dagdeviren describes the structure and its use in articles in this article.
(Bonus pro tip! If you’re find yourself needing to suddenly prepare for a job interview, you can do a lot worse than going through every X in the “responsibilities” section of the job listing and preparing short STAR answers for questions of the form “Tell me about a time when you did/demonstrated X”. Even if you don’t get asked that exact question, you’ll likely to be able to make use of the answers you’ve prepared. Even better, other jobs you apply for will likely have overlapping responsibilities, so these stories can be used across jobs.)
Ten simple rules for a successful international consortium in big data omics - Stobbe et al, PLOS Comp Bio
Collaboration is work, and large collaborations are a lot of work.
This “ten simple rules” article is written by people who have done more than a few of these kinds of consortia projects, and they know what they’re talking about. Revealingly, only three of the rules (5: build in checks; 7: keep track of code/data provenance; 8: keep up the pace) are really about the scientific work itself. Almost all of the discussion is about the unsung meta-work that has to be done to keep a large consortium functioning and moving forward.
If you or someone you work with is entering such an effort, make sure the appropriate people read this and take it seriously! Much of this stuff sounds obvious, but it takes real effort. The most common way I’ve seen consortia not really live up to their potential is when groups see rules like Rule 1 (“Set up a transparent and effective governance”), Rule 2 (bout setting clearly defined goals), or Rule 3 (about using the right terminology internally to communicate) and thinking “We don’t really need that; we all know each other, it will be fine.”
The final Rule (“Be the giant on whose shoulders others can stand”) is really nice to see here. After all the enormous work that goes into a consortium project, seeing a successful one wind down leaving nothing behind but the papers that got written is incredibly disheartening.
Scientific Publishing: Peer review without gatekeeping - Eisen et al, eLife
Transparent peer review for all - Nature Communications
Interesting week in scholarly publishing; eLife announced that they will no longer be accepting or rejecting papers that they’ve sent out for review; instead, all reviewed papers will be published online, as a Reviewed Preprint, along with the reviews. Quoting from them:
The system of science publishing we have today was not developed for today’s science or today’s technology. Its defining feature, a hierarchy of journals that use peer review to decide which papers they will publish, arose in the last century as a response to the limitations and costs of the printing press and the postal service.
and
We have found that these public preprint reviews and assessments are far more effective than binary accept or reject decisions ever could be at conveying the thinking of our reviewers and editors, and capturing the nuanced, multidimensional, and often ambiguous nature of peer review.
Although eLife doesn’t call it that, submissions will still basically be subject to desk rejects — eLife’s capacity for reviewing preprints isn’t infinite.
Meanwhile, Nature Communications will be publishing reviews of all papers:
Starting in 2016, we have offered authors the option to publish the comments received from the reviewers and their responses alongside the paper. As we believe that transparency strengthens the quality of peer review, we are now moving to publish the exchanges between authors and reviewers for all research articles submitted from November 2022 onward.
How KEK changed how everyone in Japan does CryoEM (Part 3 of 4) [Video] - AWS HPC Tech Shorts
KEK’s new cloud infratructure for CryoEM is certainly cool, but that’s not why I’m including it here. Instead, this video is just a nice example that crossed my desk this week of communicating the impacts digital research infrastructure. Note that the “speeds and feeds” stuff only comes later, in section 4; here the focus is on impact. Stories about scientists shipping hard drives of CryoEM data and waiting for weeks for results, or only finding out at the end of a 24-hour run that their data was contaminated, and so useless, versus people being on a video call while the data is being generated, giving feedback on the experiment in real time so changes can be made. And doing further analysis of data on the train. And then the impact of there being a pool of data and tools available nationally.
Those stories leave vastly more of an impact on decision makers than tables of numbers!
Note too that this isn’t some slick, high-production value marketing video that only industry can afford to do - it’s a recording of four technical people happily chatting on a Zoom call, with a little editing afterwards.
Demonstrating Importance and Value in Research Software - David Wilby
Tying in very nicely to the above, Wilby writes a great article about demonstrating the importance and value of research software projects and products, focussing on impact. Read it! His categories of evidence are:
And closes with this, which I completely agree with:
Try to collect evidence proactively - It’s easier said than done, but try to plan ahead for a project how you might collect some evidence, it’s not much fun but it will pay off in the future when you don’t have to desperately scrabble for it - take it from me!
You will always, at some point, need evidence, if only for your resume down the road. And once you have evidence, especially great quotes or numbers, and specific examples of research impact, you will find endless opportunities to showcase it!
Can We Use Trunk-Based Development for Legacy Software? - Burkhard Stubert
Trunk-based development is great because it encourages incremental changes and rapid iteration. But legacy software, without a detailed test suite or a clear path to getting one, makes this approach challenging.
Stubert gives us a few tools to try to to move developmennt on a legacy codebase to a trunk-based approach:
2021-2022 Research Data Services Annual Report - Christina Maimone, Northwestern Research Data Services
I like sharing documents like these so teams can see what other teams are doing and how they are communicating their outcomes - here Maimone provides a nice crisp document outlining what services they offer, with numbers of how they’re used, and some of the significant research and scholarly outcomes they contributed to.
The previous report was as a PDF. I think they made the right decision moving to a web version; being trained in research, where everything is PDF papers, and then thrust into University administration, where everything’s glossy documents, often our first inclination is to make a professional looking PDF. But after you do that a couple of times you realize it’s more work and fewer people read it than a professional-looking web page.
Another nice benefit of a web format, since it’s easier to create, is that it becomes possible in future iterations to have different versions of it for different audiences. For instance, funders probably care more about external impact than potential research clients or institutional decision makers, so it could be moved higher in a funder-facing version. It also becomes easier to add less-structured sections people can open up giving longer discussions of particular projects, and (connecting to Wilby’s article above) helpful quotes from the researchers or end users of the product. Never underestimate the power of a story plus a visual plus a pull quote!
IBM builds Diamondback tape library for enterprise and cloud hyperscalers - Chris Mellor
I’ve been hearing “tape is dead” for basically my entire career. Maybe this is the year! But it probably isn’t. For as long as it has a cost, density, and energy advantage while being fast enough for some use case, tape will be with us.
It is interesting to see how the times change how tape is positioned though - here IBMs new Diamondback system fits in a or on OCP rack (the choice of hyperscalers) and can be a standalone option or part of a distributed, scale-out “Redundant Array of Independent Libraries”.
Intel Is Opening up Its Chip Factories to Academia - Agam Shah
Moore’s law is dead, or at least in parlous health, depending on who you ask. So custom silicon for niche research computing applications is starting to become imaginable again. (Anyone else remember GRAPE for N-body calculations?). The advance of EDA tools, which to this outsider seem to be making faster progress than FGPA programming tools, helps. So does the growth of fab-as-a-service, which allows silicon makers to continue to make money from older, larger processes while ramping up their newer technologies.
Here Shaw reports on Intel making it easier for academics in particular to get small batches of chips fabbed. Even better, it’s somewhat subsidized by an industry and government that recognizes the need for increasing semiconductor workforce development.
An interesting sign of the times is that SPEC is developing a power efficiency benchmark suite.
Frustated with waiting for the elevators in your building? Pretty sure a monkey could design a better algorithm for the elevators? Are you sure? Play the elevator programming game.
The Commodordion is… honestly, I don’t even know what to say here.
The mystifyingly tortuous path to testing out AVX512 for FP16 on the first chip family that supports it (but does it, really?) - Alder Lake.
Static analysis and AI in a modern development tool… for COBOL - COBOL Colleague.
24 papercraft models of vintage computers.
A timer for your terminal, for some reason.
Kind of doctest or notebooks meets markdown files? Runme makes readme.md (or other markdown files) into notebooks in VSCode.
And that’s it for another week. Let me know what you thought, or if you have anything you’d like to share about the newsletter or management. Just email me or reply to this newsletter if you get it in your inbox.
Have a great weekend, and good luck in the coming week with your research computing team,
Jonathan
Research computing - the intertwined streams of software development, systems, data management and analysis - is much more than technology. It’s teams, it’s communities, it’s product management - it’s people. It’s also one of the most important ways we can be supporting science, scholarship, and R&D today.
So research computing teams are too important to research to be managed poorly. But no one teaches us how to be effective managers and leaders in academia. We have an advantage, though - working in research collaborations have taught us the advanced management skills, but not the basics.
This newsletter focusses on providing new and experienced research computing and data managers the tools they need to be good managers without the stress, and to help their teams achieve great results and grow their careers.
This week’s new-listing highlights are below in the email edition; the full listing of 191 jobs is, as ever, available on the job board.
