I hope you’ve had a good week!
These were the resources that I saw circulating this week (might not necessarily be from this week) that I think our community might be interested in.
There were a number of discussions about teams that I think are extremely relevant to reserach computing; the first one, in particular, really emphasizes the importance of one-on-ones with team members. When the newsletter gets started in earnest in February, the first couple of weeks will probably focus on de-stressing the management of research computing teams, and I could imagine a whole week early on just on one-on-ones; it’s such an important and useful tool for building working relationships and trust with the team while learning things we wouldn’t have otherwise about the day-to-day work of the group. Have you been doing regular one-on-ones with your team? Are there things you’ve found work really well (or poorly)?
This is a short interview with someone who has led software development teams at Netscape, Apple, Pinterest, and Slack, and who has written extensively on the topic. There’s a lot of higher-level things that don’t automatically carry straight over to research computing from software development - I’ll mention one below - but the fundamental basics of managing people, especially technically-minded people, are extremely relevant. And in particular, this exchange rings particularly true:
“Q: What are your best pieces of advice for being an effective engineering manager? A: Number one, with any team, is hold one-on-ones. [..]”
It’s just so valuable and straightforward.
I think this was circulating again because of a new article of something related that Microsoft did ( In a Recent Study, Microsoft Found That the Most Successful Teams Share These 5 Traits ), and it’s not hard to refactor the five traits from one into something that looks like the five factors from the other; these are fairly basic things:
These all comes down to communication and engagement from the manager - from us - which we can help with some basic tools.
Being in research helps us with a few of these: the meaning and impact of our work is much clearer than if were working on some random consumer-facing product. But we sometimes pay a price on items like structure & clarity or dependability.
Ok, I took some liberties with the article title there. But having walked into technical projects already in progress before, I absolutely agree with the priorities about learning/verifying these first six things first, and then patiently learning and learning trust so that when you do decide what changes to make they’re more likely both to be the right ones and to be successfully implemented.
The priorities listed to learn/verify are:
All of those are extremely relevant for us, even the first one. Yes, most of our efforts are being grant-funded, but how does that work? Why is that funder funding us - not what’s written in the grant proposal, but why does this project meet a need the funding agency sees - and what can be done to make sure that happens in the future?
One of the big differences between research computing and regular software development or IT has always been the open-endedness of the work, and in particular that we’re often starting in a “will this even work” mode rather than building something we know is doable and it’s just a matter of discovering and validating the user requirements (something that Agile approaches help a lot with.)
There was an interesting blurb in R&D Today abut the Manhattan project as an example of a project where everything was just too new to able to form hypotheses and perform experiments; they just had to go through a stage of trying a lot of things, noting the outcomes, and slowly getting to the point of finding more solid ground.
In data science and particularly ambitious startups there is an increasing realization that you can’t just agile your way from nothing; you have to go through that same casting about phase first. That means actually mixing stagegate approaches (waterfall! gasp!) with agile, or going through separate R&D, Design and then Engineering/Productionizing phases. Basecamp has a process around it - transitioning away from “R&D”. I think as data analysis becomes more mainstream, research software development may become more and more similar to other areas of software development.
A decade in review in tech, Cindy Sridharan
Ok, I’m pretty late to this one, but this is a thoughtful look at what happened in the 2010s and thinking about why. I think the comparison between Docker and Kubernetes is particularly on-target; Docker took over the world incredibly quickly because it served a real need and the “highest level API” was very well matched to that need. Kubernetes owns its space but growing that user base is going to be hard because the “highest level API” is… well… really not very high level, or even closely lined up with the problems it aims to solve.
Hard and Soft Modularity, Brittany DePoi
This is a very nice way to think about modularity, using continuous development as a mental model; the issue isn’t just whether the tools are separate, but whether you can deploy a new version of a tool without that propagating outwards.
(See also this tweet.) It’s always good to take stock, look to see what’s going well and what’s not, make hypotheses about how to fix things, and then try the experiment and see how it goes. We’re scientists - that’s what we do! (Although not often enough about our own processes). This isn’t a particularly new thing, though; continuous improvement has been a part of agile methods since before agile was used in software development.
Two very different kinds of advice on two different kinds of technical writing this week:
Notes on Technical Writing, Marcus Kazmierczak
All of our teams have to write documentation, whether it’s for researchers using a computing system or a piece of software. And even though we spend much of our day reading (and having strong opinions about) the quality of said documentation, when it’s our turn to do the writing it’s still hard to know what to focus on.
Marcus Kazmierczak’s short blog point focusses on 5 principles he follows, and expands on each:
and I found it very useful.
Why I Keep a Research Blog, Gregory Gundersen
Moving from how to write to why to write, this Princeton Ph.D. candidate describes why he blogs about and on topics related to his research. Blogs are slowly coming back after being buffeted by the rise of social media, and they can be an incredibly useful resource both for the reader and for the writer. Writing is painful and agonizing (IMHO) because of the level of clarity it requires of my thinking, but that makes it a useful process. His seven goals are
and he expands on them. My goals for this newsletter aren’t that dissimilar…
I include these in the link roundups both who are interested in the jobs themselves, or those who are interested in hiring such people so they see what similar job ads look like. It’s also just interesting to see, as data analysis of large datasets becomes mainstream, to see explicit “Research Computing” opportunities at companies one never would have expected a decade ago - Target? Really?
Still, I only see a fraction of these jobs, so if you know others that you’d like to have included, please send them along:
Manager, Research Computing - Vector Institute (Toronto): “…[S]eeking a Manager, Research Computing to join our growing team in Toronto… The Manager, Research Computing will build and coach a highly-skilled team who will develop and maintain tools that support transparent growth and appropriate resource sharing policies.“
Lead High Performance Computing Engineer - Target (Sunnyvale): “The Lead High-Performance Computing Engineer will design and develop parallel computing algorithms for solving very large stream-computing and neural-computing problems on heterogeneous platforms including vector engines (AVX512), FPGAs, GPUs, and other types of super-computing hardware platforms. “
Head of Research Computing (HPC) - Norwich Biosciences Institute Partnership (Norwich): “We have an exciting opportunity for a strategic High-Performance Computing (HPC) leader to take accountability for the future development of research computing across one of the UK’s foremost research organisations. The Head of Research Computing will set the future technology strategy, and service model, for mission-critical, research IT services at NBI.”
Chief Technical Officer - Radii Devices (Bristol): “Radii Devices is offering a unique opportunity … to lead the technical development of a new software system for faster, more personal fitting of prosthetics and orthotics. Radii Devices is a University of Southampton spinout…”
And that’s it for another week. Please reply and let me know anything you found interesting, insightful, or disagreed with! Topics you want more of? Less of? Let me know.
Have a great weekend, and good luck next week with your research computing team,