jonathan@researchcomputingteams.org
Congratulations, everyone; we did it.
If you’re at a University, 2020 is now or is soon to be officially at a close. For the rest of us, while there is some work remaining to be done, things are winding down. We made it to the end of 20-frickin’-20.
I started this newsletter together with you in January, which seems like a decade ago. It’s been a hard year for our teams, and a hard year for managers. We’ve had to keep things together and moving with the world falling apart; help team members through incredibly tough times and keep the research and researchers who depend on us going.
We’ve done incredible work, and because of what we’ve done as managers our teams are going to come out in late 2021 stronger than when this started. The trust we’ve built with our teams by seeing them through the tough times will make the team work even better together. Our improving and making more intentional our team communications, necessary for the abrupt move to all-distributed, will be of benefit in the years to come. Our upping our management and prioritization skills will help our team through whatever future challenges come our way.
I’ve learned a lot writing this, and I hope it’s been helpful to you to read this over the past year. Over 100 of you have subscribed and stayed subscribed through some mis-steps and mis-fires, and I appreciate it and your feedback. From your feedback I’ve learned:
I think we all more than deserve a couple of weeks worth of rest. I’ll be back January 8th, recharged and ready, and I hope you will be too.
And now, without further ado, the last link roundup of 2020!
Say “No” to Triangulated Feedback - Esther Derby
This one hits a little close to home this week.
Derby’s article talks about the perils of “triangulated” feedback - team member A tells you something about team member B and you bring it to team member B. A team is a group of people who are accountable to each other in working to a common goal. By being a cut-out in these accountability conversations we short circuit these needed conversations, eroding trust, and give ourselves a bunch of worse-than-meaningless busywork to boot.
The reason this hits home is last week I actively made a situation between two team members significantly worse by interjecting myself too soon and too forcefully. I felt like I was doing the right thing - my intense personal preference is to avoid these situations, so taking decisive and immediate action “seemed” right to me - but it absolutely was not. In this particular situation, monitoring and checking in after a day or so would have worked much better. To be clear, being completely uninvolved is not a solution either, but we can’t be a first- or even second-choice option for dealing with between-team-member conflicts except in extraordinary circumstances.
Why Capable People Are Reluctant to Lead - Chen Zhang, Jennifer D. Nahrgang, Susan J. Ashford, and D. Scott DeRue, HBR
In a study of 400 MBA students, three risks held people back from stepping up to lead, in projects or in taking decisive action:
As we try to make sure our team members have growth opportunities, and increase their scope by giving them more responsibility and project to manage, these are the key concerns they are likely to have (or, frankly, we are likely to have as we grow in our careers). To mitigate this, the authors suggest
Writing a Performance Self Review for Software Engineers - With an Example - Gergely Orosz
Orosz writes this in the context of getting ready for a performance review by your boss. Many of us don’t have such reviews in any meaningful way. But this is a terrific process to go through every quarter or so, for yourself and for your team as a whole. It’ll help you communicate your value to your boss, yes, but also your teams value to administration, potential new collaborators, and external stakeholders; it’ll help you focus on the positive accomplishments and identify areas for improvement; and, more or less for free, it’ll help you keep your resume up to date for that next opportunity.
Orosz suggests focussing on:
Tech Lead Management roles are a trap. - Will Larson
When I was asked at my SORSE talk if it was possible to be both lead developer and manager, I replied that anything was possible but it is really, really hard. The most stressed I’ve been in the last couple of years was when I’ve had both significant technical and managerial responsibilities - they are completely different skillsets requiring your mind to be in different kinds of places. Bouncing between the two is definitely playing the game in hard mode.
Larson agrees, especially for new managers:
The reality is that when you’re trying to learn something brand new, like team management in this case, you’re almost always going to be better off getting to focus on that area.
Collaborating with Someone You Don’t Really Know - Rebecca Zucker, HBR
Starting projects with new collaborators is a pretty integral part of our line of work. Zucker suggests clarifying things right from the start - these conversations can be a bit awkward but go way easier at the start of a working relationship. The good news is that I think our experience as managers makes it simpler:
I honestly think I wouldn’t have been able to answer my part of the last three questions clearly before having worked as a manager for a while. It’s only been since I’ve been working with colleagues with very different working styles, and making it my job to understand and accommodate those working styles, that I can actually recognize my own.
Introducing Cloudflare Pages: the best way to build JAMstack websites - Rita Kozlov, Cloudflare
We all need webpages for our organizations, teams, and projects. For a lot of us in the technical world, JAMstack solutions like Jekyll make the most sense - they rely on the tools we use every day. But if you don’t want the pages to be absurdly slow, you can’t just rely on github pages. Our team uses a slightly Rube Goldberg contraption involving GitHub, Travis-CI, AWS S3, AWS CloudFront, AWS Route 53, and AWS Certificate Management. It works really well, and is super cheap, but honestly was a pain setting up.
Cloudflare has a beta now for Cloudflare Pages which cuts out the middleman and builds and pushes your jamstack page directly to their CDN. Future versions will even support dynamic webpages using cloudflare workers (which I’ve been meaning to play with). Worth taking a look at if you don’t already have a solution you like.
COVID-19 Teaching Experience: 17-313 Foundations of Software Engineering - Christopher Meiklejohn
A review of online learning in 2020 - Tony Bates
In the past year, a lot of you have learned a lot about online teaching and training, and those hard-won lessons are things that we’ll all be able to build on in coming years. These two articles reflect on some lessons learned.
Meiklejohn gives some very hands-on reflections teaching a software development course in a hybrid mode over the past year, and the main takeaways are that it can be done and successfully, although rejigging in-person materials to work successfully with online tools is hard.
Bates’ article outlines 10 higher level lessons learned, each of which has its owns short article:
The structure and interpretation of scientific models - Konrad Hinsen
You don’t hear it as much now but it was everywhere in the early 2000’s - a new pillar of science, not just theory and experiment but computation! And then came data! And machine learning eventually came around too and eventually there were pillars everywhere and the whole thing seemed kind of silly.
Hinsen makes a better distinction, between observations and models, and those models can be empirical, or - the real purpose of science - explanatory.
DRY is a Trade-Off - Moshe Zadka
A reminder that everything in our work is tradeoffs, and even really good “rules” are bad when applied too dogmatically. Having some partially-repeated code in your project is way better than forcing yourself into the wrong abstraction too early.
What I Wish Someone Had Told Me About Tensor Computation Libraries - George Ho
This is a really high level overview and categorization of array computation libraries (I’m sorry, as someone who just barely passed a general relativity course I just can’t call them Tensor computation libraries) like PyTorch, TensorFlow, Theano, JAX, and others. He categorizes them by how they perform the three key classes of functionality of such libraries:
Ho wrote a similar categorization and explanation of probabilistic programming languages like Stan and PyMC4 which also looks good.
d’Oh My Zsh - Robby Russell
This isn’t a new article, but it crossed my browser the other day, and it’s a really nice overview of how a software project became a huge success with incredibly modest beginnings - initially not much more than a list of dot files - but by being useful right from the beginning and by very judiciously choosing additional functionality to implement.
In defense of blub studies - Ben Kuhn A pretty central tenet of this newsletter is that there’s no magic to running research computing teams, it’s all just about being deliberate and focussing on the basics. Kuhn makes a similar argument for developing software - know your tools deeply and well.
Where do I go now that CentOS Linux is gone? Check our list - Jim Salter, Ars Technica
Ars Technica, of all places, has a good roundup of CentOS alternatives including some I hadn’t heard of such as Springdale Linux and HPE ClearOS.
GitOps Decisions - Ian Miell
Another central tenet of this newsletter is that a lot of tasks that seem like a lot of work are just making explicit a bunch of decisions that were previously implicit. And making things clearer and more explicit is a pretty central job of a manager.
Mielle describes the process of moving to gitops with even a quite simple setup. There’s a dizzying number of decisions which have to be made and implemented - how many repos, where does config live, how do you handle multiple environments, etc. But these aren’t new decisions, they’re decisions that have been previously been made implicitly, and by going through the work of making things explicit you have everything documented and automated making development, deployment, and onboarding new team members incredibly easier.
2021 International Workshop on Software Engineering for Computational Science - June 16-18, 2021, papers due early February 2021
We seek contributions from members of both communities that describe perspectives, research outcomes, and lessons learned (positive or negative) from the development of computational science software.
A safe, minimal, Bash script template.
A really nice self-guided advanced compiler course from Cornell.
Even the things we take most for granted in computing weren’t obvious at the time and needed to be invented. It took almost a decade to invent the else clause in “if-then-else”, and it wasn’t for lack of trying.
Nomad 1.0 for those with applications that are outgrowing docker compose but for whom kubernetes would be overkill (which is most people).
Starting August 20201, GitHub will require authorization tokens (rather than username/password) for all git operations. From an operations point of view it’s interesting that they’re choosing to schedule two brownout dates in June and July - a “shot across the bow” to make sure people are read for the hard August end date.
A lot of already delicate lock-free code is going to break when it moves to ARM.
Ever since the inception of the term there’s been a lot of talk of STEM fields. With the importance of social sciences and humanities increasingly clear in the era of social media and now with the pandemic, expect to start hearing about SHAPE fields - Social sciences, Humanities, and the Arts, for People and the Economy.
