<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Software Engineering on Leonard Austin</title>
    <link>https://c05b76f5.leonardaustin.pages.dev/tags/software-engineering/</link>
    <description>Recent content in Software Engineering on Leonard Austin</description>
    <generator>Hugo</generator>
    <language>en-GB</language>
    <lastBuildDate>Fri, 20 Mar 2026 18:00:00 +0000</lastBuildDate>
    <atom:link href="https://c05b76f5.leonardaustin.pages.dev/tags/software-engineering/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>I Vibe Coded a Full-Stack Kubernetes App in 21 Days</title>
      <link>https://c05b76f5.leonardaustin.pages.dev/posts/vibe-coding-a-full-stack-app-in-21-days/</link>
      <pubDate>Fri, 20 Mar 2026 18:00:00 +0000</pubDate>
      <guid>https://c05b76f5.leonardaustin.pages.dev/posts/vibe-coding-a-full-stack-app-in-21-days/</guid>
      <description>&lt;p&gt;&lt;strong&gt;tl;dr&lt;/strong&gt; — I built a full-stack Kubernetes desktop application — Go backend, React/TypeScript frontend, brochure website — in 21 days using AI-assisted &amp;ldquo;vibe coding.&amp;rdquo; 74,675 lines of source code. 461 commits. 129 pull requests. 100% merge rate. I never read a single line of the source code. Here&amp;rsquo;s exactly how it worked, what I actually typed, and what I learned.&lt;/p&gt;&#xA;&lt;h2 id=&#34;what-i-built&#34;&gt;What I Built&lt;/h2&gt;&#xA;&lt;p&gt;Clusterfudge is a native macOS desktop app for managing Kubernetes clusters. Think of it as a Lens competitor: cluster overview, pod management, log streaming, exec terminals, Helm chart management, YAML editing, resource wizards, a troubleshooting page, and an AI debugging terminal that calls Claude Code to diagnose live pods. Plus a brochure website.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Etiquette for Tech Teams</title>
      <link>https://c05b76f5.leonardaustin.pages.dev/posts/etiquette-for-tech-teams/</link>
      <pubDate>Sat, 10 Mar 2018 10:25:40 +0100</pubDate>
      <guid>https://c05b76f5.leonardaustin.pages.dev/posts/etiquette-for-tech-teams/</guid>
      <description>&lt;h2 id=&#34;for-a-happy-workplace&#34;&gt;For a Happy Workplace&lt;/h2&gt;&#xA;&lt;p&gt;This article attempts to offer some of the rules for a productive, cohesive and enjoyable working environment for tech teams. It is a semi-working article that I will add to over time.&lt;/p&gt;&#xA;&lt;p&gt;&lt;img src=&#34;https://c05b76f5.leonardaustin.pages.dev/images/meetings.webp&#34; alt=&#34;meetings&#34;&gt;&lt;/p&gt;&#xA;&lt;h3 id=&#34;meetings&#34;&gt;Meetings&lt;/h3&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;Always include an Agenda and Objective to meeting invites. It helps invitees decide whether the meeting is relevant to them.&lt;/li&gt;&#xA;&lt;li&gt;Long blocks of uninterrupted time is when the magic happens, for most engineers. Be mindful of this when scheduling meetings. The “best” time will differ depending on who you are inviting to the meeting.&lt;/li&gt;&#xA;&lt;li&gt;Default meeting duration is 30 minutes. Meetings longer than 1 hour tend to become unproductive: avoid them.&lt;/li&gt;&#xA;&lt;li&gt;Keep in mind everyone in the meeting, avoid tangents that are not applicable to the majority of the room. Stick to the agenda! Some conversations should just go into a ticket or google doc.&lt;/li&gt;&#xA;&lt;li&gt;At any point, excuse yourself from a meeting if it is not relevant to you.&lt;/li&gt;&#xA;&lt;li&gt;Announcing the meeting in #meetings slack channel. Don’t invite the whole company to every meeting, but allow people to invite themselves to things that are of interest to them.&lt;/li&gt;&#xA;&lt;li&gt;If you need a room make sure you book a room, so you’re not taking it from anybody else.&lt;/li&gt;&#xA;&lt;li&gt;Feel free to use your laptops in meetings unless the host specifically states otherwise.&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;hr&gt;&#xA;&lt;p&gt;&lt;img src=&#34;https://c05b76f5.leonardaustin.pages.dev/images/headphones.webp&#34; alt=&#34;headphones&#34;&gt;&lt;/p&gt;</description>
    </item>
    <item>
      <title>Engineering Team Core Values</title>
      <link>https://c05b76f5.leonardaustin.pages.dev/posts/engineering-team-core-values/</link>
      <pubDate>Mon, 15 Jan 2018 10:17:14 +0100</pubDate>
      <guid>https://c05b76f5.leonardaustin.pages.dev/posts/engineering-team-core-values/</guid>
      <description>&lt;h3 id=&#34;simple-code-is-elegant&#34;&gt;Simple Code is Elegant&lt;/h3&gt;&#xA;&lt;p&gt;Tidy, readable, simple code is paramount. It makes reviewing PR easier, it makes coming back to the code after 18 months easier, it makes your peers like you more.&lt;/p&gt;&#xA;&lt;h3 id=&#34;anti-gossip&#34;&gt;Anti-Gossip&lt;/h3&gt;&#xA;&lt;p&gt;Constructive conversations over background criticism. Call it out when you see it (even if in other parts of the company). If you feel the need to complain, make a difference and give feedback instead.&lt;/p&gt;&#xA;&lt;h3 id=&#34;approachable&#34;&gt;Approachable&lt;/h3&gt;&#xA;&lt;p&gt;During busy times, when you are deep in code and stress is mounting, it is easy to forget to Treat Others as You Would Expect to be Treated and be “approachable”. Others should not be worried about talking to you. Definitely no jerks, even if they are geniuses. Adjust your technical language when speaking to non-technical staff.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Ravelin Tech Stack</title>
      <link>https://c05b76f5.leonardaustin.pages.dev/posts/ravelin-tech-stack/</link>
      <pubDate>Tue, 15 Aug 2017 10:46:43 +0100</pubDate>
      <guid>https://c05b76f5.leonardaustin.pages.dev/posts/ravelin-tech-stack/</guid>
      <description>&lt;h2 id=&#34;an-overview-of-ravelins-technology&#34;&gt;An Overview of Ravelin’s Technology&lt;/h2&gt;&#xA;&lt;p&gt;I write this post as an overview of each aspect Ravelin’s technology stack; almost not worthy of the hours and days that each component has taken to implement. This overview will not attempt to deep dive into any given topic but, where possible, link out to sources and reference material. The intention is to write more specifically and in far greater detail over the coming months.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Train Every Software Engineer to Be a Penetration Tester</title>
      <link>https://c05b76f5.leonardaustin.pages.dev/posts/train-every-software-engineer-to-be-a-penetration-tester/</link>
      <pubDate>Mon, 31 Jul 2017 11:44:55 +0100</pubDate>
      <guid>https://c05b76f5.leonardaustin.pages.dev/posts/train-every-software-engineer-to-be-a-penetration-tester/</guid>
      <description>&lt;p&gt;Because security matters&lt;/p&gt;&#xA;&lt;h2 id=&#34;the-idea&#34;&gt;The Idea&lt;/h2&gt;&#xA;&lt;p&gt;External Pen Testers are useful, but only have a limited amount of time to get to know our systems and are not intimately familiar with the Ravelin codebase. On the other hand, engineers and data scientists within Ravelin know the codebase inside out (they wrote it after all), they understand the API and the expected functionality. Why not train all technical staff on Pen Testing? Not only will they gain experience with security awareness, leading to a more secure code but also have a bit of fun during War Games.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
