<?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 Enrico Mischorr</title>
    <link>https://enrico.mischorr.com/posts/</link>
    <description>Recent content in Posts on Enrico Mischorr</description>
    <image>
      <title>Enrico Mischorr</title>
      <url>https://enrico.mischorr.com/%3Clink%20or%20path%20of%20image%20for%20opengraph,%20twitter-cards%3E</url>
      <link>https://enrico.mischorr.com/%3Clink%20or%20path%20of%20image%20for%20opengraph,%20twitter-cards%3E</link>
    </image>
    <generator>Hugo -- 0.155.3</generator>
    <language>en</language>
    <lastBuildDate>Wed, 10 Dec 2025 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://enrico.mischorr.com/posts/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Building a Voice Assistant From Scratch — What Nobody Tells You About the Decisions That Actually Matter</title>
      <link>https://enrico.mischorr.com/posts/building_voice_assistant_from_scratch/</link>
      <pubDate>Wed, 10 Dec 2025 00:00:00 +0000</pubDate>
      <guid>https://enrico.mischorr.com/posts/building_voice_assistant_from_scratch/</guid>
      <description>&lt;p&gt;When I set out to build my own voice assistant, I had a seemingly simple mental model: capture audio, transcribe it, send it to an LLM, speak the response. Four boxes on a whiteboard, a few arrows between them. How hard could it be?&lt;/p&gt;
&lt;p&gt;Turns out, the arrows are where all the interesting engineering happens. And the boxes? Each one hides a small universe of trade-offs that only reveal themselves once you start building for real hardware, real latency requirements, and real-world constraints.&lt;/p&gt;</description>
    </item>
    <item>
      <title>How to structure teams</title>
      <link>https://enrico.mischorr.com/posts/how_to_structure_teams/</link>
      <pubDate>Fri, 12 Apr 2024 00:00:00 +0000</pubDate>
      <guid>https://enrico.mischorr.com/posts/how_to_structure_teams/</guid>
      <description>&lt;p&gt;You&amp;rsquo;ve probably seen it: a reorganization rolls out, someone draws new boxes on a chart, and within months the same coordination problems resurface — just wearing different names. The issue isn&amp;rsquo;t that the structure was &lt;em&gt;wrong&lt;/em&gt;. It&amp;rsquo;s that nobody asked the right questions before drawing those boxes.&lt;/p&gt;
&lt;p&gt;I recently read &lt;em&gt;Team Topologies&lt;/em&gt; by Matthew Skelton and Manuel Pais, and it crystallized something I&amp;rsquo;ve felt across the last years of leading teams and building software: team structure isn&amp;rsquo;t a template you copy. It&amp;rsquo;s a design decision — and like all design decisions, it comes with trade-offs.&lt;/p&gt;</description>
    </item>
    <item>
      <title>The problem with Snapshot Testing</title>
      <link>https://enrico.mischorr.com/posts/proplem_with_snapshot_testing/</link>
      <pubDate>Sat, 11 Feb 2023 00:00:00 +0000</pubDate>
      <guid>https://enrico.mischorr.com/posts/proplem_with_snapshot_testing/</guid>
      <description>&lt;p&gt;I&amp;rsquo;ve seen it in code reviews. And you probably too. A PR changes a button&amp;rsquo;s color, and suddenly 47 snapshot tests fail. The author updates them all with &lt;code&gt;--updateSnapshot&lt;/code&gt;, the reviewer skims past 200 lines of &lt;code&gt;.snap&lt;/code&gt; file changes, and everyone moves on. No one actually verified anything.&lt;/p&gt;
