jonathan@researchcomputingteams.org
Hi:
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)?
Engineering management: An Interview with Michael Lopp
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.
Re:Work: Five keys to a successful google team
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.
Your first 90 days as CTO or VP Engineering Technical Manager Will Larson
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…
