Skip to content

Every Tuesday at 12pm Mountain Time

weekly-dev- chat logo

A casual weekly virtual chat mostly focused on web and software development.

Weekly Dev Chat is a place to ask questions, hear different viewpoints, and get to know your fellow developers. Every week there is an initial topic posted to get the discussion started. Sometimes we discuss the initial topic the entire chat, and other times the topic changes several times through the natural flow of the conversation.

Everyone and anyone are welcome to join as long as you are kind, supportive, and respectful of others.

Types of fun in Software Development

Today's (2026-07-21) topic is applying the types of fun to software development. The 4 types of fun are:

  • Type 1: Fun in the moment and when you remember it.
    Example: Stroll in the park on a nice day with friends. Would do it again in a heartbeat.

  • Type 2: Not fun during the moment but is fun in retrospect.
    Example: Hike to the top of a mountain on a hot day with some great views at the top. Get a feeling of accomplishment.

  • Type 3: Not fun during the moment or when you remember it but often makes the best stories.
    Example: Getting lost at night during a hike and your headlamp isn't working. Holy crap, that was more dangerous than I thought.

There is also a 4th type of fun that some people have added:

  • Type 4: Fun in the moment but regret it later.
    Example: Eating and drinking too much. Often counter to your long-term goals such as staying in shape.

What are some examples of the types of fun in Software Development? Inspired by me recently spending six days hiking to and around Mt. Assiniboine. It was definitely type 2 fun due to the long days of hiking, the mosquitoes, and crappy dehydrated food but great to remember.

Everyone and anyone is welcome to join as long as you are kind, supportive, and respectful of others.

P.S. - Image created by ChatGPT.

Gives examples of the 4 types of fun

Debugging in Production: Stories, Strategies, and Tools

Every developer has a war story about finding and fixing a bug in production. Whether it's a race condition that only appears under load, a timezone calculation gone wrong, or a subtle interaction between two services—production bugs teach us the most valuable lessons.

This week, let's talk about debugging in production: the tools, techniques, and mindsets that help us find root causes fast and ship fixes with confidence.

Discussion starters:

  • What's the most interesting production bug you've debugged? What made it tricky to find?
  • What tools have been game-changers for you: logs, distributed tracing, profilers, debuggers, monitoring, or something else?
  • How do you balance moving fast with being careful when something is broken in production?
  • What's a debugging lesson you learned the hard way that changed how you build systems?

Everyone and anyone is welcome to join as long as you are kind, supportive, and respectful of others. Zoom link will be posted at 12pm MDT.

Rubber Duck Debugging

You've probably heard of this technique: when you're stuck on a problem, you explain it out loud to an inanimate object (the classic is a rubber duck). The act of explaining often helps you spot the flaw you’ve been missing.

Do you use rubber duck debugging? What other tricks work for you, for example:

  • Walking away and taking a break
  • Switching to a completely different task
  • Sleeping on it
  • Asking the "Five Whys"
  • Whiteboarding or drawing out the problem

Everyone and anyone are welcome to join as long as you are kind, supportive, and respectful of others. Zoom link will be posted at 12pm MDT.

alt text