#16 - Link Roundup, 15 May 2020
Engineering Manager Event Loop; Change takes sustained effort; Expanding conflict capacity in stressful times
I asked last week about onboarding; people who responded last week said they weren’t bringing on student interns or new hires at all at this point in the pandemic. It sounded like at least our managers had succeeded in avoiding layoffs in their teams, sometimes despite an unfavourable - in one case very unfavourable - pre-COVID-19 environment, but several were not bringing on research students, either because of complexities on onboarding, that they just didn’t have the time, or because schools had stopped their placement programs.
A question for this week - how are work hours and productivity going in your team right now? There’s some evidence that after an initial dip, productivity has actually risen; but I think it’s more complicated than that, especially for teams tackling complex problems. GitHub has seen more hours worked (and more variable hours) but it’s not clear that total number of PRs or commits has gone up - people are working longer but not necessarily getting more done.
Anecdotally it seems like in among some teams I’m familar with, productivity for lots-of-small-tasks work has gone up, but productivity for deep-work will-have-to-think-about-this-for-a-few-days type tasks has dropped noticably. Has that been your experience, or are you seeing something different? How are you handling it?
The Engineering Manager Event Loop - David Loftesness via Chris Eigner
This isn’t new, but I really like the idea: what a generic tech software development manager should be thinking of daily, weekly, and monthly on people, projects, processes, and themselves. It’s not quite right for research computing - thinking about recruiting and hiring on a daily basis is to put it mildly not the regime we’re normally in - but a lot of the other items hold up. What other changes would we have to make?
Attitudes toward Change and Transformational Leadership: A Longitudinal Study - Matthew David Henricks, Michael Young & E. James Kehoe, J. Change Management
There’s a lot of people who spend their careers studying how workplaces work. I don’t think most of the management literature percolates into STEM fields — the papers look funny. They’re full of impenetrable jargon (unlike our normal completely buzzword-free reading, heh) and the text seems impossibly fluffy compared to dense STEM work (but, well, people’s behaviour doesn’t lend itself to formulae and small dense sentences).
This is a longitudindal study that probably aligns with you already believe, but it’s worth highlighting - you absolutely can change culture or practices in a team or larger organization, but you can’t do it by having a single event and then putting up some posters. It takes time and sustained effort. People systems are like large ships; it’s hard to get them to change course, but once actually you get them turning they have a lot of momentum.
Managing Your Own Career
Practical Skills for The AI Product Manager - Peter Skomoroch, Justin Norman and Mike Loukides
I’m not saying you should leave academic research computing and move into AI product management — in fact, if you care enough about managing research computing teams well to be reading this, please don’t, the community needs you — but we often undervalue how transferrable our skills are to other areas. Read some of these practical must-have skills and see if they don’t sound like your day job:
Design/Innovation: “…It’s incredibly important to determine what outcome is desired, how that outcome will be delivered, and how the product will be used before embarking on the long (and expensive) development journey.”
Feature Development and Data Management: Data management, you say?
Modelling: yeah I think we’re good
Serving infrastructure: check
How to expand conflict capacity in times of crisis - Marlene Chism
We’re all tired and stressed right now, and it’s easy under those circumstances for small things to cause conflict where it normally wouldn’t. This is something that we can work on, but it takes some time and practice. Pay close attention to things that trigger unhelpful reactions, try to be aware of them as they come up and short-circuit them, and then buy some time saying you’ll get back to them and step away.
Programmatically draw architectures for AWS, Azure, GCP or on-prem systems by writing python code. The cool thing there of course is now your architecture diagrams can be meaningfully version controlled.
I’ve often said that one of the problems people new to computing at scale have is that laptops and their filesystems work too darn well, so their intuitions about what’s easy and hard actively mislead them on clusters or distributed systems. This article expresses that more clearly, and might be useful for discussions with users who are having trouble making the jump.
You shouldn’t write code when avoidable. Even something “trivial” like CSV parsers.
If you haven’t seen this already, there’s a nice survey of deep learning for scientific discovery on arXiv.
A nice looking coursera course on research data management.