Roscoe A. Bartlett: I was a late arrival to writing code. I did not start programming until my freshman year in college in 1993. My first computer was a Gateway that my father purchased for me for $3,000 (a lot of money in 1993). The first programming language I learned was Quick Basic. During my time at UMBC, I wrote some more software in a few different programming languages including graphical programming with LabView to do real-time data-collection and control of a laboratory distillation column (I was a Chemical Engineering student). After my B.S. in Chem. E., I took a year off before starting graduate school and wrote a good bit of software for a congressional campaign and as a research assistant at University of Maryland, Baltimore County (UMBC).

When I started my Ph.D. in Chemical Engineering at Carnegie Mellon University (CMU) in 1996, I knew I liked writing code. In my first year at CMU, I enjoyed the challenge of learning and mastering the C++ programming language (pre-1998 standardization). My first C++ book was "C++ Nuts & Bolts for Experienced Programmers", 1995, by Herbert Schildt, and I read that book cover-to-cover in approximately two days. A few months later, I read Bjarne Stroustrup’s book "The C++ Programming Language, 2nd Edition". While that book mostly just covered the C++ language, Stroustrup made some references to writing tests and some other basic software engineering best practices, but it was pretty minimal (after all, this was a book about a programming language, not software engineering). Later in my first year of graduate school, I was introduced to the book "Design Patterns" by a computer science Ph.D. student at CMU. Armed with the knowledge of C++ and Design Patterns, I set about writing a sizable amount of software implementing advanced numerical algorithms for constrained optimization as part of my Ph.D. work (the optimization package, at that point, for reduced successive quadratic programming was called rSQP++).

When I started working at Sandia National Labs in 2001 after my Ph.D., I continued writing object-oriented parallel numerical software in C++, extending my Ph.D. software package rSQP++ to support parallel computations with MPI (changing the name of rSQP++ to MOOCHO). Around 2003, I added the source code (and history) for MOOCHO to the Trilinos project version control repository. Once in the Trilinos community, I created or significantly contributed to many Trilinos packages. By 2007, I had written a considerable amount of software and was a prolific contributor to Trilinos (the largest contributor to Trilinos in the number of commits). During that entire period from 1996 till 2007 I believed that I was writing quality object-oriented C++ software. Then, in 2007, I began reading a larger portion of the modern software engineering literature (see my reading list) and came to realize my knowledge gap in best practices for creating and maintaining quality software. After this realization, I began applying many of the software engineering best practices to my CSE projects and realized significant improvements in productivity and the overall quality of the software I was writing. However, I was also horrified to realize that, prior to gaining this knowledge, I had created tens of thousands of lines of CSE software of insufficient quality and that I was now in a position to have to maintain.

I got involved in the IDEAS project when it first started in 2014 and worked with people from other Dept. of Energy (DOE) laboratories to write some of the precursor material for BSSw.io. In 2017, the IDEAS project was reborn within the Exascale Computing Project as IDEAS-ECP, the BSSw.io site was started, and it incorporated much of that material. Editing and contributing to BSSw.io was an opportunity for me to share some of what I had learned with the rest of the broader CSE/HPC community and to learn from the community, from the other IDEAS-ECP members, and especially from the other BSSw.io editorial staff. For me, the opportunity to work with a diverse group of individuals, and to hear and learn from such a variety of different perspectives, has deepened my understanding of software engineering best practices for CSE/HPC. I have truly valued the opportunity to contribute to and be an editor for the BSSw.io site. I am thankful there is a home for ideas and information about how to practice software engineering for CSE/HPC where content can be quickly created and published and yet has higher editorial standards than you might just put out yourself. BSSw.io provides an attractive compromise between speed-to-publish, formality, and peer review that sets it apart from other publication venues.

David Bernholdt: I've been working with scientific software for nearly 40 years now (geez!). My interest in better software engineering arose out of working with some large teams on some pretty large code bases -- initially thinking that there must be a better way to do software development, and then having the opportunity to work in a team that did do a better and more thoughtful job with the software. Since then, I've been trying to pick up better ways of doing things, and when I have a chance, implement them in my own work. Over the years, I've tapped whatever I could find to help me -- people who seemed to know useful things, papers, books, etc. So when the idea of BSSw.io came up, it seemed quite natural for me to get involved. To me, BSSw.io is both a source to help me keep learning about software engineering and also a way to thank all the people whom I learned from by helping to make similar resources available to the larger community.

I learn something from pretty much every new article that we publish on BSSw.io because there are so many different experiences and perspectives out there. As an editor for the site, much of my time lately has been focused on shepherding our blog series. I particularly enjoy the contributions that bring a topic or a viewpoint that I hadn't thought about before, or in some cases, hadn't even been aware of. A recent example, and I think appropriate for this harvest season, was the article Long-Term Software Gardening Strategies for Cultivating Scientific Development Ecosystems by Dave Bunten and Gregory Way. With a little sleuthing on the internet, I learned that this gardening metaphor for software stewardship was not new, but it was one that I'd never run across before. And it really resonated with me because it addressed aspects of the software lifecycle and software ecosystems that colleagues and I have been struggling with in other projects. The same kind of thing often happens with new curated content articles too, of course, though my experience as an editor is not as intense -- probably because I'm not immersed in someone else's writing on the topic. As an editor, I also shepherd many of the contributions to our event listings, which I really appreciate because they illustrate how vibrant and diverse the scientific software community is.