&lt;p&gt;This is snapshot testing&amp;rsquo;s dirty secret: &lt;strong&gt;it feels like testing without actually being it.&lt;/strong&gt;&lt;/p&gt;
&lt;h2 id=&#34;what-snapshot-tests-actually-assert&#34;&gt;What Snapshot Tests Actually Assert&lt;/h2&gt;
&lt;p&gt;I know, most developers probably like snapshot testing. It&amp;rsquo;s easy. And it takes away all the effort to write tests. But if that&amp;rsquo;s what you&amp;rsquo;re looking for you could just as well skip tests as a whole and &amp;ldquo;safe&amp;rdquo; yourself the work.&lt;/p&gt;</description>
    </item>
    <item>
      <title>How to Find Good People to Hire (Without Competing on LinkedIn)</title>
      <link>https://enrico.mischorr.com/posts/how_to_find_good_people/</link>
      <pubDate>Sat, 21 Aug 2021 00:00:00 +0000</pubDate>
      <guid>https://enrico.mischorr.com/posts/how_to_find_good_people/</guid>
      <description>&lt;p&gt;LinkedIn is a crowded battlefield. If you&amp;rsquo;re not a well-known name or don&amp;rsquo;t have recruiter budgets to burn, your job posting is competing against thousands of others — and losing. The good news? Some of the best candidates aren&amp;rsquo;t actively job hunting on platforms at all. They&amp;rsquo;re learning, building, and showing up in places most companies overlook.&lt;/p&gt;
&lt;p&gt;Here&amp;rsquo;s where to find them.&lt;/p&gt;
&lt;h2 id=&#34;universities-get-there-before-everyone-else&#34;&gt;Universities: Get There Before Everyone Else&lt;/h2&gt;
&lt;p&gt;The most obvious advantage of university recruiting is access to talent before the market gets to them. But the less obvious advantage is even better: students are often more adaptable, curious, and willing to grow into a role than someone who&amp;rsquo;s been doing the same job for five years. As an added bonus, they often bring in new ideas and tech-stacks your older colleagues are not aware of.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Becoming a Team Lead can be harder than being one</title>
      <link>https://enrico.mischorr.com/posts/becoming_team_lead_harder_than_being_team_lead/</link>
      <pubDate>Sun, 25 Oct 2020 00:00:00 +0000</pubDate>
      <guid>https://enrico.mischorr.com/posts/becoming_team_lead_harder_than_being_team_lead/</guid>
      <description>&lt;p&gt;Nobody would have thought that the hardest part of becoming a team lead wasn&amp;rsquo;t the leading — it was the becoming.&lt;/p&gt;
&lt;p&gt;When I made the switch from senior engineer to team lead, I somehow expected a clean break. Old role ends on Friday, new role starts on Monday. In hindsight that was naive. In reality, the transition stretched over months. And during that time, I was stuck in a no man&amp;rsquo;s land that was more exhausting than the team lead role itself.&lt;/p&gt;</description>
    </item>
    <item>
      <title>How You Know You&#39;re Doing Scrum Wrong</title>
      <link>https://enrico.mischorr.com/posts/how_you_know_you_do_scrum_wrong/</link>
      <pubDate>Thu, 05 Mar 2020 00:00:00 +0000</pubDate>
      <guid>https://enrico.mischorr.com/posts/how_you_know_you_do_scrum_wrong/</guid>
      <description>&lt;p&gt;Here&amp;rsquo;s the truth about Scrum: if you&amp;rsquo;re following it to the letter, you&amp;rsquo;re probably doing it wrong.&lt;/p&gt;
&lt;p&gt;I&amp;rsquo;ve seen teams treat the Scrum Guide like holy scripture — rigidly executing every ceremony, obsessing over story point accuracy, and monitor process compliance. Meanwhile, they ship late, burn out, and wonder why this &amp;ldquo;agile&amp;rdquo; thing doesn&amp;rsquo;t feel very agile.&lt;/p&gt;
&lt;p&gt;The problem isn&amp;rsquo;t Scrum itself. It&amp;rsquo;s confusing the &lt;em&gt;practices&lt;/em&gt; with the &lt;em&gt;principles&lt;/em&gt;.&lt;/p&gt;
&lt;h2 id=&#34;the-one-size-fits-all-trap&#34;&gt;The &amp;ldquo;One Size Fits All&amp;rdquo; Trap&lt;/h2&gt;
&lt;p&gt;Scrum was designed as a framework, not a rulebook. Yet many teams adopt it as a fixed template: two-week sprints, daily standups at 9:15, retros on Friday, refinement on Monday. Copy-paste from a random team that posted about it on the internet.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
