📅 April 27, 2022
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
- 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
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