<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Posts on Grant Ammons</title>
    <link>https://grant.dev/posts/</link>
    <description>Recent content in Posts on Grant Ammons</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <copyright>Copyright 2022 by Grant Ammons</copyright>
    <lastBuildDate>Sun, 22 Dec 2019 15:40:11 -0400</lastBuildDate>
    <atom:link href="https://grant.dev/posts/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>What I learned creating 12inch.reviews, a mashup of Spotify and Pitchfork</title>
      <link>https://grant.dev/posts/12inch-reviews-mashup/</link>
      <pubDate>Sun, 22 Dec 2019 15:40:11 -0400</pubDate>
      <guid>https://grant.dev/posts/12inch-reviews-mashup/</guid>
      <description>&lt;p&gt;&lt;img loading=&#34;lazy&#34; src=&#34;https://grant.dev/images/12inch.reviews.png&#34;&gt;&lt;/p&gt;
&lt;p&gt;I&amp;rsquo;m a huge music nerd.  I&amp;rsquo;ve played in many bands in my teens 20s, and music is a big part of my life.. I&amp;rsquo;m also a big fan of &lt;a href=&#34;https://pitchfork.com/&#34;&gt;Pitchfork&lt;/a&gt; music reviews.&lt;/p&gt;
&lt;p&gt;There was a mashup site I was using called &lt;a href=&#34;http://pitchify.com&#34;&gt;Pitchify&lt;/a&gt;, which was no longer updating, and it eventually got taken down.  So I did what any engineer would do and I created my own mashup!&lt;/p&gt;
&lt;p&gt;&lt;a href=&#34;https://12inch.reviews&#34;&gt;12inch.reviews&lt;/a&gt; is a mashup of Pitchfork&amp;rsquo;s &lt;a href=&#34;https://pitchfork.com/reviews/albums/&#34;&gt;album reviews&lt;/a&gt; with Spotify&amp;rsquo;s &lt;a href=&#34;https://developer.spotify.com/documentation/web-playback-sdk/quick-start/&#34;&gt;web playback SDK&lt;/a&gt;.  It utilizes the browser&amp;rsquo;s &lt;a href=&#34;https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API&#34;&gt;IndexedDB API&lt;/a&gt; to allow for fast, responsive searching and sorting of 17k+ album reviews, and allows you to play the full album right in the browser!&lt;/p&gt;</description>
    </item>
    <item>
      <title>The life-changing benefits of side projects</title>
      <link>https://grant.dev/posts/side-projects/</link>
      <pubDate>Fri, 22 Jul 2016 15:40:11 -0400</pubDate>
      <guid>https://grant.dev/posts/side-projects/</guid>
      <description>&lt;p&gt;I am an avid side project-er. At any point in time I always have at least one “thing” going on in the background that feeds my appetite for playing with new tech and learning new stuff.&lt;/p&gt;
&lt;p&gt;Side projects can be liberating and super fun. They are great for your career overall and could lead to great opportunities. These side projects have had an amazing effect on my career, and they can help yours immensely as well!&lt;/p&gt;</description>
    </item>
    <item>
      <title>How to deliver high-quality software</title>
      <link>https://grant.dev/posts/high-quality-software/</link>
      <pubDate>Wed, 23 Mar 2016 15:40:11 -0400</pubDate>
      <guid>https://grant.dev/posts/high-quality-software/</guid>
      <description>&lt;p&gt;When it comes to software, the term “QA” itself is highly loaded. Because what is it, really? Is it just a thing at the end of the software delivery line, where quality gets lovingly sprayed on at the end, achieving a nice glossy sheen? Is it a separate department that bolts on quality, where the engineers don’t really need to worry about it after they throw it over the wall? Is it that one integration test that one engineer wrote, once, and it’s “probably good enough”? Of course not!&lt;/p&gt;</description>
    </item>
    <item>
      <title>The importance of celebrating success with your team</title>
      <link>https://grant.dev/posts/celebrating-success/</link>
      <pubDate>Sun, 27 Dec 2015 15:40:11 -0400</pubDate>
      <guid>https://grant.dev/posts/celebrating-success/</guid>
      <description>&lt;blockquote&gt;
&lt;p&gt;“Ok, so we launched our new feature last night. However we have 30 customer emails from last night about bugs, and we need to hit those right away. Also the error rate is a little spikey, which probably means there’s more issues, and our response time is up a few ticks. Have a nice day!”&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;What a bummer.&lt;/p&gt;
&lt;p&gt;This is unfortunately how things go during a standup meeting after just after shipping a successful feature. The above narrative might as well be the following instead:&lt;/p&gt;</description>
    </item>
    <item>
      <title>What it really means to practice Agile</title>
      <link>https://grant.dev/posts/what-agile-means/</link>
      <pubDate>Mon, 21 Dec 2015 15:51:55 -0400</pubDate>
      <guid>https://grant.dev/posts/what-agile-means/</guid>
      <description>&lt;blockquote&gt;
&lt;p&gt;&lt;strong&gt;Individuals an interactions over processes and tools.&lt;/strong&gt;&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;Why? Because the first principle of the &lt;a href=&#34;http://agilemanifesto.org/&#34;&gt;Agile Manifesto&lt;/a&gt; is so easy to break. We broke it big time, and we learned a lot when fixing it.&lt;/p&gt;
&lt;p&gt;Tools like Jira seduce you into building a mammoth process that is convoluted and hard to convey to your team. You get blinded by the allure of super-sweet metrics and charts. And so the thought goes: “We’ll know our burndown rate and velocity, and it will all be on this pretty graph, and we’ll put it up on the wall TV, and we shall revel in our newfound measurements!”&lt;/p&gt;</description>
    </item>
    <item>
      <title>Ditching scrum for Kanban - The best decision we&#39;ve made as a team</title>
      <link>https://grant.dev/posts/scrum-for-kanban/</link>
      <pubDate>Mon, 14 Dec 2015 15:40:11 -0400</pubDate>
      <guid>https://grant.dev/posts/scrum-for-kanban/</guid>
      <description>&lt;p&gt;The following is a story about how we matured as an engineering team. We went from an ad-hoc process to Scrum, and used Scrum for a whole year. Scrum leveled us up as a team in terms of structure and process. But it caused major morale issues. Then we found Kanban. We implemented it and have never looked back.&lt;/p&gt;
&lt;h2 id=&#34;from-nothing-to-scrum&#34;&gt;From nothing to Scrum&lt;/h2&gt;
&lt;p&gt;We started using Scrum after using a strange, ad-hoc system of developing software. There was a perception from the rest of the company that things were disorganized. We did not have a PM and did not have a great communication channel to the rest of the company. No one knew when things were shipping or what they included when they shipped. We had quality issues because QA was not a big part of the process, and we did not do peer code reviews, so we spent more time fixing bugs than shipping features.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