Overall, I guess I would say I'm thankful for our many contributors to BSSw.io for sharing their knowledge, experience, and energy with me and with the broader community.

Lois Curfman McInnes: I am truly grateful to collaborate with such a talented and committed community on advancing scientific software (practices, people, products, applications, and more) as the central means of discovery computational science and engineering (CSE). A sincere thank you to all BSSw.io readers and contributors --- and to complementary groups around the world who are working to advance the cause of high-quality scientific software as a primary means of encapsulating expertise and sustaining collaboration across disciplines.

After my experience as a graduate student in writing my own software for algorithmic investigations in iterative numerical methods, I had the good fortune to partner with Bill Gropp and Barry Smith to develop PETSc-2.0, building on the (then newly defined) MPI standard. Since that time, I have thoroughly enjoyed the expansion of collaboration on advanced scientific computing throughout the international community, and especially across DOE labs. I am grateful for continual learning from one another and progress together to advance the culture of scientific software.

Pat Grubel: I started on the IDEAS-ECP team as a post-doctoral researcher at Los Alamos National Laboratory and was asked to join the team when my predecessor (also my mentor) had taken on new roles at the lab so needed a replacement. It was an opportunity to meet experts across the DOE complex who advocated for quality software to advance science, so it sounded like a good opportunity. My first meeting with the team was an in-person meeting and I was just getting to know team members and a little bit about their roles when they wanted to split the meeting in two. The topic I picked was to work on the BSSw.io site that aimed to be a community hub for those who faced the many challenges of producing and maintaining scientific software in the increasingly complex and changing landscape of HPC. I spent most of my career as an engineer and picked up software development on my own. I had recently returned to graduate school for computer engineering, studying and improving the performance of programming models on the underlying architecture. Although developing software was a necessary tool, and I was able to collaborate with several scientific software teams, I had not given much thought to the best practices of developing and maintaining software or the challenges that scientific software teams faced in collaborating on the many large software projects that exist.

Looking for and reviewing articles and resources for the BSSw.io site first helped me with personal organization and productivity. Then, trying to keep up with some of the best practices that experts like other editorial board members and the community found helpful aided me with projects. I attempted to practice some of these new (to me) ideas on my projects and was eventually asked to be the technical lead on a software project. At that point, helping the team members with productivity and best software practices became very important. The project team has been incrementally applying some of the practices and tools found in resources and articles on the site and has been improving software development processes. I am grateful for the many articles and helpful resources on the site and glad to be a small part of it. The best part of being on the editorial team has come from meeting the team members and working with them. Knowing them and gleaning insights from their knowledge has been extremely helpful and enjoyable.

Rinku Gupta: As I reflect on my journey in the scientific computing field over the past 25 years, I can't help but feel an overwhelming sense of gratitude for the evolution of my understanding and engagement with software sustainability. When I started as a research software engineer, delving into the intricacies of programming models, fault tolerance, resilience, networks, and operating systems consumed my professional landscape. However, it wasn't until I joined the IDEAS-ECP project that the concept of software sustainability truly entered my awareness. Initially viewing it as a redundant addition to our existing practices, my perspective underwent a profound shift. The IDEAS-ECP project revealed the depth and breadth of sustainability issues within scientific computing, a revelation that has significantly shaped the latter part of my career in the last several years.

Discovering that many scientific projects, including my own, didn't really dig deep into the nitty-gritty of sustainability did hit me hard. Jumping into the IDEAS-ECP project helped me see the real challenges and opportunities in keeping our software strong. This newfound awareness, coupled with my subsequent role as the Editor-in-Chief for the Better Scientific Software website, has provided me with a unique vantage point. It allowed me to gain insights into how our community perceives and prioritizes software sustainability, productivity, and quality. This deep dive changed how I see sustainability in scientific computing. For this expanded awareness and the chance to champion the cause through the Better Scientific Software platform, I am profoundly thankful.

Navigating the role of Editor-in-Chief for the Better Scientific Software website has been more than a professional milestone—it's a journey that echoes my own path from being a student in India to finding my way to the USA. Arriving in the USA as a student, several decades ago, marked the beginning of a transformative journey, filled with diverse experiences and working alongside people from various backgrounds. It's a journey that unfolded into a role where I now stand, amidst discussions that shape the future of scientific computing. The chance to bridge gaps in understanding within our vibrant scientific computing community, spanning continents and cultures, is something I cherish. This journey, from my roots in India to my current role in the USA, has not only added professional richness but has also strengthened my commitment to work on things that I am passionate about. I am thankful for the opportunities presented by BSSw.io and this diverse scientific computing community, and it's my hope that together we can pave the way for a more sustainable and collaborative future in the field.

