<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>System Design on Maceage's Blog</title><link>https://blog.maceage.com/tags/system-design/</link><description>Recent content in System Design on Maceage's Blog</description><generator>Hugo</generator><language>en-au</language><copyright>© Graham Mace</copyright><lastBuildDate>Fri, 30 Aug 2024 00:00:00 +0000</lastBuildDate><atom:link href="https://blog.maceage.com/tags/system-design/index.xml" rel="self" type="application/rss+xml"/><item><title>System Design Learnings</title><link>https://blog.maceage.com/posts/2024/system-design-learnings/</link><pubDate>Fri, 30 Aug 2024 00:00:00 +0000</pubDate><guid>https://blog.maceage.com/posts/2024/system-design-learnings/</guid><description>&lt;p&gt;As a software engineer who grew up developing desktop applications before moving into web development, I spent most of my career in the depths of application code rather than infrastructure.&lt;/p&gt;&#10;&lt;p&gt;Hosting and networking were handled by other teams or companies – my responsibility was writing software that ran on top of that stack, not worrying about the foundation beneath it.&lt;/p&gt;&#10;&lt;p&gt;But that landscape has shifted. System design interviews are now ubiquitous in tech hiring, particularly at scale-focused companies. These interviews assess your ability to architect and scale systems – a skill set that&amp;rsquo;s become as crucial as coding ability itself.&lt;/p&gt;</description></item><item><title>Codifying Architecture: Diagrams as Code</title><link>https://blog.maceage.com/posts/2024/codifying-architecture/</link><pubDate>Sun, 03 Mar 2024 00:00:00 +0000</pubDate><guid>https://blog.maceage.com/posts/2024/codifying-architecture/</guid><description>&lt;p&gt;&lt;small&gt;&lt;i&gt;(Originally drafted in August 2019 during my tenure at Xero. Republished here in March 2024 with updated context and removed proprietary references)&lt;/i&gt;&lt;/small&gt;&lt;/p&gt;&#10;&lt;p&gt;Engineers love writing code. There&amp;rsquo;s nothing quite like instantly seeing the fruits of your labour appear on a screen – immediate feedback and the joy of getting something working.&lt;/p&gt;&#10;&lt;p&gt;Engineers, however, tend to hate writing documentation. It takes time, it&amp;rsquo;s seen as overhead to &amp;ldquo;real work,&amp;rdquo; and so it falls by the wayside. The next engineer to come along is told: &lt;em&gt;&amp;ldquo;Oh, that&amp;rsquo;s out of date – just look at the &amp;lsquo;self-documenting&amp;rsquo; code instead.&amp;rdquo;&lt;/em&gt;&lt;/p&gt;</description></item><item><title>The C4 Model: From Attendee to Facilitator</title><link>https://blog.maceage.com/posts/2024/the-c4-model/</link><pubDate>Sun, 25 Feb 2024 00:00:00 +0000</pubDate><guid>https://blog.maceage.com/posts/2024/the-c4-model/</guid><description>&lt;p&gt;&lt;small&gt;&lt;i&gt;(Originally drafted in December 2019 during my tenure at Xero. Republished here in February 2024 with updated context and removed proprietary references)&lt;/i&gt;&lt;/small&gt;&lt;/p&gt;&#10;&lt;p&gt;In late 2019, I attended a workshop at &lt;a href="https://yowcon.com/" target="_blank"&gt;YOW! Melbourne&lt;/a&gt; run by &lt;a href="https://simonbrown.je/" target="_blank"&gt;Simon Brown&lt;/a&gt;, the creator of the C4 model. It turned out to be one of the most useful conference sessions I&amp;rsquo;ve ever been to.&lt;/p&gt;&#10;&lt;p&gt;What made it valuable wasn&amp;rsquo;t salesmanship – though you could be forgiven for initially wondering whether you were sitting through a pitch. Simon was excellent at explaining &lt;em&gt;why&lt;/em&gt; the format exists, why other approaches tend to fall down, and what C4 offers compared to heavier alternatives like &lt;a href="https://www.omg.org/uml/" target="_blank"&gt;UML&lt;/a&gt; and &lt;a href="https://www.bpmn.org/" target="_blank"&gt;BPMN&lt;/a&gt;.&lt;/p&gt;</description></item></channel></rss>