<?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>software engineering on Matt Sencenbaugh</title>
    <link>https://mattsencenbaugh.com/tags/software-engineering/</link>
    <description>Recent content in software engineering on Matt Sencenbaugh</description>
    <generator>Hugo -- gohugo.io</generator>
    <lastBuildDate>Thu, 26 Jan 2023 00:00:00 +0000</lastBuildDate><atom:link href="https://mattsencenbaugh.com/tags/software-engineering/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Invert your assertions</title>
      <link>https://mattsencenbaugh.com/invert-your-assertions/</link>
      <pubDate>Thu, 26 Jan 2023 00:00:00 +0000</pubDate>
      
      <guid>https://mattsencenbaugh.com/invert-your-assertions/</guid>
      <description>TDD Tip: Invert your assertion One top tip I picked up years ago from a co-worker was to invert your assertions when you are in the midst of your TDD cycles.
In other words, if you have an RSpec assertion like this:
expect(foo.nil?).to be_truthy
flip the truthy to falsey and run the test
expect(foo.nil?).to be_falsey
What you want to see there is that your test fails. In a &amp;lsquo;true&amp;rsquo; TDD environment the test would be perfectly clean and no state would be acting on your subject, but that&amp;rsquo;s just not how most test suites for production products work.</description>
    </item>
    
    <item>
      <title>Macroservices - A Pragmatic Approach For Small Teams</title>
      <link>https://mattsencenbaugh.com/macroservices-a-pragmatic-approach-for-small-teams/</link>
      <pubDate>Thu, 13 Jun 2019 00:00:00 +0000</pubDate>
      
      <guid>https://mattsencenbaugh.com/macroservices-a-pragmatic-approach-for-small-teams/</guid>
      <description>In an ideal world, all software projects would be written well. Full test suite, a good ci/cd pipeline, and a general focus on maintainability.
If that&amp;rsquo;s the world you live in, or your org spends a lot of time from the onset of a project optimizing for a clean codebase, this is nirvana. One well kept monolith keeps complexity down across the board. No complicated SOA, deployment tooling, or failure case handling.</description>
    </item>
    
    <item>
      <title>Programmatically Change S3 Storage Class To Glacier</title>
      <link>https://mattsencenbaugh.com/programmatically-change-s3-storage-class-to-glacier/</link>
      <pubDate>Thu, 08 Mar 2018 00:00:00 +0000</pubDate>
      
      <guid>https://mattsencenbaugh.com/programmatically-change-s3-storage-class-to-glacier/</guid>
      <description>The glacier storage class within Amazon S3 is a great way to reduce costs for files you don&amp;rsquo;t think you will ever need again, but want to have stick around just in case.
Unfortunately the AWS SDK doesn&amp;rsquo;t provide a way to transition an object to the Glacier storage class; you can only transition to Infrequent Access and no further. Here is my quick hack to enable that ability:
 Create a special folder in your S3 bucket named &amp;lsquo;archive&amp;rsquo; (or whatever you like).</description>
    </item>
    
    <item>
      <title>Where is next November?</title>
      <link>https://mattsencenbaugh.com/where-is-next-november/</link>
      <pubDate>Thu, 28 Apr 2016 00:00:00 +0000</pubDate>
      
      <guid>https://mattsencenbaugh.com/where-is-next-november/</guid>
      <description>Today I finished up The Mythical Man Month by Frederick Brooks, which is a surprisingly relevant collection of essays about software engineering, despite being written 42 years ago. Some of the essays I found quite boring, but those were usually essays that also detailed systems specific to the 70s. Most of the book tends to deal with the people of software engineering, and management tactics around the profession.
