Hi!
Well, the move across institutions happened, which meant for one glorious moment I was at inbox zero on my work email. Other than that, the move was unremarkable, largely due to our insanely capable administrative staff.
In other news, this roundup now marks exactly 6 months of the RCT roundups; we’ve done 26 of them now, as well as a daily sequence for a week which didn’t work very well, and a quickstart on doing remote One-on-Ones once our offices all started closing. I’ve really enjoyed it and learned a lot.
Now that I think I’ve got the hang of the link roundups, I think it would be good to branch out. Two ideas that have come up a couple times are:
Are either of those of interest? Is there something else you’d be interested in? Let me know!
For now, on to the roundup.
Active Listening for Managers - Rachel Hands
Why you Can’t Just Ask Why - Lorin Hochstein
As a manager, learning to be a better active listener - drawing information out of people, helping them reach their own conclusions, digging deeper, restating the speaker’s thoughts in your own words to make sure you understand - is really valuable. It’s a useful skill for talking with your teammates, but also stakeholders and your own manager. And it really helps me to focus on conference calls - when the other person isn’t really there but I’m watching them talk on my own personal distraction box.
The only thing I’d add to Rachel Hands’ article is that digging in with “Why”-type questions is tricky, as Lorin Hochstein points out. If human beings have any superpower, it’s being able to invent completely plausible reasons for things on the fly. Sometimes there’s truth in there, but just as often it’s an unconsciously generated rationalization. What questions — What did you see that makes you say that? What do you think would be a good reason about that? What should I know about this? — helps keep things much more grounded.
Mentors, stop saying “I Understand” - Brenda F. Wensil and Kathryn Heath
Sponsoring a Protégé — Remotely - Sylvia Ann Hewlett and Kennedy Ihezie
Coaching helps us boost the skills of our team members, but there’s a couple of other ways we can really help develop the career of a team member or community member. These two articles give a pretty good overview of the differences between mentoring (being available for advice, which is nice, and valuable, but costs you almost nothing) and sponsorship (actively making opportunities for someone, at the expense of some of your own political capital).
The first article reminds us that we don’t necessarily understand where our mentees are coming from. That’s especially true if we’re providing advice to people with very different experiences and backgrounds than our own. The second article talks about how even in a more virtual environment we can still sponsor someone.
Managing a Multigenerational Laboratory - Lab Manager
I almost never include an article in here just to criticize it, but I’ve referenced Lab Manger articles in the past - they’re often quite good, and written in a way that makes sense to those of us in research - and I want to caution you about this article (which is by no means the worst of the genre). If you start to read anything about how to manage millenials (or boomers, or Gen Xers, or Gen Zers), just click “close”.
To the extent that any of the traits ascribed to say Gen Z as a group (they’re idealistic, want work that matters, are good with recent technology…) have any validity, they’re not a statement about people born between 1997 and 2012, they’re a statement about people who are in their late teens to mid twenties. It’s an age effect, not a cohort effect.
More importantly, though, the differences between those arbitrary generational divides are completely dwarfed by the differences within individuals in any such group. You don’t manage cohorts, you manage individuals, and the way you get to know those individuals is by having one-on-ones, paying attention, and keeping and reviewing notes.
There absolutely are demographic groups whose members will feel outsized effects of some changes and decisions - Black team members, Indigenous team members, first-generation college trainees, women, parents (especially mothers), amongst others. It is important to be aware of those disparate impacts. And even there, how changes will effect individuals and what they need from us as a result will depend on the individual and their situation.
Your team members are individuals, not cohorts or demographics. Get to know them and manage accordingly..
Mentored Sprints Community Handbook - Tania Allard and Cheuk Ting Ho
This is really interesting. Is someone on your team working on a community software project and has been thinking about a (now virtual) hackathon or community sprint with other members of the community? This very detailed handbook discusses how to organize and run such an effort.
UK Research and Development Roadmap - UK Government Policy Paper
I missed this last week - the UK has released a white paper on funding R&D and it looks really promising for research computing broadly: they aim to
“develop our digital research infrastructure capability – data, supercomputers, software, and people – building an internationally leading national digital research infrastructure, bringing digital transformation to the research sector”.
As James Hetherington points out on twitter, money is good (and there’s real money involved), but the fact that this would be an integrated plan with people, data, computer hardware and software all under the same umbrella is incredibly important.
Blended Content Studio - Mike Caulfield
A really nice course on building engaging online courses with a blend of synchronous and asynchronous material. There’s a lot here - I haven’t gone through it all yet - but it’s a great mix of everything from pedagogical theory to the extremely practical details.
Questionable Advice: Can Engineering Productivity Be Measured? - Charity Majors
Ask the EM: Can You Really Measure Individual Developer Productivity? - Gergely Orosz
Two related takes from two very accomplished technical leaders this week on the same question - can you measure the productivity of individual software developers?
They both come to similar conclusions - the answer is no Anything important in knowledge work is accomplished by teams, not by individuals; you hold the team accountable to the team goals, and the individual accountable to contributing to the team’s outcomes in a way which best aligns with their strengths and the teams needs.
For both of those things you can absolutely use quantitative data as inputs - this article by Dexter Sy talks more about the range of things you can use as “indicators”, rather than metrics - but they can’t replace a focus on outcomes and use of judgement. Which, you know, sucks: it’s way harder than just tracking lines of code or tickets or citations or whatever. But that’s the job.
The Hitchhiker’s Guide to Research Software Engineering: From PhD to RSE - Glenn Moynihan
Glenn Moynihan provides a nice overveiw of his journey from a PhD student to a research software developer in industry. In a way it’s related to the above: focussing on outcomes and outputs others can use. He suggests being visible in the community, making contributions to the community whenever possible, and packaging up your own work as professionally and usefully as possible so that others can make use of it.
Inclusiveness in Language for Outsiders Looking In - Fred Hebert
A nice overview on the why’s of getting rid of e.g. master-slave or whitelist-blacklist language in software development projects (but not just there). We’re going through this now. It’s not anywhere near the most important changes we or other projects need to make, but it’s straightforwardly done and it does matter.
Universities and Tech Giants Back National Cloud Computing Project - Steve Lohr, New York Times
Genomics England taps up AWS and Lifebit to create cloud-based Covid-19 research environment - Caroline Donnelly, ComputerWorld
A couple recent reminders about how quickly even big institutions who could do on-prem work are pushing for use of commercial cloud. In the NYT article, big institutions like Stanford, Carnegie Mellon and Ohio State are pushing their support for a proposed National Research Cloud for AI research; in the second, NHS’s Genomics England has been moving cloudward for some time.
Is this the beginning of the end of the x86 era? - @HPC_Guru on Twitter
A thread tree on the rise of ARM, first in the top 500 and now in upcoming Macbooks, and what it means for HPC.
It’s an interesting thread and worth reading, but if I took anything away from it it’s this: There’s no such (single) thing as HPC, there hasn’t been for 15 years, and continuing to talk about “impacts on HPC” or “HPC needs”, even as a shorthand, causes more problems than it solves.
We in the broader research computing community know this - there’s a staggering (almost overwhelming) diversity of needs by researchers, all of which are important for advances in various areas. Taking the subset of that diversity that requires “a lot” of computing by some measure and calling that “HPC” doesn’t mean anything. So you have twitter threads of people arguing past each other
Research computing is about the research, not the computing. Focussing on research use cases allows us to have meaningful discussions. Focussing on hardware needs or market segments does not.
AWS Imagine Grants - September 30, 2020
This is aimed at US nonprofits rather than research, but (US) universities or research institutes could easily be involved in a proposal. Awards will include $100k in credits but also up to $100k in actual money.
Google Cloud Next On Air 2020 - 14 July - 8 Sept
Weekly free training sessions on Google Cloud technologies.
The FortranCon 2020 talks are online. I still have a soft spot for Fortran as a DSL, where the domain is number crunching on rectangular multi-d arrays.
A really cool looking python library that automatically generates a portfoilio of exploratory data analysis plots.
This retrospective of a massive Slack outage in May makes for riveting reading. Research computing will be in a much more mature state when we can routinely read such retrospectives for our outages, issues, and hacks.
A Lua tutorial using an arcade game as a worked problem, and maybe even more interestingly, the “chapters” are github issues.
Git-assembler: “make, for git”.
Secretive, a MacOS app for saving ssh keys in the secure enclave.
