xUnit Expanded - Better Testing With xUnit

xUnit is one of the most used testing tools for C#, yet its full capability often goes underutilized.

Unfortunately, there isn't much guidance or documentation for developers in terms of what libraries to use with xUnit or some of the more uncommon functionality of xUnit itself, keeping much of its use to the realm of learned experience.

This talk will cover some xUnit tips and tricks that come from just that. Through a coding demo, you'll learn how to make tests easier to write and more robust, as well as other lesser-known libraries and patterns that can be used in tandem with it to fully unlock its potential.

This session is tailored both to those with many years of testing, as well as those new to it. The advice in it is intended to be a set of practical patterns and libraries that any skill level can take advantage of.

Presentation outline:
- Motivation
- Libraries used
- Parallelism in xUnit
- FluentAssertions
- Coding demo (this will be the bulk of the presentation)
- Recap, closing thoughts, questions

Hearing and Being Heard - Getting the Entire Team to Speak

Many of us have been on teams where the same few people speak every meeting, and likewise, the same few people very rarely ever speak. Often, we also fall into one of those categories ourselves. Learn why this happens, why it's beneficial for everybody if the whole team participates, what happens when participation isn't equal, and practical actions to take to encourage all individuals to share their opinions and concerns.

At first glance, it can be confusing to navigate this issue. Should team members be required to say something, or called on directly? What if they truly have nothing to say? Are there any benefits from addressing this? How do we get all people to participate and share knowledge, and more than that, do so comfortably?

Regardless of your role on the team, this talk will address these questions and give you practical actions to take to help your team feel safe and get the feedback, opinions, and concerns of all of its members.

Instruments of Change: How to Measure Developer Productivity

In the fast-paced world of software development, the goal of measuring developer productivity has gained traction recently, yet it remains a touchy subject. Tools like story points and DORA metrics have become more popular, though teams often expend effort tracking these values without knowing why or what action to take from the data. Without a clear strategy in mind for implementing these measurements, companies can very easily lose time, money, and the trust of their teams. This talk is for any leaders or team members who have concerns such as:
-What metrics should we be measuring and why are we measuring them?
-Am I going to be disciplined if I perform worse than other teams?
-Should we measure developer productivity at all? Can we take any actions from the data?
Drawing from firsthand experience from being on both sides of leadership and development, I’ll begin this talk will begin with the end in mind – covering what the goals ultimately are when measuring developer productivity. Crucially, attendees will also gain clarity on which metrics are truly meaningful for their organization. After covering potential motivations and benefits, I’ll talk about what metrics can be worth leveraging for your organization, as well as how to measure them.
Being a developer myself, I’ll particularly talk about these metrics from that perspective. Additionally, this talk will cover organizational patterns for teams that I have seen succeed and foster a culture of continuous improvement, as well as those common pitfalls that ultimately undermine your efforts and alienate teams from leadership.
When implemented carefully, I’ve found that teams will lean into measuring their productivity for their own sake so that they can improve themselves. The organization reaps the benefits in the form of less defects, faster feature development, and a happier workforce.

-What is productivity?
-Goals
-Measuring productivity
-Measuring value
-Getting value as early as possible
-Iteration, feedback, and team empowerment
-Continuous improvement
-Tech practices
-Recap, closing thoughts, and questions

This talk is intended both for developers who may be curious or anxious about these things happening in their organization, as well as leadership who are interested in measuring these things themselves (or currently doing so).

Many organizations implement this by tracking the amount of tickets completed, rather than the amount of value added. This talk will attempt to explain why tracking purely the amount of work done misses the mark and (rightly) makes developers more anxious. It will also go into some specific metrics and how to use them correctly as a guideline, such as DORA metrics.

Moreover, it will go over some tech practices and organization patterns that facilitate faster iteration for faster value add, which I find is what organization usually really want. This includes things such as teams owning their work without outside approvals, pushing straight to prod, and automated testing