<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Quality on Jesse Builds Software</title>
    <link>https://jessemcdowell.ca/tags/quality/</link>
    <description>Recent content in Quality on Jesse Builds Software</description>
    <generator>Hugo</generator>
    <language>en-CA</language>
    <lastBuildDate>Fri, 09 May 2025 19:33:22 -0700</lastBuildDate>
    <atom:link href="https://jessemcdowell.ca/tags/quality/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Disambiguating Scalability</title>
      <link>https://jessemcdowell.ca/2025/05/Disambiguating-Scalability/</link>
      <pubDate>Fri, 09 May 2025 19:33:22 -0700</pubDate>
      <guid>https://jessemcdowell.ca/2025/05/Disambiguating-Scalability/</guid>
      <description>&lt;p&gt;Although it was years ago, I still remember the conversation vividly. I was having my regular check-in with the CTO. It was also sunny outside, and the view from his office was particularly nice that day.&lt;/p&gt;&#xA;&lt;p&gt;He asked me, &amp;ldquo;Is our app scalable?&amp;rdquo; After a moment of thought, I answered, &amp;ldquo;Yes.&amp;rdquo;&lt;/p&gt;&#xA;&lt;p&gt;I spent the next few years remembering that conversation, wondering what would have happened if I had asked what he meant by scalable.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Writing Code for Better Reviews</title>
      <link>https://jessemcdowell.ca/2024/04/Writing-Code-for-Better-Reviews/</link>
      <pubDate>Wed, 24 Apr 2024 14:37:05 -0700</pubDate>
      <guid>https://jessemcdowell.ca/2024/04/Writing-Code-for-Better-Reviews/</guid>
      <description>&lt;p&gt;I believe code reviews are a high-value activity (which &lt;a href=&#34;https://jessemcdowell.ca/2024/01/Optimal-Code-Reviews/&#34;&gt;I&amp;rsquo;ve written about before&lt;/a&gt;), but they take time and slow down your development process. With a few simple tricks, you can make it easier for reviewers to understand your changes, allowing them to give you better feedback faster. Not only does this save everyone time, but it also improves the quality of your code.&lt;/p&gt;&#xA;&lt;div class=&#34;table-of-contents&#34;&gt;&#xA;    &lt;nav id=&#34;TableOfContents&#34;&gt;&#xA;  &lt;ul&gt;&#xA;    &lt;li&gt;&lt;a href=&#34;#make-your-intentions-understood&#34;&gt;Make your intentions understood&lt;/a&gt;&lt;/li&gt;&#xA;    &lt;li&gt;&lt;a href=&#34;#group-changes-by-intention-one-intention-at-a-time&#34;&gt;Group changes by intention, one intention at a time&lt;/a&gt;&lt;/li&gt;&#xA;    &lt;li&gt;&lt;a href=&#34;#break-up-large-changes-into-multiple-reviews&#34;&gt;Break up large changes into multiple reviews&lt;/a&gt;&lt;/li&gt;&#xA;    &lt;li&gt;&lt;a href=&#34;#avoid-high-noise-low-value-changes&#34;&gt;Avoid high-noise, low-value changes&lt;/a&gt;&lt;/li&gt;&#xA;    &lt;li&gt;&lt;a href=&#34;#establish-shared-hygiene-to-reduce-noise&#34;&gt;Establish shared hygiene to reduce noise&lt;/a&gt;&lt;/li&gt;&#xA;    &lt;li&gt;&lt;a href=&#34;#rebase-with-care&#34;&gt;Rebase with care&lt;/a&gt;&lt;/li&gt;&#xA;    &lt;li&gt;&lt;a href=&#34;#review-your-work-before-asking-others&#34;&gt;Review your work before asking others&lt;/a&gt;&lt;/li&gt;&#xA;    &lt;li&gt;&lt;a href=&#34;#understand-your-review-tool&#34;&gt;Understand your review tool&lt;/a&gt;&lt;/li&gt;&#xA;  &lt;/ul&gt;&#xA;&lt;/nav&gt;&#xA;&lt;/div&gt;&#xA;&#xA;&lt;h2 id=&#34;make-your-intentions-understood&#34;&gt;Make your intentions understood&lt;/h2&gt;&#xA;&lt;p&gt;Good commit messages and review titles are important. It may be (and in fact, should be) obvious from your code change what you&amp;rsquo;re trying to do, but a good message is still important. There are lots of cases where someone needs to scan the change list, and good messages make this a lot easier. It also helps your reviewer understand what you&amp;rsquo;re doing.&lt;/p&gt;</description>
    </item>
    <item>
      <title>The True Cost of Dependencies</title>
      <link>https://jessemcdowell.ca/2024/03/The-True-Cost-of-Dependencies/</link>
      <pubDate>Wed, 27 Mar 2024 15:35:10 -0700</pubDate>
      <guid>https://jessemcdowell.ca/2024/03/The-True-Cost-of-Dependencies/</guid>
      <description>&lt;p&gt;I used to use Getform for a contact form on &lt;a href=&#34;https://pragmaticpotato.com&#34;&gt;my consulting company website&lt;/a&gt;. I recently received an email from them announcing that their free tier was dropping from 50 submissions per month to a lifetime limit of 25. This makes it useless for anything more than a trial, and their lowest tier is a more expensive than other similar options.&lt;/p&gt;&#xA;&lt;p&gt;I&amp;rsquo;m not here to complain about companies taking back free offerings. I don&amp;rsquo;t like the change, and I wish they&amp;rsquo;d given me more than three days of notice, but they are a businesses, and businesses need to make money. It is a good reminder though: even if something is free to use, it still takes time and effort to integrate, to maintain, and you may occasionally need to throw it out and find a replacement.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Optimal Code Reviews</title>
      <link>https://jessemcdowell.ca/2024/01/Optimal-Code-Reviews/</link>
      <pubDate>Thu, 04 Jan 2024 14:11:32 -0800</pubDate>
      <guid>https://jessemcdowell.ca/2024/01/Optimal-Code-Reviews/</guid>
      <description>&lt;p&gt;I am a strong advocate for code reviews. They have many advantages including improving code quality and team communication. On the other hand, they take a lot of time and add yet another delay to the development pipeline. With the wrong team culture, they can create hard feelings and discourage honest collaboration. This is a heavy price to pay, and yet, I&amp;rsquo;ve seen many teams that do them without ever talking about how or why.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Regarding Test Coverage Targets</title>
      <link>https://jessemcdowell.ca/2023/08/Regarding-Test-Coverage-Targets/</link>
      <pubDate>Mon, 21 Aug 2023 11:28:52 -0700</pubDate>
      <guid>https://jessemcdowell.ca/2023/08/Regarding-Test-Coverage-Targets/</guid>
      <description>&lt;p&gt;Unit tests are undeniably a good thing, but you only realize the full benefits of them when you have enough tests that you can make changes with confidence. If you can make a change, run your tests, and be comfortable enough to ship your changes, then you and your team can get work done much faster. More drastic changes to the shared code become feasible. Life gets better.&lt;/p&gt;&#xA;&lt;p&gt;It makes sense then that teams want to ensure that code is sufficiently covered with tests. Nobody wants to count tests every time they review a PR, so tools are added that check it automatically. It&amp;rsquo;s then a small step to set a coverage target, and suddenly you have a machine checking every PR for tests. This all makes sense to me, and it was my first instinct too. I don&amp;rsquo;t recommend this approach any more.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Sustainable Errors</title>
      <link>https://jessemcdowell.ca/2023/05/Sustainable-Errors/</link>
      <pubDate>Mon, 29 May 2023 09:57:05 -0700</pubDate>
      <guid>https://jessemcdowell.ca/2023/05/Sustainable-Errors/</guid>
      <description>&lt;p&gt;Making a program work for the happy path is not always easy, but given enough time I believe pretty much anyone could do it. When a professional takes on the task however they will make it work for more than just the happy path, and do it with code that is easy to debug, and easy for others to understand and change. Since so much of what we end up dealing with are exceptional flows, we need a concise way to deal with them. Fortunately we have the aptly named exception pattern.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Is the Bug Fun?</title>
      <link>https://jessemcdowell.ca/2023/05/Is-the-Bug-Fun/</link>
      <pubDate>Mon, 15 May 2023 10:47:52 -0700</pubDate>
      <guid>https://jessemcdowell.ca/2023/05/Is-the-Bug-Fun/</guid>
      <description>&lt;p&gt;There are many things about producing video games that are surprising, but one of the weirdest has to be the approach to bugs. Like any piece of software, bugs are found through testing or user reports, triaged, then assigned to developers. Unlike normal business software they also ask the question, &amp;ldquo;is the bug fun?&amp;rdquo;&lt;/p&gt;&#xA;&lt;p&gt;There are plenty of unintended features (bugs) in games that became beloved. Attack combos were an accident in Street Fighter II, but they became so popular that they are a part of basically every fighting game now. Rocket jumps are another example. The internet is full of examples.&lt;/p&gt;</description>
    </item>
    <item>
      <title>How to Fix a Bug</title>
      <link>https://jessemcdowell.ca/2023/04/How-to-Fix-a-Bug/</link>
      <pubDate>Mon, 24 Apr 2023 08:50:00 -0700</pubDate>
      <guid>https://jessemcdowell.ca/2023/04/How-to-Fix-a-Bug/</guid>
      <description>&lt;p&gt;Building applications can be tricky, and it&amp;rsquo;s inevitable that mistakes will be made. As a result, we programmers spend a lot of time fixing bugs. Sometimes they are easy, but sometimes they can be pretty tough to figure out.&lt;/p&gt;&#xA;&lt;p&gt;I&amp;rsquo;ve fixed a lot of bugs in my career, and to be honest with you, I usually enjoy the process. These days I am typically assigned the super urgent bugs that nobody else can figure out, and I kind of like it that way. I don&amp;rsquo;t get me wrong, I don&amp;rsquo;t like the bugs being there, but I enjoy being helpful and figuring out tough problems. I also think my successes have helped improve my reputation which is always a good thing.&lt;/p&gt;</description>
    </item>
    <item>
      <title>How to Report a Bug</title>
      <link>https://jessemcdowell.ca/2023/03/How-to-Report-a-Bug/</link>
      <pubDate>Fri, 10 Mar 2023 21:40:00 -0800</pubDate>
      <guid>https://jessemcdowell.ca/2023/03/How-to-Report-a-Bug/</guid>
      <description>&lt;p&gt;Nobody likes bugs, least of all programmers. No matter how hard we try to catch them early, some will always escape into circulation. Until computers are smart enough to do what we meant instead of what we said, users are going to keep finding bugs, and we&amp;rsquo;re going to keep fixing them.&lt;/p&gt;&#xA;&lt;p&gt;Before a bug is fixed, it needs to be reported. Unfortunately it&amp;rsquo;s not uncommon to receive incomplete reports. We can spend a lot of time hunting and making guesses, and sometimes that&amp;rsquo;s enough, but if we can&amp;rsquo;t figure out the problem it&amp;rsquo;s pretty hard to fix it. This can be especially unfortunate when the stakes are high, and oddly, this is when it also seems to be the most common.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Reading Server Graphs: Connected Users</title>
      <link>https://jessemcdowell.ca/2013/06/reading-server-graphs-connected-users/</link>
      <pubDate>Fri, 14 Jun 2013 22:30:44 -0700</pubDate>
      <guid>https://jessemcdowell.ca/2013/06/reading-server-graphs-connected-users/</guid>
      <description>&lt;p&gt;I&amp;rsquo;ve spent the last several years working on multi-user server systems in two different companies. Both those companies had a giant monitor hanging off a wall showing a graph of connected users. It won&amp;rsquo;t give you detailed diagnostic information, but it is a good indicator for the health of your servers, and your product generally. If you learn to notice certain patterns in your user graph, it can also save you precious time when things go wrong.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
