Growing Team Community and Effectiveness with Retrospectives

Many resources exist to help software engineers increase their coding skills, but how can they learn to be better teammates with one another? How can engineering, product management, and other members of a team build bridges and a shared understanding of what their work involves and how they can help one another? Retrospectives can be an incredibly powerful and helpful tool for reflection and the intentional practice of learning crucial lessons from the recent past in order to guide and help shape the future.

Rethink what a retrospective can be and get excited to start implementing them on your team (or revitalize the one you already have scheduled)! See how retrospectives contribute to a sense of community even in virtual workspaces, and hear several examples of activities to get everyone reflecting and listening.

Deploy Without Fear Using Automated Tests

As Kent Beck advises, "Write tests until fear is transformed into boredom," and anyone who has been witness to a production deployment issue is all too aware of this fear. Tests can help us gain confidence in the code we are about to write and in the CI/CD environments we have set up so that the act of pushing new changes can be stressless and perhaps even fun.

There are several tools we can use for testing applications, and various levels at which to test. When is it time to write a new test? Should that new test be a unit test or an integration test? Just what is the difference between unit and integration? Is end-to-end testing a worthy investment? And how do I get started?

I will answer these questions and more based on my experience and opinions as a full-stack software engineer who has written tests at every level. I will also demonstrate how I helped take an application with low test coverage and began introducing new tests using libraries like Playwright and React Testing Library, and adding them in our GitHub Actions workflows.

Remote Mob Programming: An Introvert's Tale of Working Collaboratively

How is it possible for a team to collaborate better than they ever have before, all while never commuting to an office again? How can you increase code quality while also intentionally fostering a sense of community and human connection? And, even if it is possible, how do you convince people to give it a try?

I am an introvert, and, for nearly 3 years now, I have preferred to write code in all-workday-long video calls. It seems like a contradiction, with so many software developers able and encouraged to write code completely solo, but I feel that the benefits of remote mob programming are worth a deep dive exploration, and anyone who is curious how it could even be possible to work in such a way is sure to learn something interesting.

Come learn what mob programming is and how it can possibly be effective in an organization. Listen to stories of how this style of work is possible in a remote job, and understand not just the potential benefits but also the technical and social challenges. And even if you prefer to work on your own or are not even a software developer yourself, you will gain a new perspective in how creating and maintaining things together—both within teams and across departments—can deliver better results and instill a sense of connectedness.

This talk has been given at Atlanta Developers’ Conference 2023 but has been reworked a bit since. In the coming weeks, I will also have been on a podcast (Mob Mentality Show) to discuss this talk and its contents. It is one part an explainer of what remote mob programming is, one part personal story of how different kinds of programmers prefer different ways of working, and one part an appeal to community and empathy and how that can be done in a remote job. It is meant to appeal to experienced programmers, aspiring programmers, and non-programmers (designers, product owners, managers, et al.) alike.

Scully: The Angular Static Site Is Out There

Angular is a powerful web application framework that helps us build impressive enterprise applications, but as static "Jamstack" sites grow in popularity, those who maintain Angular apps may feel the grass is greener with other technologies that are optimized for faster page rendering. Fortunately, the open source tool Scully is a static site generator that works with Angular to pre-render content and deliver fast and secure websites that can still connect to APIs to render dynamic content as needed. In this talk, I will demonstrate Scully by showing how it can be added to an existing Angular project, explain how it actually works behind the scenes to produce the new static assets, and recommend some good practices for incrementally improving your Angular applications.

Target audience is web developers, especially those who have used Angular, as they would benefit most and have the most context. But all are welcome who wish to attend and all terms will be explained. This is a tool that I have experience using and I have given a one-hour version of this talk to co-workers as a way of explaining the viability of possibly using it in our production tech stack. This talk is a mix of slides to explain definitions and sharing my screen to show actual code samples. Requires Internet connection if at all possible to show demonstration of an actual deployment. I have experience speaking at several conferences in the past year of various formats and sizes (Atlanta Code Camp, Big Mountain Data & Dev, & Devnexus).

Buried in Technical Debt? Prioritizing the Important Maintenance

Have you ever taken a shortcut to complete a task, assuring yourself that you would go back and clean it up and do it the right way later when you had the time? In software, this is called “technical debt,” and when it piles up, it can make code hard to read and maintain. Soon enough, the cost to fix these problems can become too high, and coming up with a plan for your team to take action becomes increasingly difficult.

In this talk, we will discuss the different types of technical debt and tips on how to convince other people in the organization of the importance of making regular “minimum payments.” We also cover some creative strategies and analogies to keep in mind to balance out technical maintenance along the other urgent product-focused work, as well as considerations for projects with extensive “accrued interest.”

This is a talk I have given at in-person conferences (Atlanta Code Camp 2021, Devnexus 2022, devopsdays Atlanta 2023), virtual conferences (Big Mountain Data & Dev 2021, Festive Tech Calendar 2021), and local user group meetups (St. Louis Java Users Group, Modern Web ATL). It introduces a definition and explanation of technical debt but also speaks to some of the pain points that it can cause and the ways in which it manifests; it will feel relevant for people who have been in a software development role, but it will also be informative to people new to the concept and help them understand what to look for in the future. This talk will be specially tailored to the PHP-focused audience with content about how my company managed to take its application on out-of-date Laravel and out-of-date PHP versions and create a plan to collaborate to accomplish this feat. This is a standard format lecture talk.

Making Time for Accessibility: Basic Principles and Building for Conformance

What message are we telling our users when they log into a product that didn't prioritize accessibility? Have we put up barriers? Will they assume we wanted to exclude them? There are many types of disabilities, and without a careful effort to consider the experiences of all users, we could easily unintentionally create frustrated users and decrease engagement and revenue. There could also be legal risks with inaccessible web applications, especially when they are served by the public sector or provide public services. Customers and stakeholders will want to be assured of the compliance of products such as these, but even if organizations can agree to take accessibility seriously, where would they start?

This talk provides a basic foundation of web accessibility principles that software engineers, UX designers, and product managers should know. Learn about a variety of automated and manual testing strategies, and why accessibility is not something we can simply ask a robot agent to do for us. There are many guidelines to consider, but it is possible to start taking action, and I will share personal stories of the transformations we are making in our product, processes, and people to remediate existing issues and ensure a commitment to conformance moving forward.

My hope is to share with you the value of web accessibility and to inspire you to start incorporating accessibility work into every part of the software development process.