I won&amp;rsquo;t rehash them all here; however there is one section in No Silver Bullet - Refired that I found particularly compelling:</description>
    </item>
    
    <item>
      <title>iOS Design Patterns: The Builder</title>
      <link>https://mattsencenbaugh.com/ios-design-patterns-the-builder/</link>
      <pubDate>Tue, 05 Jan 2016 00:00:00 +0000</pubDate>
      
      <guid>https://mattsencenbaugh.com/ios-design-patterns-the-builder/</guid>
      <description>One of the things I&amp;rsquo;d like improve in 2016 is my knowledge of software engineering design patterns, with a particular emphasis on iOS. I&amp;rsquo;ll be posting a quick summary of each one I stumble across on the blog so that my future self can find things again easily.
Today&amp;rsquo;s pattern is called &amp;lsquo;The Builder&amp;rsquo;. The intent of the pattern is to make it easy to create objects with a lot of initial configurations, without bloating your code with a bunch of long initializers.</description>
    </item>
    
    <item>
      <title>Hobbyist Game Programming - The Beginning</title>
      <link>https://mattsencenbaugh.com/hobbyist-game-programming-the-beginning/</link>
      <pubDate>Sun, 28 Jul 2013 00:00:00 +0000</pubDate>
      
      <guid>https://mattsencenbaugh.com/hobbyist-game-programming-the-beginning/</guid>
      <description>Let&amp;rsquo;s do this!!!! I&amp;rsquo;ve been itching to make a game for the iPhone for a few years now and I&amp;rsquo;m finally ready to take the plunge. I&amp;rsquo;m going to be updating this blog regularly, hopefully weekly, to keep everyone updated and to keep me honest. I haven&amp;rsquo;t found too many detailed accounts of the creation of an iphone game online so I hope it will give some insight to future game makers.</description>
    </item>
    
    <item>
      <title>Landing Your First Programming Internship</title>
      <link>https://mattsencenbaugh.com/landing-your-first-programming-internship/</link>
      <pubDate>Sat, 27 Jul 2013 00:00:00 +0000</pubDate>
      
      <guid>https://mattsencenbaugh.com/landing-your-first-programming-internship/</guid>
      <description>I landed my first programming internship the summer of my sophomore year of college through a combination of dumb luck, an interesting portfolio, being able to speak business rather than just &amp;ldquo;nerd&amp;rdquo;, and a spectacularly bad technical interview. I still remember how nervous I felt walking into the in-person interviews, the hot shame I felt when I failed to answer a pretty simple technical question, and the shock of surprise when I was hired.</description>
    </item>
    
    <item>
      <title>The &#34;Priority Queue&#34; Development Process</title>
      <link>https://mattsencenbaugh.com/the-priority-queue-development-process/</link>
      <pubDate>Fri, 15 Mar 2013 00:00:00 +0000</pubDate>
      
      <guid>https://mattsencenbaugh.com/the-priority-queue-development-process/</guid>
      <description>TLDR - Programmers are bad at giving time estimates so we shouldn&amp;rsquo;t ask them to. To be more efficient an organization should experiment with a process that simply places 3 items in each developers &amp;lsquo;PQueue&amp;rsquo; and let them finish it.
PQueue My tech teammate was up from Austin this week and suggested that our dev team try out a process similar to what his old team used at Demand Media. The basic idea is that instead of doing agile or waterfall, Demand Media simply assigned each developer a queue of the highest priority tasks they could be working on at that moment (with a cap of 3).</description>
    </item>
    
    <item>
      <title>On Being a Junior Developer</title>
      <link>https://mattsencenbaugh.com/on-being-a-junior-developer/</link>
      <pubDate>Tue, 20 Nov 2012 00:00:00 +0000</pubDate>
      
      <guid>https://mattsencenbaugh.com/on-being-a-junior-developer/</guid>
      <description>Junior developer (for purposes of this post)is a developer with &amp;lt; 2 years experience programming in industry who have an interest in sharpening their technical skills.
I recently graduated from Stanford with a degree in Computer Science. I&amp;rsquo;ve been programming for 4 years and feel comfortable claiming ~1.5 years industry experience through summer internships, failing as a solo founder, being a lead engineer for a startup, various freelance gigs, and my current position at a mobile health startup I helped found in December.</description>
    </item>
    
  </channel>
</rss>
