jonathan@researchcomputingteams.org
Hi, everyone:
I got a number of responses back from last week’s question about interviews or Q&A; people were interested in both, at least trying it out.
The interviews will take a little while to line up. If you have suggestions for research computing managers you’d like to see interviewed, please send the suggestions along. And if you are interested in volunteering, please do volunteer too! I’ll build a list and then start asking people. And for Q&A I’ll set up an online question box.
And with that, on with the roundup! There’s a bit of a writing and hiring theme this week, as you’ll see below:
Tell candidates what to expect from your job interviews - Julia Evans
The goal of the interview process is to find out if there’s a good match between the job and the candidate; that’s more likely to happen if both the candidate and the interviewers are clear on what the process will be. Julia Evans points out that it’s straightforward and useful to document the process and communicate it to candidates ahead of time. The candidate will better know what’s important to the interviewers, and so can communicate their strengths more clearly (as well as being less stressed); the interviewers won’t be winging it and will be able to focus on the important things. In addition, it makes the hiring unit look much more professional to the candidate.
How do you work with and manage an exhausted team? - Andy Skipper, CTO Craft
Skipper’s article starts off with 10 causes of an exhausted team, which seems unnecessary. A lot of teams out there are pretty exhausted, just due to (waves around) all of .. everything.
The article goes on to identify useful procedural, behavioural, and emotional signs to have an eye out for, and some specific things we can do as a manager to help people work through it. A number of those things are things I wouldn’t have thought of - pairing people on tasks, for instance, and the importance of continuing to maintain lines of communication and trust, including negative feedback compassionately given.
1-on-1s for engaged employees: How good managers run them - Impraise
Long-time readers won’t read anything new here about running good one-on-one meetings with your team members, but it’s always good to review the basics, and this is a short read if you want to brush up.
Impraise is one of many SaaS tools out now for managers to organize their one-on-ones and feedback/coaching conversations with team members. I haven’t used any myself and I don’t feel like we’re missing out on anything vital, but in principle anything that helps you and your team communicate well and promotes good manager practice like routine feedback and one-on-ones sounds like it could be useful. Have any readers used such tools? Any thoughts?
4 ways to improve your writing and communication in your free time - Jessica Thiefels
Written communication is remote work super power - Snir David
Asynchronous Communication Builds Respect and Trust - Dexter Sy, Tech Management Life
A lot of us in research and computing ended up here because we preferred working in math or code over writing. But writing is an incredibly useful skill to hone — it helps us communicate with our team now, and with our stakeholders; and it helps develop our career whether through blogging or writing papers that get read.
Jessica Theifel’s article gives us some concrete suggestions about how to improve our writing game - some resources to learn about persuasive writing and for grammar checking, and a couple resources for writing prompts to help get us to practice.
It’s (intentional) practice that really helps improve writing, and the hard part is forcing ourselves to do the practice. (Committing to a weekly newsletter is one particularly extreme way to do it).
As you develop those skills, it will help with your team, too. Working remotely is forcing us into a bunch of new communication practices that, honestly, are going to continue to serve us well even once frequent face-to-face meetings become feasible. One of those practices is not relying so heavily on synchronous communication - which is exhausting when done over Zoom or the equivalent - and more on asynchronous communication, which means writing more frequently and for longer than a one-paragraph email. Snir David’s article points out how useful written communication is for our new remote work life.
And finally Dexter Sy’s article argues that using more asynchronous commuincation can help show your team you trust and respect them - giving them the information they need, caring enough to write it well, and then letting them do their thing rather dripping out information, or virtually tapping on their shoulder and seeming to check in on them routinely.
(Relatedly, this thread on twitter about tech companies hiring for writing skills is interesting).
EMBL survey studies effects of COVID-19 pandemic on life scientists - Bioengineer.org
Scientists pessimistic about life after Covid-19 - Robin Bisson
As tough as the last months have been for our teams, it’s important to remember that our researcher colleagues - especially early career researchers, wet-lab folks, and women who take on a the majority of family care duties - are not doing well either. These two surveys reveal a lot of concern for the present and pessimism about the future.
How to Write Technical Posts (so people will read them) - Sandy Maguire
The key to getting posts read is making them relevant and easy to read. That’s kind of hard for those of us who mainly have academic or technical writing experience. This article suggests some things to think about.
Research Computing Q&A Site to be Examined at PEARC20 - HPC Wire
Ask.CI - think StackOverflow for research computing departments - is something I had never heard of before and in the last month or two have been hearing about everywhere. As with all such things, it really requires a critical mass of users, but more and more XSEDE centers are playing with it. There are a lot of advantages to such a system over ticket-based systems for users willing to post their questions publicly. I’m curious to see how this project evolves.
Design Documents at Google - Malte Ubl
Code only says what it does - Marc Brooker
Malte Ubl’s article is a nice overview of how design documents are done at Google, and how they are used - to communicate not only an end goal but the why’s - the context, the tradeoffs intentionally made in design, and the alternatives considered.
As Marc Brooker’s article points out, code is great and can be “self documenting” at what things actually do, but not why they are done that way. Without information like what tradeoffs were chosen and alternatives considered, it’s hard to know whether or not the old why’s are still valid and so whether or not change is needed.
(Design documents are not especially new things - e.g. decision logs have been a part of project management for ages, for similar reasons.)
Does Stress Impact Technical Interview Performance? - Behroozi, Shirolkar, Barik & Parnin
Tech Sector Job Interviews Assess Anxiety, Not Software Skills - Chris Parnin & Matt Shipman, NC State
Whiteboard coding interviews are not widely loved by candidates. I don’t have interviewees live code but do I like watching candidates work through similar kinds of problems on a whiteboard. This study may finally make me rethink this.
It’s a small study (N=48) where interviewees were assessed on their coding skills and randomized into two arms. In one they were interviewed by a panel, having to live-code on a whiteboard and explain their way through; in the other, they privately worked through the problem on a whiteboard. And then they were evaluated for having passed the interview or not.
And the results aren’t great for whiteboard interviews. The in-front-of-people interview results weren’t strongly correlated with coding skills so much as stress levels of being in front of an audience. In particular, every woman who live interviewed failed the live interview, and every woman who did the problem privately passed.
I would like to see versions of this study run with larger N, though, and in slightly different situations (not a panel interview, but a single interviewer for instance). But the results seem to line up with anecdotal evidence.
There are absolutely roles I might want to hire someone into where presenting to a room full of skeptical decision makers is a job responsibility. Maybe I’m looking for someone to talk with funders or PIs of partner projects or to advocate for money from the VPR. I this case, the results of these interviews - does the person get stressed in that kind of environment - would be valuable signal.
But most of the jobs I’d hire someone for aren’t like that. It’s just not an important skill to have for our developers or sysadmins. In which case the results of these interviews would just be noise. And relying on that noise knowing full well that the women in this study do significantly more poorly seems clearly unjustifiable.
What Predicts Software Developers’ Productivity? - Murphy-Hill, Jaspan, Sadowski, Shepherd, Phillips, Winter, Dolan. Smith & Jorden Transactions on Software Engineering (2019)
Interesting paper I just came across:
we designed a survey that asked 622 developers across 3 companies about these productivity factors and about self-rated productivity. Our results suggest that the factors that most strongly correlate with self-rated productivity were non-technical factors, such as job enthusiasm, peer support for new ideas, and receiving useful feedback about job performance. Compared to other knowledge workers, our results also suggest that software developers’ self-rated productivity is more strongly related to task variety and ability to work remotely.
There’s definitely issues with self-rated productivity, but given the problems with external measures, I’m not sure what the alternative is.
Note that the developers themselves think they’re more productive when they’re getting useful feedback about performance. It’s uncomfortable giving feedback sometimes but people want (and deserve) feedback.
Characterization and Identification of HPC Applications at Leadership Computing Facility - Liu et al.
A nice and detailed workload characterization of jobs on Mira, a “leadership-class” computer that started serving jobs at Argonne in 2017. We need more data like this; it’s hard to know how to build or deploy systems (certainly on-prem systems) without understanding the workloads they need to support. But it’s hard, because the systems supplied always distort the expressed needs; if you don’t build it (for some use case) they won’t come.
Rewriting FORTRAN Software in Rust - Ferdia McKeogh
A nice overview of experience rewriting some shallow-water equation simulation software from Fortran to Rust. To be honest I’m surprised Rust did as well as it did - it’s really quite impressive. But for the time being, Fortran is still pretty hard to beat for the sorts of things that Fortran is generally used for.
High-Performance Cloud Computing for Exhaustive Protein–Protein Docking - Masahito Ohue, Kento Aoyama, and Yutaka Akiyama
Cloud Computing for Climate Modelling: Evaluation, Challenges and Benefits - Montes et al.
Two nice recent overviews about moving research computing stalwarts into the cloud. The docking paper focusses on running MEGADOCK in Azure, and looks at performance over a number of instance types, with and without GPU, and with various network configurations. The climate modelling paper focuses on more high level issues, the challenges (complexity and in some cases cost) and benefits (flexibility, burstability, and lack of capital cost).
What I learned from looking at 200 machine learning tools - Chip Huyen
Artificial Intelligence: the Future of Medicine? - Benjamin Amor
Two quite different articles - one aimed at people in the computing space, one aimed at physicians and policy makers - on AI/ML tooling. In both, they identify one key issue relevant to research computing - the problem, as always, is good clean complete data and sensible hypotheses.
JuliaCon 2020 - 24-31 Jul, Free
A week of tutorials followed by two days of packed sessions. Julia has a lot of promise for research computing, and if you’d like to learn more, this could be a good way to start.
Data Center World - 24-27 Aug, $695-$1195
For those who spend a lot of time thinking about data centres but wouldn’t normally go to a data-centre-specific conference, the 2020 Virtual edition of Data Center World may be of interest.
Maybe controversially, I really like slack, but it can be a huge binging, beeping, source of distraction. Here’s a list of 25 tips for setting it up to be less all-consuming. Individually, they’re helpful but small; collectively I think they make a big difference. This plus making expectations clear on your team about slack still being primarily an asynchronous means of communication can make it useful rather than a productivity drain. (Next up: fixing its memory consumption…)
I mention the importance of feedback for your team frequently, Julia Evans reminds us that giving positive feedback to peer managers about their team member’s work, especially for something that miight otherwise go unrecognized, is a good and useful thing to remember to do.
Brandon Gregg’s Systems Performance book is out in a highly-revised second edition. The first edition is an extremely good book.
Some pointers on creating a Github profile README.
Barcelona Supercomputing Centre’s datacentre hosting Mare Nostrum is just lovely. Here’s an online tour - just press the play bottom at the bottom left-hand side.
I learned about httpie a month or so ago - if you use curl to test out API endpoints, you should try httpie.
If you’re an Mac user, you can use TouchID or an Apple watch to authenticate for sudo.
There’s a bash script testing framework?! That lets you test commands like rm?
29 bytes of C code which generates a 16GB executable.
