<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Posts on Hi, I'm Braddy</title><link>https://yeohbraddy.com/posts/</link><description>Recent content in Posts on Hi, I'm Braddy</description><generator>Hugo</generator><language>en</language><atom:link href="https://yeohbraddy.com/posts/index.xml" rel="self" type="application/rss+xml"/><item><title>Futureproofing Tines: Fair share orchestration</title><link>https://yeohbraddy.com/posts/futureproofing-tines-fair-share-orchestration/</link><pubDate>Thu, 29 Jan 2026 12:00:00 +0000</pubDate><guid>https://yeohbraddy.com/posts/futureproofing-tines-fair-share-orchestration/</guid><description>&lt;p>&lt;em>Originally published on the &lt;a href="https://www.tines.com/blog/futureproofing-tines-fair-share-orchestration/">Tines Engineering Blog&lt;/a>.&lt;/em>&lt;/p>
&lt;p>One of the more fun and challenging problems I worked on at Tines - redesigning how we orchestrate action runs so that no single customer&amp;rsquo;s workflow can starve everyone else. With over a billion automated actions flowing through the platform every week, our initial simple approach needed an upgrade. We built a fair-share system that pairs deterministic concurrency gating with continuously accruing per-story budgets, and the result is much more predictable performance across the board.&lt;/p></description></item><item><title>Making N+1 query detection actually useful at scale</title><link>https://yeohbraddy.com/posts/making-n+1-query-detection-actually-useful-at-scale/</link><pubDate>Thu, 01 Jan 2026 12:00:00 +0000</pubDate><guid>https://yeohbraddy.com/posts/making-n+1-query-detection-actually-useful-at-scale/</guid><description>&lt;h2 id="why-n1-queries-matter">Why N+1 queries matter&lt;/h2>
&lt;p>An N+1 query is one of the most common performance anti-patterns in applications powered by relational databases. It happens when code loads a collection of records, then lazily fetches an association for each one individually effectively turning what should be 1 query into N+1.&lt;/p>
&lt;pre tabindex="0">&lt;code># 1 query to load users
users = User.where(team_id: team.id)

# + N queries, one per user, to load their profile
users.each { |u| puts u.profile.bio }
&lt;/code>&lt;/pre>&lt;p>At large scale where N might be 100, 200, or 1,000, it&amp;rsquo;s not a great thing:&lt;/p></description></item><item><title>Some advice to my younger self</title><link>https://yeohbraddy.com/posts/advice-for-younger-me/</link><pubDate>Sat, 04 Oct 2025 12:00:00 +0000</pubDate><guid>https://yeohbraddy.com/posts/advice-for-younger-me/</guid><description>&lt;h4 id="build-your-own-worldview">Build your own worldview&lt;/h4>
&lt;p>It is important to develop the skill and habit of thinking for yourself. This aligns choices with values which reduces regret, second-guessing, and a more focused growth. This also allows you to also resist trends and borrowed opinions. All in all, it&amp;rsquo;s clear standards and integrity, high agency, and cleaner tradeoffs.&lt;/p>
&lt;h4 id="avoid-generalization-from-specific-experiences">Avoid generalization from specific experiences&lt;/h4>
&lt;p>It&amp;rsquo;s very easy to default to generalization from specific experiences, especially when contexts are not static. When listening, actively look for examples that weaken the theory and then find ways to improve on the theory. This way, we can understand the world deeply by improving our explanations.&lt;/p></description></item><item><title>Truths about software engineering I learned</title><link>https://yeohbraddy.com/posts/things-i-learned/</link><pubDate>Mon, 08 Sep 2025 12:00:00 +0000</pubDate><guid>https://yeohbraddy.com/posts/things-i-learned/</guid><description>&lt;p>After withdrawing from ETH Zurich in a degree for MSc in CS, majoring in Theoretical Computer Science and Machine Learning, I joined a startup in pursuit of making impact, learning with practical experience, and building. Here is what I learned.&lt;/p>
&lt;h4 id="the-power-of-dogfooding-and-observability">The power of dogfooding and observability&lt;/h4>
&lt;p>It&amp;rsquo;s much easier to come up with ideas when using the product as you feel the rough edges firsthand which promotes thinking about ways to improve it. This is similar to instrumenting what users feel, you can&amp;rsquo;t fix what you can&amp;rsquo;t see.&lt;/p></description></item><item><title>Four disciplines in shipping what matters</title><link>https://yeohbraddy.com/posts/four-pillars/</link><pubDate>Fri, 01 Aug 2025 12:00:00 +0000</pubDate><guid>https://yeohbraddy.com/posts/four-pillars/</guid><description>&lt;p>Recently at work, I started a recurring monthly session focusing on growing engineers, especially younger engineers. These sessions are mostly focusing on career advice, principles, and tools to make engineers more effective.&lt;/p>
&lt;p>This session focused on how to increase impact and demonstrating that impact.&lt;/p>
&lt;p>&lt;em>A small disclaimer before we continue, (good) advice is fuzzy because it entirely depends on the person receiving it.&lt;/em>&lt;/p>
&lt;h4 id="four-disciplines">Four disciplines&lt;/h4>
&lt;p>In software engineering, there are four disciplines:&lt;/p></description></item><item><title>The pen is mightier than the AI model</title><link>https://yeohbraddy.com/posts/the-pen-is-mightier-than-the-ai-model/</link><pubDate>Wed, 23 Jul 2025 12:00:00 +0000</pubDate><guid>https://yeohbraddy.com/posts/the-pen-is-mightier-than-the-ai-model/</guid><description>&lt;p>Today, I received the results and feedback of my product improvement submission for an internal transfer to a PM role. Although writing the submission was already a deeply fulfilling and fun experience, the discussion I had after with Head of Product transcended the experience and led to an important lesson and a reality check for myself.&lt;/p>
&lt;p>In pursuit of my idea of &lt;em>&amp;ldquo;perfection&amp;rdquo;&lt;/em>, I employed the help of AI to aid my storytelling techniques, challenge my assumptions, and guide my answer. However, I failed to realise that the more I used AI to critique and refine, the more I lost the human touch - the clarity of thought and voice.&lt;/p></description></item><item><title>You don't have to choose between infra and product</title><link>https://yeohbraddy.com/posts/you-dont-have-to-choose-between-infra-and-product-and-why-im-glad-i-didnt/</link><pubDate>Sun, 08 Jun 2025 12:00:00 +0000</pubDate><guid>https://yeohbraddy.com/posts/you-dont-have-to-choose-between-infra-and-product-and-why-im-glad-i-didnt/</guid><description>&lt;p>Early in my career, I started out in a product-facing team, working on user-visible features, collaborating with design, thinking about experience and usability. It was rewarding, fast-paced, and full of feedback loops.&lt;/p>
&lt;p>After a while, I knew I wanted to push myself further.&lt;/p>
&lt;p>I didn’t just want to design interfaces. I wanted to understand the systems beneath them. I wanted to write code that was resilient under load, optimize for throughput, and work at scale. I wanted to build the kind of technical judgment that only comes from shipping real infrastructure.&lt;/p></description></item><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>