jonathan@researchcomputingteams.org
Hi, all!
Last issue, I left you with a couple of models for giving feedback. We had Situation-Behaviour-Impact:
“When you presented the proposed plan at the project kickoff meeting, the material you presented had a really good balance of just enough relevant context and case for the plan overview. That helped ensure the discussion afterwards was well informed and not sidetracked into irrelevant details.”
The Manager-Tools model:
“May I give you some feedback? [If yes:] When your presentations have the right background material without anything extraneous, and a good overview of next steps, that makes the whole meeting and following discussion more productive. Thanks!”
And the beginnings of a formulation from Better Bosses/Raw Signal Group:
“My expectations are…”
So when would you use each of these?
The Manager-Tools model is great for giving small, easily understandable feedback to those reporting to you. In the negative-feedback case, it ends with a second question; something along the lines of “Could you do that differently next time?” and that is all you need for something small or familiar. For something new or slightly bigger, I typically leave it more open and explicitly invite a conversation; but for tiny and routine things that’s not really necessary (and the more tiny and routine you can make a piece of feedback, the better it goes for everyone).
For peers, you’re not necessarily in a position to make a direct ask like “can you do that differently”; that’s when I use something like Situation-Behaviour-Impact. For what it’s worth, Manager Tools agrees as well with their peer feedback model, which is just behaviour-impact; I talk to my peers relatively infrequently, so it’s useful to bring up the context of the situation, although I suspect they would tell me that doing that anchors the feedback too much on what has happened in the past rather than the future. Either way it’s probably better to not wait long enough to give the feedback that you have to remind them what happened.
To my mind, a conversation that has to start with with “my expectations are” is a much bigger conversation about a serious situation (good or bad); it has the advantage of explicitly owning the expectation, but isn’t something that I’d use for routine feedback.
The roundup this week is already a bit long, so I’ll leave things here for now and next week talk about the process of starting to give feedback in these models, and then tying that into longer-term goal setting expectation communications.
But for now, the roundup!
Private 1:1 Notes Template (Google Doc) - Don Neufeld
One-on-ones are an incredibly useful tool for listening to your team members, and building up the trust so that they’ll actually tell you things. Over time you’ll learn a lot about your team members desired career development, and between those and setting and reviewing goals you’ll get good information about their strengths and gaps.
Periodically reviewing those one-on-one notes and distilling them into some key “headline” areas - and keeping those headlines updated - is an extremely useful practice. It can be useful to tie that practice into something related you’re doing periodically with the team member, like goal reviewing and goal setting.
Neufeld shows his template for what that summary document would look like, including strengths, gaps, likes and dislikes, preferred communications or feedback style, hiring date, etc.
9 Tips for Effectively Sharing Peer Feedback in the Workplace - Mara Carvello
Worth comparing this to what we discussed earlier on feedback. Carvello councils use of on-judgmental language, and focus on the problem not the individual; those are consistent with talking about behaviour and impact. Be prepared to have a conversation - makes sense when talking with peers. We’ve talked in other issues about how the “feedback sandwich” approach is known not to work; the way to “cushion” negative feedback with positive feedback isn’t to batch them in threes, it’s to be frequently giving positive feedback!
Beyond that I think the assumption behind this article is that one has feedback conversations only occasionally, a special thing you have to brace yourself for, rather than it be an ongoing part of everyday work conversations.
Do We Really Need Another Meeting? The Science of Workplace Meetings - Joseph E. Mroz, Joseph A. Allen, Dana C. Verhoeven, Marissa L. Shuffler, Current Directions in Psychological Science
We should really eventually do a series on meetings. As a manager, one of our responsibilities is to keep people aligned and disseminate information. One (one!) tool available to us are meetings, which can be extremely efficient when run well and continually improved; but ugh, how many meetings have we gone to that aren’t that way?
We actually know a lot about meetings, what works and what doesn’t. Mroz et al. cover and summarize a lot of the literature. It’s a review article, so it’s hard to usefully summarize. I think it’s worth calling out a few specific things, like some purposes of meetings (it’s very hard to run a good meeting without being very clear about what the purpose is):
They also usefully highlight known facts about necessary meeting preparation steps and separate leader and attendee responsibilities - arriving on time, following an agenda, make sure attendees are participating, intervene when necessary, send out meeting minutes and action items immediately after, and revisit meeting structure and find out from team members whether they’re happy with the meetings as run.
Most of these points won’t be surprised to people who care enough about managing teams to subscribe to a newsletter on the topic, but it’s still a good short read and emphasizes something that might not be obvious - these aren’t just rules of thumb, people have been studying meetings since at least 1986 and we know what does and doesn’t work well.
The Tools Don’t Matter - Ken Norton
Just a reminder that as technical folk, we tend to jump straight to tools when we’re starting to manage projects or teams for the first time. I’m flat out embarrassed by how long I spent choosing planning tools, processes, etc when I started out in my current job. It had the advantage of feeling like accomplishing something, but it was basically just stalling the harder work of managing projects, products or teams - communication.
Norton has a list of questions that should be asked differently which I’m just going to quote in their entirety:
How to Step In as an Interim Manager - Rebecca Knight, HBR
Research: Becoming a Manager Doesn’t Always Feel Like a Step Up - Nishani Bourmault and Michel Anteby
Here are two articles in HBR for new or about-to-be managers.
In the first, Knight writes about a challenging but pretty common first management (or first directorship) role in either fast-growing teams or research environments; a field “promotion”, official or not, when the original manager leaves.
Being manager of people who were just last week were your peers is genuinely a awkward-feeling situation, but it’s not as bad a situation as you might worry it is. You got the role because people thought you could do it, you already know the work going on and most of the people involved pretty well (which is a huge advantage compared to the most common alternative, being parachuted into an existing team).
Knight has good advice and a couple of case studies. One piece of advice - don’t overplay your authority, do be collaborative rather than directive - can be useful for some. There’s two opposite unsuccessful ways to deal with the sudden change in your role power as a manager of the team you were part of; overplay the “I’m the boss now” card, or underplay it - “I’m just the same team member, you know? We’re still work buddies”. Both can go pretty poorly.
If you think at some point you would like to be a manager, a good way to prepare for a situation like this is to start showing some leadership in some area of your team’s work. It will help train those skills about collaboration and direction, and it can build trust with the team so that if you are asked to take on more responsibility it won’t seem to come from nowhere.
Another advantage to taking on some earlier smaller leadership tasks is described by Bourmault and Anteby int the second article. Becoming a manger can be really discouraging. The things that many love being about an individual contributor - the hands on work, seeing direct connection to results - just don’t happen any more. The problems you are working on are quite different, bigger-picture, longer-term, and connections between what you did and what ended up happening are much more tenuous. It’s not at all unusual for new managers to feel what is described here as “the managerial blues”. That passes for many managers, but others find that the work just isn’t what they enjoy. Best to find that out as early as possible in small doses.
Ten simple rules for running and managing virtual internships - Johannes Werner, Debora Jeske, PLOS CompBio
REU Participation Encourages Students to Pursue Graduate Degrees - Burçin Tamer, Computing Research Association
Working effectively with short-term trainees is tough; it takes a lot of additional planning, clarity, and careful communications. Working with virtual staff is tough; it also requires a lot more intentionality around planning, clarity, communications. And so virtual short-term trainees requires all that and more.
The good news is that if you have an ongoing programme of hiring such trainees, especially if the team is big to work with more than one at a time, you can amortize that work over several students - and it will make your team better at working with virtual collaborators, trainees, and onboarding permanent staff.
Werner & Jeske’s article is a good read - some key points from my point of view:
There are a number of good reasons why you’d want to work with interns; it’s cost-effective if you have that kind of projects, and it can be an effective recruiting tool (you can invite interns back as permanent hire if it works out).
But Tamer points out another reason, supported by data - well executed research experiences for undergraduates (REUs) can significantly increase the number of students who go on to higher degrees and seriously consider research as a career. Having REU programs, especially those that bring on women, Black and Indigenous students, or students from other groups that are systematically underrepresented in research computing, can help grow our field.
Speaking of, Oak Ridge OLCF has a pathways to computing virtual internship program that may be of interest for trainees you know - applications are due on the 30th.
Exclusive: ten more UK R&D funders have aid budgets slashed - Robin Bisson, Research Professional News
Within the nonprofit community, it’s a truism that the second year of a recession is the hardest. Donors and funders find extra reserves to help at the peak of a recession, but are tapped out and retrench into year two.
The pandemic is looking to be similar. For research funded by government, there’s likely some kind of stability - but huge deficits run up in the past year will likely mean at best flat spending in coming years (except, likely, in health). For research funded by aid or charitable giving, however - and there’s a lot both of those, especially in health - it’s going to be a hard few years. Researchers we work with may be scrambling to find alternatives for funding in the coming months.
Why Senior Engineers Hate Coding Interviews - Adam Storm
Storm’s piece is related to the discussion last month on hiring criteria, and matching evaluation to what people would actually be doing on the job. Senior developers spend a more time deciding what to code than doing on-the-fly coding, and putting them into a whiteboard coding interview is stressful, unfamiliar, and doesn’t measure what you care about. Storm emphasizes this point, and suggest that if you really want to see if they can code or not to give them a take-home assignment.
How to Create Software Packages with Julia Language - Jaan Tollander de Balsch
An under-appreciated advantage of R, in terms of community building and code sharing and compared to other languages, is how much work has gone into making it easy to create and distribute a package from within the main IDE, RStudio.
Things aren’t that easy yet with Julia, but it’s getting there; here de Balsch walks through technical steps and community expectations around releasing Julia packages into the Julia Package Registry.
An Ode to Stable Interfaces: R and R Core Deserve So Much Praise - Dirk Eddelbuettel
Speaking of R - R and R Core have put an enormous amount of work into the stability of interfaces. Eddelbuettel walks through using code (depending only on R core) from a blog post in 2007, and running it without change.
It’s only a code snippet, but keeping interfaces to basic functionality stable over 14 years (and 60 releases) is an impressive accomplishment. On the other hand, it’s meant a lot of crud that built up over time. This tradeoff is a real one for research software - which hopefully will be reused, but we don’t know when - and it’s genuinely hard to know how to strike that balance for code being actively maintained.
A Simple Rule for Better Errors - Brian Picciano
Picciano offers a simple but compelling rule for writing internal errors (and propagating them up the stack)
A function sending back an error should not include information the caller could already know.
How to automate anything - Jonathan Hall
What is Human-in-the-Loop Workflow Automation? - Kristopher Sandoval
As technologists we’re pretty big on automation, but as a community we lean towards absolutism about it. A task is completely automated, or it’s not.
But taking some workflow that your team does manually and getting it partly automated - having a playbook written out, and getting one or two key tasks (the ones that are tedious or unpleasant to do) automated - often gets you a significant fraction of the win. It’s now documented, reproducible, easier to hand off to someone, and more likely to be done in a more timely manner (since the worst parts are now scripted).
Both Hall and Sandoval point out the advantages. Hall walks you through the steps, and Sandoval points out that often keeping a human in the loop is actually desirable (or at the very least, hard to do away with).
SSH Keygen: a 2021 update - Krzysztof Zych
Nice overview on updates with OpenSSH - maybe most relevant is that FIDO/U2F tokens are now supported, which is really interesting news.
An introduction to Kernel Exploitation Part 1 - Jordy Zomer
Buffer overruns, license violations, and bad code: FreeBSD 13’s close call - Jim Salter, Ars Technica
A lot of exploits that matter at very large scale are incredibly sophisticated, and so I think most of us think of understanding how to exploit kernel vulnerabilities as requiring years and years of expertise.
But understanding the basics is pretty doable - it’s “just” programming - and arguably helps understand and assess security alerts when they come out. Zomer walks through a (made up) device and driver, and shows how to write an exploit to take advantage of it.
And it’s kind of worryingly common to find exploitable issues in new code - kernel modules, drivers - or even in kernel PRs. Salter talks about a really poor port of WireGuard functionality that almost made it into FreeBSD.
Serverless Genomics - Robert Aboukhalil
As function-as-a-service platforms mature, it’s going to be increasingly a lot easier for researchers to stand up individual endpoints than an entire web app just to support a single endpoint.
Here is a fun example (using CloudFlare rather than AWS lambdas - which also has the advantage that it can run at the edges of CloudFlare’s content distribution network) in the genomics space, looking up data from S3 (a reference genome), running a transformation on it (here simulating noise) and sending the result to the user.
It’s simple, absurdly fast, and could be a nice starting point for more complex apis. And increasingly, with tools like knative and openfaas or openwhisk, it can be something run on-prem as well.
Bioinformatics Open Source Conference - part of ISMB/ECCB 2021, July 29-30 online: Abstracts due 6 May
This annual meeting for open source and open science bioinformatics prioritzes talks about tools that have community impact, novelty, examples, and are runnable. Code and talks must be open-licensed.
2021 ALCF Computational Performance Workshop - 4-6 May, 10am
This workshop covers preparing for work on leadership-scale systems, including but not exclusively ALCF.
What if an arduino, but legos? That’s what pockit.ai seems to be building.
Nice walk through of logic programming with Datalog using cocktail recipes.
Learn basic and intermediate vim with gifs.
Standalone 2FA for SSO with NGINX: autheila.
Another paean in favour of Ada.
You know the rule - embedded db articles get an instant mention in the newsletter. Going through the functionality of sqlite.
In case of fire, delete file - why all Shrader’s servers have an 8GB empty file.
