jonathan@researchcomputingteams.org
Parent categories: Technical Leadership
Other tags: | Hiring: Other | Hiring: Interviewing and Evaluating |
Picking problems for programming interviews - Will Larson If you do do coding as part of your interviews, it’s tough to find something that is relevant, hard enough to successfully distinguish between candidates, but easy enough to be doable. Here Larson plays with a few examples (one of which is a particular kind of data munging: something broadly relevant to our needs). His suggestions are to aim for problems that: Support simple initial solutions and compounding requirements Are solvable with a few dozen lines of...
Continue...Other tags: | Hiring: Other | Hiring: Interviewing and Evaluating |
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....
Continue...Other tags: | Hiring: Other | Managing A Team: Career Ladders | Hiring: Creating a Job Description |
Research Software Engineers - Job Descriptions - Aalto Scientific Computing Group The Scientific Computing group of Aalto University has text for their job descriptions of a simple three-step (RSE1, RSE2, RSE3) progression for software development in their institution. It’s not a formally recognized ladder by HR yet but it guides their hiring decisions. The whole thing is just a few paragraphs long, but it’s very clear and is a lot more than most institutions have. The other internal documents they have on the page are...
Continue...Other tags: | Strategy: Marketing |
Newcastle University Research Software Engineering 2020 (PDF) - Newcastle Research Software Group BEAR - Advanced Research Computing Research Software Group 2020 Report (PDF) - Birmingham Research Software Group These two reports on the 2020 activities of the research software development groups at Newcastle and Birmingham are extremely interesting if you run a research software development core facility-type operation, and very interesting even if you don’t int terms of the clear product and strategy mindset (and communications efforts) behind the groups. In Newcastle’s, we get some...
Continue...Other tags: | Hiring: Other | Hiring: Interviewing and Evaluating |
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...
Continue...How to release 2 years of unfinished code, the “Agile way” - Jonathan Hall Sometimes you get yourself into a hole and need to find a way out. Hall recommends releasing something that works right away - some teeny change to the last related version - just to practice the (now quite out of date!) release process and give your team a quick win. It could even be a version bump and a change to the docs! Release something, then find a way to maybe...
Continue...Other tags: | Hiring: Other | Hiring: Interviewing and Evaluating |
How to Freaking Find Great Developers By Having Them Read Code - Freaking Rectangle We know code is read more than it’s written, and that debugging, code maintenance, and incremental addition is more common and time consuming than “green field” code development. And yet, the entire software development community tends to vastly over-value writing code from scratch over understanding existing code. That’s true of research software development, too, which famously almost never starts completely from scratch. Here the article’s author recommends focusing a “coding” interview...
Continue...Other tags: | Strategy: Funding |
Don’t fund Software that doesn’t exist This blog post by Andraeas Müller connects two facts that I think most of us in R&D computing are pretty familiar with - one that we talk a lot about and one that we don’t - and extrapolates to a conclusion that I’m not sure I agree with but is certainly worth discussing. The fact that we talk about regularly is that ongoing maintenance of important research software (and key open-source software in general) is famously underfunded, and this...
Continue...Other tags: | Working With A Research Community: Credit |
Second thoughts on Proper Citation Guidance for Software Developers A good recent blog post on the pros and cons of different approaches to software citation by Daniel S. Katz, who’s thought about this a lot. Some key points: any method is going to take extra work by someone; there may not be a one-size-fits all approach; and in the end, code just isn’t the same as a paper (amongst other things, there’s no one point at which it’s done). Daniel ends the post leaning tentatively...
Continue...Other tags: | Managing A Team: Knowledge Sharing |
On Pair Programming, Birgitta Böckeler & Nina Siessegger A great description on the hows and whys of pair programming, a technique I don’t see very often in research software development (though giving how subtle some pieces of what we work on are, it might be useful). There’s two big advantages of pair programming - knowledge transfer/collective code ownership (at least two people know how some piece of code works), and code quality (two people’s input is better than on). (It can have advantages for helping the team learn to work together, but...
Continue...Other tags: | Strategy: Product/Service Management |
The Happiness and Stresses of Open Source work - Drew Devault My FOSS story - Andrew Gallant Research computing teams have a lot in common with open source communities - even if you aren’t developers or developing open source software. One of the joys of open source communities is that you’re part of a small, visible team solving problems for your users - and that’s exactly the situation we’re in. But there’s downsides to that, too. Users can be incredibly demanding, and when you’re a...
Continue...Other tags: | Managing A Team: Documentation/Writing |
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: | Strategy: Research to Development Maturity Ladder |
Source Code has a Brief and Lonely Existence - Derek Jones Derek Jones has an interesting blog where he takes data-driven looks at software and software development. Here he points out: The majority of source code has a short lifespan (i.e., a few years), and is only ever modified by one person (i.e., 60%). I think this is worth coming to terms with, particularly in terms of research computing and tool maturity. Most new ideas, as they get put into code, will stall out at...
Continue...Other tags: | Technical Leadership: Migration |
Avoid Rewriting a Legacy System from Scratch by Strangling It - Nicolas Carlo Because the value of the code is what was learned from writing it rather than the code itself, when it comes time to grow from earlier maturity stages to the next, the recommendation for from other sectors is to migrate away from the earlier code, not to refactor a proof of concept until somehow becomes production quality. (See also Keavy McMinn’s recommendation to throw away code from a proof-of-concept “spike” in her...
Continue...The Four Pillars of Research Software Engineering - Cohen et al. In this article, we have presented 4 pillars representing a set of areas and activities that we consider to be vital in offering coordinated and comprehensive support for research software and the people who build it. In turn, we hope this will demonstrate to professional developers and researchers alike that research is a viable, and interesting, environment for a software development career. In this white paper, the authors present what they see as the...
Continue...Other tags: | Technical Leadership: Migration |
The key points of “Working Effectively with Legacy Code” - Nicholas Carlo Exit the Haunted Forest - John Millikan An awful lot of of code we work with in research computing can be thought of as legacy code - whether it’s functioning but old code that to meet current needs needs to be refactored, or whether it’s new code from a researcher which just isn’t maintainable in its current form. I like to think of reworking such code as helping the code reach its potential....
Continue...Other tags: | Technical Leadership: Reproducibility |
Quantifying Independently Reproducible Machine Learning - Edward Raff, writing at The Gradient We worry a lot about about replication and reproducibility in research computing. In this article, the author — who attempted to independently replicate the results and basic methods in 255 (!!!) ML papers. Crucial here is independent replication; it’s not enough to just run the code, but to implement independently. He was successful 162 times. That’s enough papers to do some quantitative analysis, and it’s interesting what aspects of the work were not...
Continue...Other tags: | Technical Leadership: Code Reviews |
Michaela Greiler on Code Reviews - Software Engineering Radio Episode 400 How to do High-Bar Code Review Without Being a Jerk - Andrew King How to do a Code Review - Google Engineering Practices Documentation Reading Chelsea Troy’s blog has kind of convinced me that Code Reviews are a way of doing asynchronous, distributed pair programming. And even if you do them within an in-person team, they require good communication skills to be productive and drama-free, both in the review itself and “out of band”....
Continue...Other tags: | Technical Leadership: Code Reviews |
Feedback Ladders: How We Encode Code Reviews at Netlify - Leslie Cohn-Wein, Kristen Lavavej & swyx We had several links about code reviews and the importance of clarity around expectations two weeks ago; in this post, authors from Netlify describe a simple, emoji-encoded 5-level scheme for communicating how urgent and important the code review recommendations are. It’s kind of the code review equivalent of the paper referee’s Reject/Resubmit after Major Revisions/Accepted Pending Minor Revisions/Accepted rubric. Read the article for the details, but the levels are:...
Continue...Other tags: | Managing A Team: Data Teams |
How to Grow Neat Software Architecture out of Jupyter Notebooks - Guillaume Chevalier This is an older blogpost which just became a recent talk. I’m coming around to the point of view that computational notebooks have real problems - obvious ones like hidden state, and maybe less obvious ones like the structure of notebooks actively discourage reasonable software development practices like unit testing or even version control. People even study this. But in research computing lots of things have problems and we are kind of...
Continue...Other tags: | Technical Leadership: CI/CD |
The Pyramid of Unit Testing Benefits - Gergely Orosz Unit testing is increasingly accepted in research computing that it doesn’t really need justification, but when people talk about it’s benefit, it’s usually about fairly low-level benefits - CI/CD and avoiding regressions. But there’s an entire pyramid of benefits: Validate your work. Separate concerns in your code. An always up-to-date documentation. Fewer regressions. A safety net for refactoring. Advantages like documentation, and the need to separate concerns in the code to the point that unit testing...
Continue...Other tags: | Technical Leadership: Code Reviews | Managing A Team: Knowledge Sharing |
The Communicative Value of Using Git Well - Jeremy Kun I’ve mentioned before several of Chelsea Troy’s articles on code review as a sort of asynchronous pair programming, with the benefits both of better quality code and knowledge transfer. In this article, Kun talks about crafting code changes into meaningful commits and PRs exactly to enhance that communication and knowledge transfer.
Continue...Other tags: | Technical Leadership: Migration | Technical Leadership: Case study |
Migrating large codebases to C++ Modules - Takahashi, Shadura, & Vassilev C++ Modules in ROOT and Beyond - Vassilev, Lange, Muzzafar, Rodozov, Shadura, & Penev C++20 is finally coming. There are five major new features - Contracts (preconditions/postconditions/assertions - which I think are potentially extremely interesting for research computing), Co-routines, Concepts, Ranges, and Modules. Modules are probably the biggest change to the language. Ever since C, the approach that’s been taken for modularization of C/C++ code is C-preprocessor style include statements. These are hard to...
Continue...Other tags: | Technical Leadership: Open Source Management |
A graduate student perspective on overcoming barriers to interacting with open-source software - Oihane Cereceda, Danielle E.A. Quinn It’s easy to forget how confusing and intimidating it can be to work with open source projects for the first time - filing an issue, submitting a PR (is this change too trivial? Am I submitting the PR right?). This is a description from the point of view of a grad student on the issues with interacting with open source communities for the first time
Continue...Other tags: | Technical Leadership: Code Reviews |
Five Code Review Anti-Patterns - Trisha Gee, Oracle We’ve talked before about having clear expectations on code review; here’s five common traps to avoid, and that could be made explicit as part of your team’s CONTRIBUTING.md or similar: Nit-Picking Inconsistent Feedback Last-Minute Design Changes Ping-Pong Reviews Reviewer Ghosting
Continue...Other tags: | Strategy: Product/Service Management | Strategy: Research to Development Maturity Ladder |
New users generate more exceptions than existing users (in one dataset - Derek Jones, The Shape Of Code Not surprising for us in research computing but nice to have it validated with data: new users of software find new ways to trigger software faults. This is one of the reasons why the transitions that research software goes through — from being used by the creator to being used by friendly users, and then again to being used by a wider community — is so challenging...
Continue...Other tags: | Managing A Team: Knowledge Sharing |
7 practices you should follow for a successful code handover - Nicolas Carlo Programming as Theory Building - Diogo Felix These are interesting articles to read back to back. Nicholas Carlo has his usual pragmatic information about legacy code - in this case, avoiding code becoming legacy code by executing a handoff between an outgoing developer and a new one. The key ones, I think, are: New dev writes the docs, reviewed by old dev Keep old dev engaged Jointly write more tests to share...
Continue...Other tags: | Strategy: Advocacy Resources |
Evidence for the importance of research software - Michelle Barker, Daniel S. Katz, Alejandra Gonzalez-Beltran A nice list of papers, talks, and other resources on the topic of the impact of research software. There’s also a continually updated Zotero group library and Github repository.
Continue...Other tags: | Managing A Team: Other |
Today was a Good Day: The Daily Life of Software Developers - André N. Meyer, Earl T. Barr, Christian Bird, and Thomas Zimmermann Interesting study of how 5,971 software developers spend their day in general, and how they spend it on days they feel were good days and typical days; the idea is that this could be used to help managers have their developers make more good days. It’s an interesting and short read. I walked away with two big points, but there’s others in...
Continue...Other tags: | Working With A Research Community: Other | Working With A Research Community: Hosting Conferences/Events |
Mentored Sprints Community Handbook - Tania Allard and Cheuk Ting Ho This is really interesting. Is someone on your team working on a community software project and has been thinking about a (now virtual) hackathon or community sprint with other members of the community? This very detailed handbook discusses how to organize and run such an effort.
Continue...Other tags: | Managing A Team: Other |
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...
Continue...Testing And Scale - Daniel Bell This is a short read talking about the difference in the need for testing at the initial, exploratory phase of coding (where detailed testing is brittle and slows you down) as opposed to the stage of development where the code is being used for real things (where lack of detailed coding makes the codebase brittle because it can’t be easily safely modified). This this is particularly relevant to research software development, where I’ve argued a maturity model is a...
Continue...Other tags: | Strategy: Project Management |
A Software Development Life Cycle for Research Software Engineering - Kings Digital Lab There was a really interesting SORSE talk this past week, Digital Humanities RSE: King’s Digital Lab as experiment and lifecycle by James Smithies and Arianna Ciula. The Digital lab, which hosts and maintains 160+ digital humanities projects, has a very nice lifecycle model for the research software development/hosting/maintenance efforts they get involved in, and they’ve generously made it, and templates for the documents at every step along the cycle, available to the...
Continue...A set of Common Software Quality Assurance Baseline Criteria for Research Projects - Orviz, Lopez, Duma, David, Gomez, and Donvito Coming out of the EOSC Synergy effort, an extensive checklist of criteria for “production strength” research code, to be e.g. deployed as a service to communities in the INDIGO Data Cloud. The criteria are broken down into categories: Licensing Code Workflow Code Management Code Style Code Metadata Unit Testing Functional Testing Integration Testing Documentation Security Code Review Automated Deployment In most areas the actual recommendations...
Continue...Other tags: | Working With A Research Community: Credit |
High level overview of how Australian Research Data Commons is viewing Research Software as a First Class Object - Tom Honeyman on Twitter This is a really interesting diagram of how ARDC is thinking of research software: Here's a preview of what we're thinking (high level) for a national agenda for #researchsoftware as a first class object @ARDC_AU. Feedback welcome pic.twitter.com/XtfwhK48DN— Tom Honeyman (@TomHoneyman3) November 30, 2020 The approach is I think the right one, and one I’ve advocated before; taking a path-to-maturity model approach,...
Continue...Other tags: | Technical Leadership: Code Reviews |
How to Make Your Code Reviewer Fall in Love with You - Michael Lynch A nice article outlining how to write PRs to make them as easy review as possible - making them easier to approve. Good for individuals working on open source projects and for teams working together. There are 13 steps there, but several I think deserve calling out: Review your own code first - go through the code with a reviewer’s eyes Answer questions with the code itself - if questions come...
Continue...Other tags: | Managing Your Career: Productivity |
Maximizing Developer Effectiveness - Tim Cochran This is aimed at software developers, but much of it would apply just as easily to those running systems or curating research data. Team members are effective if they’re quickly and frequently getting feedback - did this change work, does this solution meet the requestor’s needs - and not waiting for things or having their day chopped up into little pieces. That means as managers it’s important to make sure we have the tooling and processes in place to...
Continue...Other tags: | Technical Leadership: Other |
Managing technical quality in a codebase - Will Larson This article is about the steps in improving code quality over time from an initial messy code base; the idea is marching up a ladder, solving increasingly high-level issues. This is particularly relevant for research software development. Successful research software marches up a technical readiness/maturity ladder from proof of concept to prototype to community use to production research infrastructure. As code marches up that ladder, the tradeoffs change, and the needs for code quality change with...
Continue...Other tags: | Technical Leadership: Other | Managing A Team: Other | Becoming A Manager: Other |
Questionable Advice: “How do I feel Worthwhile as a Manager when My People are Doing all the Implementing?” - Charity Majors> The Non-psychopath’s Guide to Managing an Open-source Project - Kode Vicious, ACM Queue Majors’ article is a good reminder for new managers that it’s really hard to recalibrate job satisfaction or the feeling of accomplishment when you’ve moved into management. All you can do is focus on the big, long timeline stuff while still taking joy in the little moments, and make sure that...
Continue...Other tags: | Managing A Team: Documentation/Writing |
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: | Managing Your Career: Productivity | Managing A Team: Other |
The SPACE of Developer Productivity - Nicole Forsgren, Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck, and Jenna Butler, ACM Queue We’ve covered several times the challenges of measuring developer productivity, particularly individual developer productivity. Forsgren et al walk us through recent literature on the subject, disabusing us of some common myths and encouraging us to instead, as managers of developers, keep an eye on the SPACE dimensions of how well our team is doing: Satisfaction and well-being - employee satisfaction, developers having the tools...
Continue...Other tags: | Technical Leadership: Other | Technical Leadership: Code Reviews |
Those pesky pull request reviews - Jessica Joy Kerr Can pair programming replace code review? - Jonathan Hall Kerr’s blog post in late March kicked off a series of posts in the software-dev blogosphere on whether we should still be doing pull reviews. There’s too many posts to list here, but these two by RCT roundup regulars, cover much of the range of views. Kerr’s pretty firmly on team get-rid-of-’em. My summary of her argument: There’s a reason why no one likes getting or giving...
Continue...Other tags: | Technical Leadership: Code Reviews |
Having a Healthy Pull Request Process for Teams - Alex Kitchens This is a longer read on setting up a pull request process, both for the authors of the PR and the reviewers. Other processes could be healthy too, but any healthy process will have clear and explicit expectations. Kitchens spells out the responsibilities for an author - they fall under making PRs easier to review: Make the PR Description Clear and Digestible Explain Unexpected Changes Keep the Size of Pull Requests Small (When Possible)...
Continue...Other tags: | Technical Leadership: Other |
Dos and Don’ts of Pair Programming - Study Suggests Togetherness and Expediency for Good Sessions - Bruno Couriol, InfoQ Two Elements of Pair Programming Skill - Franz Zieris, Lutz Prechelt, arXiv:2102.06460 Couriol has a good summary of the work of Zieris and Prechelt on pair programming. That work, which was accepted to ICSE 2021, looks at two features which they claim determines whether pair programming succeeds as a practice: a combination of “togetherness” (whether the pair can successfully establish and maintain a common mental model...
Continue...Other tags: | Hiring: Other | Hiring: Interviewing and Evaluating |
TinyBird Tech Test - Javi Santana, TinyBird With a clear understanding of a role, it’s much easier to understand how to evaluate against that profile when you’re interviewing. Santana provides one real take-home problem they use at TinyBird, a company that builds real-time data processing tools. It involves writing up how you would solve a data ingest-plus-expose-an-API problem, and describes the rubric they use to answer it (it’s almost all about the communications, not the technical beauty of the proposed solution).
Continue...Other tags: | Becoming A Manager: Remote | Managing A Team: Knowledge Sharing |
Easy Guide to Remote Pair Programming - Adrian Bolboacă, InfoQ Bolboacă walks us through the how and why of remote pair programming, and InfoQ helpfully provides key takeaways (quoted verbatim below): Remote pair programming can be an extremely powerful tool if implemented well, in the context where it fits. You need to assess your current organization, technical context, and the time needed to absorb change before rushing into using remote pair programming. There are useful sets of questions for that. Social programming means learning easier...
Continue...Other tags: | Technical Leadership: Other |
Software Development Waste - Greg Wilson, It Will Never Work in Theory Software Development Waste - Todd Sedano, Paul Ralph & Cécile Péraire, ICSE 2017 Wilson briefly summarizes a paper by Sedano, Ralph, and Péraire, who looked at eight software development projects at Pivotal, a software development company, for 2 years and five months, interviewed team members, and analyzed retrospectives. They identified nine broad categories of wasted time and/or effort in the projects: Building the wrong feature or product Mismanaging the backlog Having to re-do...
Continue...Other tags: | Managing A Team: Documentation/Writing |
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: Code Reviews | Managing A Team: Other |
Ship / Show / Ask - Rouan Wilsenach We’ve talked about pre-commit vs post-commit reviews in #34 - post-commit being something of an alternative to PR review. Changes that past CI testing get committed, so that developers aren’t blocked by waiting for review, and commits are reviewed later. (Obviously this incentivizes a large test suite!) Wilsenach suggests that you don’t have to have a culture where it’s either/or. In the “Ship/Show/Ask” model, changes can be simply made without review (Ship) or post-commit review (or at...
Continue...Other tags: | Working With A Research Community: Other |
Low-code contributions through GitHub - Isabela Presedo-Floyd, Mars Lee, Melissa Weber, Mendonça, Tony Fast, Quansight Labs Interesting experience getting people who wouldn’t normally code to make contributions to a project via github. In this case, the effort was around alt text for images (including scientific diagrams!) for a project, based on pull requests, but I could imagine it working well for documentation, sourcing diagrams, or other contributions. The team’s process was: pre-meeting preparation with a project contributor and meeting facilitator a crash course in the...
Continue...Other tags: | Managing A Team: Other |
Guides for Managers - Software Sustainability Institute This is a resource I hadn’t seen until Better Scientific Software pointed it out - a collection of guides for research software development managers, including starting and improving a community for your product, recruiting a champion or student developers, funding software and developers, and more. The guides are short and come with links to other resources. They take a “focus on the basics” approach that readers of this newsletter would likely appreciate. Overlapping sets of guides for researchers,...
Continue...Other tags: | Managing A Team: Career Ladders |
Senior level RSE career paths (with an s) - Daniel S. Katz, Kenton McHenry, Jong S. Lee In the spirit of Shmitz et al.’s call for a career path for RCD individual contribitors, Katz, McHenry, and Lee describe a career progression for research software developers, starting with associate, staff, then senior research software engineer (RSE). Then there’s a bit of a step change to Lead, which I think is pretty well described here: Some of these roles can include some mentoring and leadership, and at...
Continue...Other tags: | Technical Leadership: Other |
Well-researched advice on software team productivity - Ari-Pekka Koponen, Swarmia Management is hard, management of something as complex and ambiguous as software development is especially hard, but that doesn’t mean we don’t know anything. There has been a lot of research on what works for making teams work well, and recently particularly in the area of software development. It doesn’t mean there are cookie-cutter solutions for anything, but we do have good guidelines. Koponen walks us through several well-supported (and in some cases ongoing) reports,...
Continue...Other tags: | Managing A Team: Career Ladders |
RSE Group Evidence Bank - UK RSE This is an interesting collection of job titles and descriptions from a number of UK RSE groups for job levelling (junior/RSE/senior/head of RSE), soe articles on setting up RSE or data science institutes. Very interesting if you’re thinking of starting an RSE group. Hopefully it continues to grow.
Continue...Other tags: | Hiring: Other | Hiring: Interviewing and Evaluating |
I really like this documented hiring process by 18F in the US Government. It’s a well thought out process, and it’s written in a way that you could send to candidates so they know exactly what to expect. It’s even in GitHub. I also really like their technical pre-work - it’s either to provide some code they’ve worked on, or to do one of four exercises. The exercises are simple but non-trivial get-and-process-data exercises that would give a lot more confidence about ability to do...
Continue...Other tags: | Strategy: Advocacy Resources |
Survey reveals 6000+ people develop and maintain vital research software for Australian research - Jo Savill, Australian Research Data Commons (ARDC) Research Software Capability in Australia - Michelle Barker and Markus Buchhorn Interesting results from a late-2021 ARDC survey on research software capability, of 70 managers of Australian research computing and data groups. Results were scaled to try to give an estimate of all-of-Australia numbers. The article by Savill gives an overview, and the full report by Barker and Buchhorn is interesting reading. Some key...
Continue...Other tags: | Technical Leadership: Testing |
How I think about Code Management - Andreas Klinger A lot of research software we start dealing with…., well, let’s say “has many opportunities to be made even better”. Klinger has a nice summary of maintaining and improving a code base over time. He sees it as having two components: Reducing complexity, and Increasing confidence And that both of those can and should be addressed incrementally and continuously. Klinger says that you handle the code complexity over time with refactoring (including my favourite refactoring, deleting...
Continue...Other tags: | Becoming A Manager: Diversity | Managing A Team: Other | Technical Leadership: Other |
The pushback effects of race, ethnicity, gender, and age in code review - Emerson Murphy-Hill, Ciera Jaspan, Carolyn Egelman, Lan Cheng, Comm ACM 2022 When we’re assessing the technical merits of a code contribution, and by extension assessing letters of reference etc about a candidate’s technical merit, we need to be aware of these effects - non-white, non-male, and older colleagues get significantly higher pushback for PRs, controlling for number of lines changed, readability, and other effects.
Continue...Other tags: | Technical Leadership: Testing |
I just threw away a bunch of tests - Jonathan Hall The evolution of the SciPy developer CLI - Sayantika Banik, Quantsight Labs Related (but not limited) to ease of developer onboarding - I was just having this conversation with a friend. Test suites are code, too, and part of your product - they’re not some weird kind of “meta-code” for which the usual rules don’t apply. As Hall points out, that means keeping them documented, making them easy to run, refactoring them, and discarding...
Continue...