Michael A. Heroux: My first experience with software quality assessment was with my supervisor in 1984 when I asked him to try out my menu-driven IBM BASIC program I had carefully designed for one of the original IBM PCs. I had it up and running at my desk. He sat in my chair and started randomly tapping letters on my keyboard. Of course, I had never planned for anyone to select any key except those I was expecting, and the program crashed in seconds. Oh, well.

Since then, I have worked on many software projects, working on LIBSCI for Cray, vendor codes from ANSYS, and many open-source libraries for the scientific community. I stepped into reproducibility, productivity, and sustainability initiatives about 15 years ago when observing that if we wanted to encourage software quality improvement on projects, we needed to build knowledge and change expectations around the quality of our software work. No one wants to do a bad job on their software, but producing papers, completing milestones, and moving on to the next urgent task compete for our time and attention. I am grateful to be part of the BSSw community that is so committed to better scientific software.

Mark C. Miller: I am pretty sure I was the only kid in my neighborhood with a home computer. Back in 1975, my father borrowed a colleague's IMSAI-8080. I learned to program it mainly by transcribing published Basic games like Hamurabi or Lunar Lander. I recall that powering it on involved a peculiar process of flipping a number of paddle switches. It wasn't until years later that I realized I had been entering three 8-bit words for a JSR instruction to initiate the boot sequence. Soon, we replaced that borrowed machine with our own Commodore PET. On a bet with my Chemistry teacher, I wrote a Basic program for it to compute molecular weights from formulae (e.g. 8Fe(H₂O)₄(OH)₂).

With that early start in programming, it may be ironic that I was never formally educated in computer science. I never took courses in compilers, networks, or operating systems. My formal education is in Electrical Engineering. I was once able to analyze the heck out of a transistor circuit or calculate the far-field of a perfectly conducting cylinder. I finally fully understood how computers worked only after taking a PDB-11 assembly language course.

All my interest and experience in programming grew out of the application of software in other projects. As a child, I wanted to create a digital Dungeons and Dragons game (and promptly exhausted the 8 kilobytes of PET memory). My graduate work first grew out of the need to recover under sampled periodic signals from streak camera rotors and later to compress a disk-resident terrain database for a real-time rendering application.

I am thankful for all those experiences because they paved the way for me to eventually find work as a computer scientist at LLNL. Although my formal job title for the last ~30 years has been Computer Scientist, I identify more as a Software Engineer. I have rarely developed a C++ class from scratch. I am still inclined to write procedural rather than object-oriented code. I debug with print statements more often than I'd like to admit.

That being said, I am thankful LLNL has nonetheless continued to invest in developing my software engineering skills through a mix of on-the-job training and formal course offerings in various scientific computing technologies. Through the pandemic, I was extremely grateful LLNL fully embraced and pivoted to remote work and required masks and vaccinations for on-site workers.

More than anything else, I am thankful for the great fortune of working around and with many, highly skilled and talented scientific software professionals who have generously shared their tricks, tips, and software engineering know-how with me either directly in conversation or by osmosis through trusting me to work on code they develop and maintain. Honestly, there have been many days where I have felt pretty sheepish to be seated at the same table with these amazingly talented people.

Being a contributor to the IDEAS-ECP project has only broadened and deepened that experience to include many friends and colleagues across the DOE complex at other national labs. I am thankful to the many dedicated members of the scientific computing community for their willingness to work with me, their confidence in my work, their patience and help in diagnosing and fixing bugs, their ability to roll up their sleeves and dig into my code when I've needed help, their suggestions for improvement, their sharing of data and results and their advocacy and citations of the software I support.

Deborah S. Stevens: My introduction to programming began with being told not to build card houses out of my father’s active card decks or else the Key Punch girls would be upset. From this start at age 6 of filling the entire living room with a forbidden card house, my interest in computer programming was trying to read the cards to find an ordering system. In 5th and 6th grade I would go with my brother to our father’s office on the weekends at the Air Force base and we played Adventure with the twisty curvy passages. In middle school, I saw the early at-home computing machine access where the handset of the wired phone (that I wanted to use to talk to my friends) was socketed into two round rubber cradles of an early modem.

I did take the mandatory programming class in high school in 1984 and the teacher would give us assignments and then leave the classroom. I usually would finish these as she walked out the door and then use the time to get other homework done.

After earning my doctorate in applied mathematics at Northwestern University in 1999 and having two children (’98 and ’01) the household focus was such that my career took a backseat to caregiving for some time. About 6 years ago, on a bet with my spouse (I’ll exercise with you, if you learn Python) I took the Coursera series of Python classes at the University of Michigan and much enjoyed it.

My work with the IDEAS-ECP project and the BSSw.io Editorial Board for the last 2 years has been enlightening. I have found the community welcoming and understanding. I appreciate the tolerance of my fumbling attempts at using github.com. I am thankful for being able to work in this environment and for the creative group of people who support BSSw.io.