jonathan@researchcomputingteams.org
Parent categories: Managing A Team
Other tags: | Strategy: Marketing |
Blogging your research: Tips for getting started - Alice Fleerackers, ScholCommBlog Fleerackers’ post is aimed at researchers but works equally well for us in research computing. It starts off with an important point - not every blog post needs to be a 1500 word feature. It could be a summary of a paper or conference session, a Q&A/interview post; anything that makes the audience more informed about your groups work than it was before. The decision for where to blog is normally easier for our...
Continue...Other tags: | Becoming A Manager: Delegation | Technical Leadership: Other |
A thorough team guide to RFCs - Juan Pablo Buriticá We’ve written before about design documents architectural decision logs (e.g. #33) and using collaboration around documents as a form of asynchronous meeting (e.g. #49). Usually the thinking is that someone in charge has initiated the document. Buriticá writes about team member-initiated requests for comments as a proposal for a change or the creation of something new, which can then go through a comments phase like a PR, and an approval phase where whatever decision making...
Continue...Other tags: | Technical Leadership: Systems: Other | Technical Leadership: Runbooks | Technical Leadership: Automation |
Tracking Toil using SRE principles - Eric Harvieux, Google Cloud Blog Writing Runbook Documentation when you’re an SRE - Taylor Barnett, Transposit “Toil is the kind of work that tends to be manual, repetitive, automatable, tactical, devoid of enduring value, and that scales linearly as a service grows.” These two articles came out in the same week, and they work very nicely together. One of the under-appreciated advantages commercial cloud organizations (or other large operations) have at scale isn’t about hardware - it’s that they...
Continue...Other tags: | Technical Leadership: Software Development |
Jeremy’s Notes on Fast.AI coding style A bracing reminder (ternary operators! 120-character lines!) that there aren’t “correct” coding styles; the purpose is to make sure teams reduce internal barriers to collaboration by picking one style that works for them and sticking with it.
Continue...Other tags: | Working With A Research Community: Communications Tools | Technical Leadership: Other |
Google’s Technical Writing Courses - Google Some of us, particularly those of us who were trained in engineering departments, got technical writing training — but most of us didn’t, and the training we did get was focussed more on reserach papers (which let’s face it is a terrible model for almost any other form of writing besides research papers). Google has made available two of their internal courses on technical writing. The first course is sort of “Strunk and White for people who work with...
Continue...Other tags: | Technical Leadership: Other | Working With A Research Community: Communications Tools |
Design Docs, Markdown, and Git - Caitie McCaffrey Azure Sphere Security Services used a Word/Sharepoint workflow for drafting, circulating, refining, and approving design documents wasn’t working, so they trialed a move to using markdown and git for their design documents. It was a success, and here they write up their approach. Not every design document corresponds to just on repository’s worth of code, so they chose to have one single repo for design documents for their organization organization, to support discoverability and large/unconstrained multi-codebase architectural...
Continue...Other tags: | Technical Leadership: Systems: Other | Technical Leadership: Automation |
The Runbooks Project - Ian Mieli In an effort to help get people started with runbooks for operations, Ian Miele of Container Soltuions has started an opensource set of runbooks, the Open Runbooks Project, starting with their own. Worth checking out as a set of templates, and keeping an eye on as more get added.
Continue...Other tags: | Working With A Research Community: Communications Tools |
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...
Continue...Other tags: | Technical Leadership: Other |
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...
Continue...Other tags: | Technical Leadership: Other | Working With A Research Community: Communications Tools |
Drawing good architecture diagrams - Toby W, (UK) National Cyber Security Centre A nice overview of drawing architecture diagrams. The article makes the point that the diagram is about communicating, and if it doesn’t communicate the key points of the system to the readers, then it’s not succeeding. I like this advice: Start with a basic high level concept diagram which provides a summary. Then create separate diagrams that use different lenses to zoom into the various parts of your system. Having multiple diagrams of...
Continue...The documentation system - Divio The Divio page is a nice set of pages talking about a systematic way to think about various kinds of documentation - tutorials, explanation, reference, and how-to guides - as documents meeting different needs, along two different axes: when studying vs when working, and providing practical vs theoretical knowledge. For our systems, our software, our curated data sets, really all of the outputs of research computing, we need these kinds of documentation, and it’s not enough to provide one of...
Continue...Other tags: | Technical Leadership: Other |
Why write ADRs [Architecture Decision Records] - Eli Perkins, GitHub blog We’ve written before on the importance of recording the why’s of architecture decisions. Even the best self-documenting code or infrastructure can only describe how it works, which is different from why it was implemented this way rather than another. Without that context, it’s very difficult to know, when something changes, if the architecture should be reconsidered. Perkins does a good job in a short article describing three good classes of reasons why to write...
Continue...Other tags: | Technical Leadership: Other |
Getting Big Things Done - Marc Brooker Architecture Decision Records - Upmo Brooker, who leads development on AWS’s Lambda product, writes about his approach to getting big things done and done well; his approach is outlined below: Is it the right solution? Is it the right problem? Engage with the doubters, but don’t let them get you down Meet the stakeholders where they are Build team(s) The builders The stakeholders Be willing to adapt This maps pretty straightforwardly to research computing work too. Key to...
Continue...Other tags: | Managing A Team: Other |
Write Down Your Team’s Unwritten Rules - Liz Fosslien, Mollie West Duffy It’s very likely that my team is going to grow significantly over the coming months. That’s a huge opportunity but also a challenge - we have a pretty good team culture now and we don’t want to make any unintentional changes to that. In addition, we’ve had a few discussions recently where it’s been clear that expectations I thought were clear - about learning, contributing to others’ work, working hours - were not...
Continue...Other tags: | Working With A Research Community: Communications Tools | Becoming A Manager: Managing Individuals | Managing Your Career: Other |
Writing Is One of the Best Things You Can Invest In, as a Software Engineer. The More Experienced People Become, the More They Tend to Realize This. - Gergely Ortoz Speaking of non-technical skills being underrepresented in technical job descriptions… Communicating well is absolutely essential part of a job in any interdisciplinary endeavour like research computing, and written communication is becoming absolutely vital as teams go remote. That doesn’t necessarily mean particularly good grammar or vocabulary - we’re an international community, many in our community...
Continue...Other tags: | Technical Leadership: Software Development |
Developers spend most of their time figuring the system out - Tudor Girba, feenk Writing good code by understanding cognitive load - David Whitney ARCHITECTURE.md - Aleksey Kladov Girba points us to a recent article: Xia, Bao, Lo, Xing, Hassan, & Li (2018), **Measuring Program Comprehension: A Large-Scale Field Study with Professionals*,* IEEE Transactions on Software Engineering that looked at 78 professional developers during over 3000 hours of their work and found that 58% of their time was taken up by comprehending a code base;...
Continue...Other tags: | Working With A Research Community: Communications Tools |
Writing in the Sciences (Coursera Course) - Kristin Sainani Writing is one of those things that many of us got into science or computing to avoid. But written communication, especially to stakeholders and the public, is vital for effective product management in research computing. Sainani has what looks like a pretty good short course on writing for within research communities and to the public: Topics include: principles of good writing, tricks for writing faster and with less anxiety, the format of a scientific manuscript, peer...
Continue...Other tags: | Becoming A Manager: Offboarding |
Why a Positive Offboarding Experience Matters More Than Ever - NOBL As a rule, people won’t retire from their jobs with you. It’s always good to be prepared for any given team member to leave (make sure everything’s always documented, use one-on-ones to have a good understanding of what everyone’s working on, use techniques like pair programming/PR reviews or talks and demos to disseminate knowledge. The post on NOBL makes the following suggestions: Make sure your off-boarding checklist still makes sense in a post-pandemic world...
Continue...Other tags: | Managing Your Career: Other |
Always be quitting - Julio Merino If we knew we were quitting (or just going on a long vacation) in two months, what would we be doing differently at work? Probably documenting a lot more, making sure people were coming to meetings so that they could take our place when we weren’t there, training up people to be able to take over parts of our role for us. But those activities are key and routine parts of being an effective manager or technical leader. Merino...
Continue...Other tags: | Managing Your Career: Other |
Writing is Networking for Introverts - Byrne Hobart This is an older (2019) article that recently started circulating again, and I really like it. Relationships are a key part of being an effective leader, and for building your career. Trust speeds collaboration, and we trust people we already know and have interacted with. Increase the circle of people who trust you (and you trust) so you can have more effective and frequent collaborations requires building your relationship network. “Networking” has come to sound like a...
Continue...Other tags: | Becoming A Manager: Managing Individuals | Managing A Team: Other | Working With A Research Community: Communications Tools |
Words Matter: Is Your Digital Communication Style Impacting Your Employees? - Samantha Rae Ayoub, Fellow “We need to talk”. “Fine.” These all messages or responses that would be very uncomfortable for us to receive from our boss; but when things are busy it’s pretty easy for us to communicate in exactly that way with our team members or peers. Your boss (probably) isn’t a jerk, and neither are you, but when we have a lot of things on our mind it’s easy to not pay...
Continue...Other tags: | Technical Leadership: Other |
Making World-class Docs Takes Effort - Daniel Stenberg Documentation is incredibly important for a product’s adoption and use - whether the tool is software, data products, systems, or (increasingly) a combination of the three. It takes a lot of work, but that work pays off later with more adoption and less support effort per user. Stenberg highlights what he’s found to be important for documentation: that it be: Stored with the code, for convenience and so updates are kept in sync, but Not generated from...
Continue...Other tags: | Technical Leadership: Software Development |
What Makes a Good Changelog - Zeno Rocha, Herbert Lui, WorkOS A very pragmatic about documentation for developers. The most important thing about changelogs is that they exist. And the easiest way to ensure that’s done is to have simple, clear, and non-onerous expectations of what they should look like. Rocha and Lui specify: They should be clear In images, highlight changes Spotlight the people behind the product Consistent formatting of versions and dates, and… Teams should dedicate real technical staff time to them
Continue...Other tags: | Technical Leadership: Data Resources |
Datasheets for Datasets Template - Audrey Beard Datasheets for Datasets - Timnit Gebru et al, arXiv:1803.09010 Beard provides a LaTeX template for Gebru et al’s suggested “Datasheets for Data sets”, a human readable high level description of a dataset - not a data dictionary, but describing the reason the data set exists, how data was collected, what preprocessing/cleaning/labeling was done if any, how or if maintenance will be done, what uses the dataset has been put to, and more.
Continue...Other tags: | Technical Leadership: Systems: Other | Managing A Team: Other |
Making operational work more visible - Lorin Hochstein In the f-string failure article in software development, I pointed out that log and error handling code was under-reviewed and tested. There’s probably a bigger lesson one can take from that on the undervaluing of supporting or glue or infrastructure work compared to “core” work. And sure enough, one of the huge downsides of operations work is that when everything goes well, it’s invisible. Above, Granda walks us through writing up an incident report and sharing it...
Continue...