I do a lot of different things for work; it is part of what I enjoy most about what I do. The kind of work that I do has recently become known as "Research Software Engineering" (RSE). I previously referred to it as "I don't know, like, programming for science, I guess. A little bit of everything." It is a strange multitool of a job, and its boundaries are still being defined. But based on my experience, I think an ideal RSE would need to be (1) a fully qualified scientific researcher, (2) a full-stack software developer, and (3) a competent project manager. There are not yet really educational or career paths for RSEs (although people are working to change that). Many of us start with degrees in science or engineering but must then become both autodidacts and polymaths to fill in the gaps. I recommend the books below as entry points into some of the most critical skill sets for a RSE. These are books that I have not only read but reread, some of them many times. I reference many of them regularly, and my copies are filled with annotations and bookmarks. I have been recommending these books to my employees and mentees for several years, with the goal of jump-starting their professional development. My hope is that this will serve as something like a course reader for anybody on similar paths.
"Clean Code: A Handbook of Agile Software Craftsmanship" by Robert C. Martin
Most of the book's examples are in Java, and the text often assume that you'll be writing object-oriented code. But without too much squinting, you’ll find that most of its points and lessons are applicable to any programming language or paradigm. (For example: when and what types of in-code comments are or are not useful.) Also, I think that the "agile" in the title refers more to the spirit of the original Agile Manifesto — of which Martin was a coauthor — than to any of the particular methodologies that have become basically synonymous with the term. So, again, the book is broadly applicable, and you should not avoid it just because you don't sprint your kanbans at the weekly standup or whatever.
"Working Effectively with Legacy Code" by Michael Feathers
"Legacy code" here refers, in practice, to any code that has previously been written. You could have written it five minutes ago, and it counts. What this book is really primarily about is how to write good (and effective) test coverage for code so that you can modify, refactor, or port it while retaining confidence in its functioning. This is essential, because a large fraction of our work as RSEs involves legacy code. Perhaps we receive prototype code from the project PI (or one of their grad students), and we need to make it production-ready. Or maybe we are trying to replicate or refine data processing methods from the nearly 30-year-old Clementine lunar mission, or even Apollo.
"The Missing README: A Guide for the New Software Engineer" by Chris Riccomini and Dmitriy Ryaboy
This book conveys a lot of information, tips, tricks, and gotchas related to software engineering that — up until now — were only carried around in the heads of old-hat developers as lessons hard won from experience. As the book's introduction puts it: "skills that are not taught in school." Even if you don't understand everything in this book right away, perhaps because you lack relevant experience, simply planting these seeds in your mind will accelerate your progress once you do _need to understand it. I recommend this book for anybody who is _new to professional software development, but if you have been around these parts for a while (maybe >10 years), then you may get less out of it (but not nothing).
"Software Estimation: Demystifying the Black Art" by Steve McConnell
I think this is considered a classic on the topic of software project estimation, and I suggest that anybody who manages software developers or does software development in exchange for money should read it, maybe several times through. Being a knowledgeable, effective software project estimator will feel like a super power.
"Software Estimation Without Guessing: Effective Planning in an Imperfect World" by George Dinwiddie
This book is a little more approachable — and thinner — than Software Estimation, and to some extent just covers a subset of the same topics. However, it also goes into some detail on the social, cultural, and psychological factors that affect how software estimates are created, received, and acted upon. It is the kind of book on engineering that discusses cognitive biases and empathy, which I daresay always have greater impacts on project success than specific technology stacks or development methodologies.
"Influence: The Psychology of Persuasion" by Robert Cialdini
Regardless of your occupation, you will spend a great proportion of your working life either trying to align other people to your goals and objectives or fielding efforts from others to align you to theirs. This book is a practical crash course on how to navigate that from both sides.
"Think Fast and Slow" by Daniel Kahneman
This is a book about how people think and make decisions. It was a whirlwind best seller and won many awards, and I feel like everyone has read it by now. But if you haven't: congratulations, you're one of today's lucky ten thousand! It also has everything to do with software engineering. I am, as I write this, realizing the extraordinary extent to which the topics covered in this book overlap with nearly every other book on this list.
Everything by Edward Tufte
You will also, in your career, need to make your arguments visually. Tufte's philosophies of graphical design are not the only ones, but they are both good and very influential. Titles include "Visual Explanations," "The Visual Display of Quantitative Information," and "Beautiful Evidence." I often flip through them just to gain some inspiration prior to constructing a high impact graphic. For example, I once made a poster that was entirely composed of sparklines.
"The Golem: What You Should Know About Science" by Harry Collins and Trevor Pinch
I feel quite strongly that, in scientific undertakings, all assumptions should be questioned, and that includes our assumptions about the nature of science itself. Unfortunately, the culture and norms of science for many of us are like water to fish, especially by the time we've navigated the scientific training gauntlet. Fortunately, there are fields and scientists who spend their careers interrogating the system — sociologists, historians, ethnographers, etc. in departments with names like "science and technology studies" (STS) — and they tend to write incredibly clear, engaging, and illuminating books about what they learn. "The Golem" is intended for a broad audience and is a good entry point into STS and ethnography of science.
"Science In Action: How to Follow Scientists and Engineers Through Society" by Bruno Latour
Latour was one of the founders of STS as a discipline, which makes this book also a good entry point, although not aimed at as broad an audience. The book contains many interesting ideas. It might not be right about everything — what is?! — but will probably induce you to think differently about the work that you do.
"digitalSTS: A Field Guide for Science & Technology Studies" edited by Janet Vertesi and David Ribes
This is a collection of articles on topics related to the intersection of STS and "digital" aka “computers.” The text is definitely not targeted at a broad audience, but boy is it ever useful and illuminating for research software engineers who necessarily operate in the liminal space between scientific research and software engineering.
Image information
For more information about the image above, please see the blog post at the Mastcam-Z instrument site. Last-mile processing for this image was performed by software created by Million Concepts.
Author Bio
Chase Million is the founder and CEO of Million Concepts, a research and consulting company that provides support services — including software development — to research efforts, primarily in the fields of planetary science and astronomy. As a 2021 BSSw fellow, he created a guide to research software project estimation.
