Third annual Developer Day encourages best practices
Developer Day—an all-day event designed to encourage sharing and collaboration across various programs—is officially a tradition. Now in its third year, Dev Day was held on July 25 and included quick presentations on a range of topics, several deep dives, a keynote speaker, and a panel discussion dedicated to the onboarding process.
John Grosh, Computing’s deputy associate director of mission development, kicked off the day by discussing LLNL’s increasing emphasis on producing and developing software—a core capability and priority for the directorate. He stated, “Developer Day is key part of our Directorate’s software engineering strategy. This field moves very quickly. Events and activities such as these help us stay at the leading edge and build an LLNL community of practice that supports almost all of our lab’s critical missions.” For example, Grosh noted, maintaining and upgrading our software capabilities helps the Laboratory keep pace with threats from adversaries.
Computer scientists David Beckingsale, Kyle Dickerson, and Elsa Gonsiorowski coordinated Dev Day with the help of administrators Nicole Armbruster, Jamie Goodale, and Tristan Jensen. More than 100 employees registered for the event, which was organized in a new format this year. The morning sessions fit into a theme of Lifecycle of a Software Developer, while the theme of the afternoon sessions was Creating Better Software. In addition to networking breaks between sessions, Gonsiorowski noted, “We were able to bring in an external speaker for the keynote as well as provide lunch for everyone.”
Keynote on Code Reviews
Following the panel, Jeffrey Carver, professor in the University of Alabama’s computer science department, gave the keynote address. He spoke about the importance of code reviews and how to make them effective for developers and reviewers alike. Carver’s presentation, “Contemporary Peer Code Review Practices in Research Software,” suggested ways to approach code reviews with a constructive mindset. For example, the code review process can do more than find bugs; it can help a team enforce consistency and quality, share knowledge, and explore different perspectives.
“We all make mistakes and sometimes can’t find the problem. There’s value in bringing in another set of eyes to review your work,” said Carver, who described techniques for reviewing code and providing meaningful feedback. He continued, “We tend to be protective of our code. Aim for peace and harmony in code reviews. They are not meant to be antagonistic.”
Figure 1. Jeffrey Carver from the University of Alabama explains how to make code reviews effective.
Lifecycle of a Software Developer
Dev Day’s morning sessions included a panel discussion about onboarding new developers. Panelists were summer student mentor Thomas Bennett, workforce administrator Emily Brannan, group leader John Consolati, and computer scientist Daniel Osei-Kuffuor. Fielding questions from the audience, the panelists explained how the Computing Directorate ensures that new employees’ hardware and software tools are ready to go on day one and that teammates are standing by to answer any questions. The panel also described onboarding process improvements under way at LLNL.
Much of the panel discussion focused on how to support new hires as they learn how a national lab works and acclimate to LLNL. Consolati advised, “Seasoned employees can help broaden a new person’s network as much as possible to foster their independence.” Former intern and postdoc Osei-Kuffuor added, “Introduce them to others in their area so they have a larger support system. You can provide opportunities for interaction with others who have similar interests.”
Figure 2. Workforce administrator Emily Brannan (second from left) answers audience questions during the onboarding panel.
The morning concluded with “quick takes” by David Bloss and Kevin Athey. Bloss outlined the seven stages of expertise in software engineering—a heuristic devised by methodology expert Meilir Page-Jones that describes the software engineer’s path from “total ignorance” to “world-class knowledge.” These stages may inspire an employee’s career growth and help managers assess a developer’s aptitude.
Athey reviewed an article, “Bored People Quit,” by author and blogger Michael Lopp. Among other advice, the article suggests that managers notice when employees are ready for new challenges and let them experiment. Athey applied Lopp’s concepts to software development, noting that managers should not stop coding; they should remain versed in changing technologies so they can better connect with colleagues.
Creating Better Software
Dev Day’s afternoon began with two deep-dive talks. John Lee spoke about LLNL-approved cloud services, while Vicki Pope explained software risk grading at the Lab. “‘Risk grading’ is a term that can evoke horror among developers,” said Pope. “Mission-critical software produced at the Lab must be evaluated to balance programmatic needs, scientific and technological creativity, and quality requirements.” She demonstrated LLNL’s tool that manages the risk-grading process.
Subsequent presentations by Corey McNeish, Raul Viera Mercado, and Ian Lee focused on tooling with C++, Java virtual machines, and Python, respectively. The afternoon closed with quick takes by Thomas Mendoza, who outlined the history of Unicode and character sets along with current best practices, and Dickerson, who described a 12-factor app that encourages consistency and reproducibility of software-as-a-service.
Overall, the organizing committee was pleased with the third installment of Dev Day. Attendees were invited to fill out a survey: 93% of respondents reported meeting someone new, while 87% indicated they learned something new that will improve their work at LLNL. “Our goal is to connect developers and help them become better,” Dickerson pointed out. “So it sounds like Dev Day is achieving that quite well.”
Figure 3. Computer scientist Daniel Osei-Kuffuor speaks about his LLNL onboarding experiences as a student intern and a postdoctoral researcher.