Intro

I am late on a recap of CodeMash 2022 considering the conference was back in January, but I came across a few things worth sharing. CodeMash is a conference held at Kalahari Resorts in Sandusky, Ohio. The sessions are a smorgasbord of different technologies. Some sessions don't involve technology at all. This year was my fourth time attending.

Below are some of my highlights from sessions I attended.

The Art of Readable Code

• Code for other developers
• Building software is like writing a book
  • Outline
  • Write
  • Revise
  • Review
  • Release
• Coding is social
  • Having a shared understanding of the domain is extremely important.
• Read code out loud to understand intent.
• Avoid magnet classes (Common, Manager, etc.)

Finding Your Flow With Kanban

• If you know your throughput, you can do a JIT prioritization and backlog grooming.
  • Example: We're getting 5 stories done a week, we need to make sure the next 5 most important things in the backlog are ready to go. We don't need to review 10+ stories.

Building Reusable components | slides

• Treat your reusable components as a product.
• Make the impossible, impossible
  • Lead other developers into the pit of success. Make getting into an invalid state impossible.
• Start with a rigid design. Least amount of props. Be opinionated at first. Default for the most common use cases.

Making the most of your DevOps Artifacts

• Projects that only publish to a NuGet feed might not need separate release pipelines. Can just deploy from the build pipeline.
• I learned about stages and conditions with build pipelines. I used to set up two pipelines. One for verification (dotnet format, dotnet test) and one for running dotnet publish to create the artifacts. I realized I could just combine those into one pipeline and set up a validation stage with a condition to only run during a pull request:

- stage: Validation
  condition: eq(variables['Build.Reason'], 'PullRequest')

and a build stage that ran when not a pull request:

- stage: Build
  condition: ne(variables['Build.Reason'], 'PullRequest')

Tribal Knowledge in Agile Teams | slides

• Have a knowledge base - pick one.
• Demo your documentation. Treat it like a first class citizen.

Supercharge Your ASP.NET Core Applications | video

• Health Checks

Design Patterns for Loosely Coupled Applications | video, slides

We really do change data stores. You have changed data stores if:

• You tested middle-tier logic in isolation (without testing the DB)
• You changed from a file-source to a relational store or web-service
• You added an API layer in front of an existing DB
• You added a caching layer in front of a data source
• You moved from a local DB to a cloud implementation

#development