<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Quality on Hi, I'm Braddy</title><link>https://yeohbraddy.com/tags/quality/</link><description>Recent content in Quality on Hi, I'm Braddy</description><generator>Hugo</generator><language>en</language><lastBuildDate>Sun, 05 Oct 2025 21:18:34 +0100</lastBuildDate><atom:link href="https://yeohbraddy.com/tags/quality/index.xml" rel="self" type="application/rss+xml"/><item><title>Speed is a feature and why moving fast improves quality</title><link>https://yeohbraddy.com/posts/speed-is-a-feature-why-moving-fast-improves-quality/</link><pubDate>Sun, 01 Jun 2025 12:00:00 +0000</pubDate><guid>https://yeohbraddy.com/posts/speed-is-a-feature-why-moving-fast-improves-quality/</guid><description>&lt;blockquote>
&lt;p>“Speed and quality aren’t at odds - they’re often positively correlated.” - Nan Yu, Linear&lt;/p>&lt;/blockquote>
&lt;p>When I first started out as an engineer, I assumed that “moving fast” meant rushing, cutting corners, or skipping due diligence. Sure, sometimes it does if you’re careless. However, over time, especially working in a startup environment, I’ve learned something that surprised me:&lt;/p>
&lt;p>Speed can actually improve quality.&lt;/p>
&lt;p>Not in a reckless way, but in a focused, practiced, high-feedback-loop kind of way. The best engineers and teams I’ve worked with move quickly because they care about quality. They know what matters, what can wait, and how to learn through iteration. They don’t aim for perfect upfront. They aim to learn fast and improve continuously.&lt;/p></description></item></channel></rss>