<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Nguyen Le Phong: Blog</title>
    <link>https://nguyenlephong.github.io/en/blog</link>
    <description>Articles on software architecture, AI and how software teams work.</description>
    <language>en</language>
    <lastBuildDate>Thu, 23 Jul 2026 00:00:00 GMT</lastBuildDate>
    <atom:link href="https://nguyenlephong.github.io/en/blog/feed.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Turning Review Evidence Into Team Memory</title>
      <link>https://nguyenlephong.github.io/en/blog/ways-of-working/turning-review-evidence-into-team-memory</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/ways-of-working/turning-review-evidence-into-team-memory</guid>
      <pubDate>Thu, 23 Jul 2026 00:00:00 GMT</pubDate>
      <description>A practical note on converting review findings, commands, screenshots, and decisions into reusable team memory instead of one-time approval artifacts.</description>
      <category>Ways of Working</category>
      <category>Ways of Working</category>
      <category>Review</category>
      <category>Evidence</category>
      <category>Team Memory</category>
      <category>Documentation</category>
    </item>
    <item>
      <title>What Thirty Days of Small Notes Can Teach</title>
      <link>https://nguyenlephong.github.io/en/blog/perspectives/what-thirty-days-of-small-notes-can-teach</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/perspectives/what-thirty-days-of-small-notes-can-teach</guid>
      <pubDate>Wed, 22 Jul 2026 00:00:00 GMT</pubDate>
      <description>A reflective note on how a month of small daily observations can reveal patterns that are easy to miss in the middle of work.</description>
      <category>Perspectives &amp; Field Notes</category>
      <category>Reflection</category>
      <category>Writing</category>
      <category>Learning</category>
      <category>Daily Notes</category>
      <category>Career</category>
    </item>
    <item>
      <title>System Design Interviews Begin With Clarifying Requirements</title>
      <link>https://nguyenlephong.github.io/en/blog/architecture/clarifying-requirements-in-system-design-interviews</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/architecture/clarifying-requirements-in-system-design-interviews</guid>
      <pubDate>Tue, 21 Jul 2026 00:00:00 GMT</pubDate>
      <description>A practical guide to the first minutes of a System Design Interview: clarify users, scale, core flows, constraints, and trade-offs before choosing tools.</description>
      <category>Source &amp; Architecture</category>
      <category>Software Architecture</category>
      <category>System Design</category>
      <category>Requirements</category>
      <category>Scalability</category>
      <category>Decision Making</category>
    </item>
    <item>
      <title>Letting AI Speed Up the Search, Not the Judgment</title>
      <link>https://nguyenlephong.github.io/en/blog/ai/letting-ai-speed-up-the-search-not-the-judgment</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/ai/letting-ai-speed-up-the-search-not-the-judgment</guid>
      <pubDate>Tue, 21 Jul 2026 00:00:00 GMT</pubDate>
      <description>A practical reflection on using AI to broaden investigation while keeping source checking, trade-off decisions, and accountability with people.</description>
      <category>AI &amp; The Future</category>
      <category>AI</category>
      <category>Search</category>
      <category>Judgment</category>
      <category>Verification</category>
      <category>Evidence</category>
    </item>
    <item>
      <title>Protecting Attention in a Busy Team</title>
      <link>https://nguyenlephong.github.io/en/blog/culture/protecting-attention-in-a-busy-team</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/culture/protecting-attention-in-a-busy-team</guid>
      <pubDate>Mon, 20 Jul 2026 00:00:00 GMT</pubDate>
      <description>A calm note on treating attention as a shared team resource, not an infinite personal budget that people can recover alone.</description>
      <category>Engineering Culture</category>
      <category>Engineering Culture</category>
      <category>Attention</category>
      <category>Focus</category>
      <category>Teamwork</category>
      <category>Meetings</category>
    </item>
    <item>
      <title>Designing Defaults That Fail Safely</title>
      <link>https://nguyenlephong.github.io/en/blog/architecture/designing-defaults-that-fail-safely</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/architecture/designing-defaults-that-fail-safely</guid>
      <pubDate>Sun, 19 Jul 2026 00:00:00 GMT</pubDate>
      <description>A practical reflection on choosing defaults that protect users and systems when configuration, rollout, or external dependency behavior is uncertain.</description>
      <category>Source &amp; Architecture</category>
      <category>Software Architecture</category>
      <category>Defaults</category>
      <category>Reliability</category>
      <category>Failure Modes</category>
      <category>Configuration</category>
    </item>
    <item>
      <title>Making Handoffs Honest About What Is Unknown</title>
      <link>https://nguyenlephong.github.io/en/blog/ways-of-working/making-handoffs-honest-about-what-is-unknown</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/ways-of-working/making-handoffs-honest-about-what-is-unknown</guid>
      <pubDate>Sat, 18 Jul 2026 00:00:00 GMT</pubDate>
      <description>A practical note on writing handoffs that include open questions, assumptions, and risk instead of pretending the work is more certain than it is.</description>
      <category>Ways of Working</category>
      <category>Ways of Working</category>
      <category>Handoffs</category>
      <category>Communication</category>
      <category>Risk</category>
      <category>Delivery</category>
    </item>
    <item>
      <title>The Quiet Discipline of Finishing Properly</title>
      <link>https://nguyenlephong.github.io/en/blog/perspectives/the-quiet-discipline-of-finishing-properly</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/perspectives/the-quiet-discipline-of-finishing-properly</guid>
      <pubDate>Fri, 17 Jul 2026 00:00:00 GMT</pubDate>
      <description>A reflective note on the small discipline of closing work with evidence, cleanup, and context instead of only reaching the visible finish line.</description>
      <category>Perspectives &amp; Field Notes</category>
      <category>Reflection</category>
      <category>Craft</category>
      <category>Follow Through</category>
      <category>Sustainable Work</category>
      <category>Quality</category>
    </item>
    <item>
      <title>Asking AI to Name Its Assumptions</title>
      <link>https://nguyenlephong.github.io/en/blog/ai/asking-ai-to-name-its-assumptions</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/ai/asking-ai-to-name-its-assumptions</guid>
      <pubDate>Thu, 16 Jul 2026 00:00:00 GMT</pubDate>
      <description>A practical reflection on making AI-assisted work safer by asking the model to expose assumptions before accepting its answer.</description>
      <category>AI &amp; The Future</category>
      <category>AI</category>
      <category>LLM</category>
      <category>Prompting</category>
      <category>Verification</category>
      <category>Developer Tools</category>
    </item>
    <item>
      <title>Noticing Friction Before It Becomes Blame</title>
      <link>https://nguyenlephong.github.io/en/blog/culture/noticing-friction-before-it-becomes-blame</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/culture/noticing-friction-before-it-becomes-blame</guid>
      <pubDate>Wed, 15 Jul 2026 00:00:00 GMT</pubDate>
      <description>A calm note on treating repeated team friction as useful signal before it hardens into personal blame.</description>
      <category>Engineering Culture</category>
      <category>Engineering Culture</category>
      <category>Teamwork</category>
      <category>Feedback</category>
      <category>Process</category>
      <category>Leadership</category>
    </item>
    <item>
      <title>Keeping Data Contracts Small Enough to Trust</title>
      <link>https://nguyenlephong.github.io/en/blog/architecture/keeping-data-contracts-small-enough-to-trust</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/architecture/keeping-data-contracts-small-enough-to-trust</guid>
      <pubDate>Tue, 14 Jul 2026 00:00:00 GMT</pubDate>
      <description>A practical reflection on designing data contracts that are narrow, testable, and stable enough for teams to rely on.</description>
      <category>Source &amp; Architecture</category>
      <category>Software Architecture</category>
      <category>Data Contracts</category>
      <category>APIs</category>
      <category>Reliability</category>
      <category>Testing</category>
    </item>
    <item>
      <title>Keeping Checklists Close to the Work</title>
      <link>https://nguyenlephong.github.io/en/blog/ways-of-working/keeping-checklists-close-to-the-work</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/ways-of-working/keeping-checklists-close-to-the-work</guid>
      <pubDate>Mon, 13 Jul 2026 00:00:00 GMT</pubDate>
      <description>A practical note on making checklists useful by placing them where people actually decide, review, release, and hand off work.</description>
      <category>Ways of Working</category>
      <category>Ways of Working</category>
      <category>Checklists</category>
      <category>Delivery</category>
      <category>Quality</category>
      <category>Teamwork</category>
    </item>
    <item>
      <title>The Small Relief of a Reversible Decision</title>
      <link>https://nguyenlephong.github.io/en/blog/perspectives/the-small-relief-of-a-reversible-decision</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/perspectives/the-small-relief-of-a-reversible-decision</guid>
      <pubDate>Sun, 12 Jul 2026 00:00:00 GMT</pubDate>
      <description>A reflective note on lowering decision stress by knowing which choices can be changed safely after new information arrives.</description>
      <category>Perspectives &amp; Field Notes</category>
      <category>Reflection</category>
      <category>Decision Making</category>
      <category>Uncertainty</category>
      <category>Leadership</category>
      <category>Product Engineering</category>
    </item>
    <item>
      <title>Treating AI Suggestions as Draft Evidence</title>
      <link>https://nguyenlephong.github.io/en/blog/ai/treating-ai-suggestions-as-draft-evidence</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/ai/treating-ai-suggestions-as-draft-evidence</guid>
      <pubDate>Sat, 11 Jul 2026 00:00:00 GMT</pubDate>
      <description>A practical reflection on using AI output as a starting point for investigation, not as a finished answer that replaces verification.</description>
      <category>AI &amp; The Future</category>
      <category>AI</category>
      <category>LLM</category>
      <category>Evidence</category>
      <category>Code Review</category>
      <category>Developer Tools</category>
    </item>
    <item>
      <title>Making Space for the Quiet Reviewer</title>
      <link>https://nguyenlephong.github.io/en/blog/culture/making-space-for-the-quiet-reviewer</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/culture/making-space-for-the-quiet-reviewer</guid>
      <pubDate>Fri, 10 Jul 2026 00:00:00 GMT</pubDate>
      <description>A calm note on helping quieter teammates contribute thoughtful review feedback without forcing every useful signal into the loudest channel.</description>
      <category>Engineering Culture</category>
      <category>Engineering Culture</category>
      <category>Code Review</category>
      <category>Inclusion</category>
      <category>Teamwork</category>
      <category>Feedback</category>
    </item>
    <item>
      <title>Choosing Boring Boundaries on Purpose</title>
      <link>https://nguyenlephong.github.io/en/blog/architecture/choosing-boring-boundaries-on-purpose</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/architecture/choosing-boring-boundaries-on-purpose</guid>
      <pubDate>Thu, 09 Jul 2026 00:00:00 GMT</pubDate>
      <description>A practical reflection on choosing simple software boundaries that make ownership, testing, and future change easier to reason about.</description>
      <category>Source &amp; Architecture</category>
      <category>Software Architecture</category>
      <category>Boundaries</category>
      <category>Modularity</category>
      <category>Maintenance</category>
      <category>Product Engineering</category>
    </item>
    <item>
      <title>Writing Status Updates People Can Act On</title>
      <link>https://nguyenlephong.github.io/en/blog/ways-of-working/writing-status-updates-people-can-act-on</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/ways-of-working/writing-status-updates-people-can-act-on</guid>
      <pubDate>Wed, 08 Jul 2026 00:00:00 GMT</pubDate>
      <description>A practical note on writing status updates that tell readers what changed, what is blocked, and what action is needed next.</description>
      <category>Ways of Working</category>
      <category>Ways of Working</category>
      <category>Communication</category>
      <category>Status Updates</category>
      <category>Delivery</category>
      <category>Planning</category>
    </item>
    <item>
      <title>The Patience to Let Context Arrive</title>
      <link>https://nguyenlephong.github.io/en/blog/perspectives/the-patience-to-let-context-arrive</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/perspectives/the-patience-to-let-context-arrive</guid>
      <pubDate>Tue, 07 Jul 2026 00:00:00 GMT</pubDate>
      <description>A reflective note on waiting long enough for missing context to surface before turning uncertainty into a decision.</description>
      <category>Perspectives &amp; Field Notes</category>
      <category>Reflection</category>
      <category>Decision Making</category>
      <category>Context</category>
      <category>Patience</category>
      <category>Leadership</category>
    </item>
    <item>
      <title>Keeping AI Changes Small Enough to Review</title>
      <link>https://nguyenlephong.github.io/en/blog/ai/keeping-ai-changes-small-enough-to-review</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/ai/keeping-ai-changes-small-enough-to-review</guid>
      <pubDate>Mon, 06 Jul 2026 00:00:00 GMT</pubDate>
      <description>A practical reflection on using AI safely by keeping generated changes narrow, inspectable, and tied to evidence.</description>
      <category>AI &amp; The Future</category>
      <category>AI</category>
      <category>Code Review</category>
      <category>LLM</category>
      <category>Developer Tools</category>
      <category>Software Engineering</category>
    </item>
    <item>
      <title>What Calm Ownership Looks Like in Practice</title>
      <link>https://nguyenlephong.github.io/en/blog/culture/what-calm-ownership-looks-like-in-practice</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/culture/what-calm-ownership-looks-like-in-practice</guid>
      <pubDate>Sun, 05 Jul 2026 00:00:00 GMT</pubDate>
      <description>A grounded note on ownership as clear follow-through, explicit handoffs, and steady accountability without drama.</description>
      <category>Engineering Culture</category>
      <category>Engineering Culture</category>
      <category>Ownership</category>
      <category>Leadership</category>
      <category>Teamwork</category>
      <category>Delivery</category>
    </item>
    <item>
      <title>Designing With Escape Hatches, Not Back Doors</title>
      <link>https://nguyenlephong.github.io/en/blog/architecture/designing-with-escape-hatches-not-back-doors</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/architecture/designing-with-escape-hatches-not-back-doors</guid>
      <pubDate>Sat, 04 Jul 2026 00:00:00 GMT</pubDate>
      <description>A practical reflection on building safe operational escape hatches that are explicit, audited, and bounded instead of hidden back doors.</description>
      <category>Source &amp; Architecture</category>
      <category>Software Architecture</category>
      <category>Operations</category>
      <category>Security</category>
      <category>Reliability</category>
      <category>Governance</category>
    </item>
    <item>
      <title>Closing the Loop Before Starting the Next One</title>
      <link>https://nguyenlephong.github.io/en/blog/ways-of-working/closing-the-loop-before-starting-the-next-one</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/ways-of-working/closing-the-loop-before-starting-the-next-one</guid>
      <pubDate>Fri, 03 Jul 2026 00:00:00 GMT</pubDate>
      <description>A practical note on closing work loops with evidence, decisions, and handoff context before the team rushes into the next task.</description>
      <category>Ways of Working</category>
      <category>Ways of Working</category>
      <category>Delivery</category>
      <category>Review</category>
      <category>Documentation</category>
      <category>Team Communication</category>
    </item>
    <item>
      <title>When Progress Feels Like Removing Weight</title>
      <link>https://nguyenlephong.github.io/en/blog/perspectives/when-progress-feels-like-removing-weight</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/perspectives/when-progress-feels-like-removing-weight</guid>
      <pubDate>Thu, 02 Jul 2026 00:00:00 GMT</pubDate>
      <description>A reflective note on the kind of progress that comes from reducing load, clearing ambiguity, and making the next step lighter.</description>
      <category>Perspectives &amp; Field Notes</category>
      <category>Reflection</category>
      <category>Clarity</category>
      <category>Workload</category>
      <category>Focus</category>
      <category>Sustainable Work</category>
    </item>
    <item>
      <title>Letting AI Draft the Boring First Pass</title>
      <link>https://nguyenlephong.github.io/en/blog/ai/letting-ai-draft-the-boring-first-pass</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/ai/letting-ai-draft-the-boring-first-pass</guid>
      <pubDate>Wed, 01 Jul 2026 00:00:00 GMT</pubDate>
      <description>A practical reflection on using AI for the plain first draft, while keeping human judgment focused on evidence, shape, and responsibility.</description>
      <category>AI &amp; The Future</category>
      <category>AI</category>
      <category>LLM</category>
      <category>Writing</category>
      <category>Developer Tools</category>
      <category>Review</category>
    </item>
    <item>
      <title>The Quiet Skill of Asking for Help Early</title>
      <link>https://nguyenlephong.github.io/en/blog/culture/the-quiet-skill-of-asking-for-help-early</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/culture/the-quiet-skill-of-asking-for-help-early</guid>
      <pubDate>Tue, 30 Jun 2026 00:00:00 GMT</pubDate>
      <description>A calm note on why asking for help early is not weakness, but one of the small habits that keeps work honest and teams healthy.</description>
      <category>Engineering Culture</category>
      <category>Engineering Culture</category>
      <category>Teamwork</category>
      <category>Communication</category>
      <category>Psychological Safety</category>
      <category>Delivery</category>
    </item>
    <item>
      <title>Making Interfaces Honest About System Limits</title>
      <link>https://nguyenlephong.github.io/en/blog/architecture/making-interfaces-honest-about-system-limits</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/architecture/making-interfaces-honest-about-system-limits</guid>
      <pubDate>Mon, 29 Jun 2026 00:00:00 GMT</pubDate>
      <description>A practical reflection on designing interfaces that show real system limits before users and operators have to discover them through failure.</description>
      <category>Source &amp; Architecture</category>
      <category>Software Architecture</category>
      <category>Product Design</category>
      <category>Reliability</category>
      <category>Operational UX</category>
      <category>Systems Thinking</category>
    </item>
    <item>
      <title>Keeping Meeting Notes Close to Decisions</title>
      <link>https://nguyenlephong.github.io/en/blog/ways-of-working/keeping-meeting-notes-close-to-decisions</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/ways-of-working/keeping-meeting-notes-close-to-decisions</guid>
      <pubDate>Sun, 28 Jun 2026 00:00:00 GMT</pubDate>
      <description>A practical note on keeping meeting notes close to decisions so future teammates can find context, trade-offs, and follow-through without replaying the meeting.</description>
      <category>Ways of Working</category>
      <category>Ways of Working</category>
      <category>Documentation</category>
      <category>Decision Making</category>
      <category>Team Communication</category>
      <category>Planning</category>
    </item>
    <item>
      <title>The Relief of a Well-Named Problem</title>
      <link>https://nguyenlephong.github.io/en/blog/perspectives/the-relief-of-a-well-named-problem</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/perspectives/the-relief-of-a-well-named-problem</guid>
      <pubDate>Sat, 27 Jun 2026 00:00:00 GMT</pubDate>
      <description>A reflective note on how a well-named problem reduces tension by turning scattered discomfort into something people can examine together.</description>
      <category>Perspectives &amp; Field Notes</category>
      <category>Reflection</category>
      <category>Clarity</category>
      <category>Communication</category>
      <category>Decision Making</category>
      <category>Learning</category>
    </item>
    <item>
      <title>Asking AI to Show Its Working Context</title>
      <link>https://nguyenlephong.github.io/en/blog/ai/asking-ai-to-show-its-working-context</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/ai/asking-ai-to-show-its-working-context</guid>
      <pubDate>Fri, 26 Jun 2026 00:00:00 GMT</pubDate>
      <description>A practical reflection on asking AI systems to expose their working context so engineers can verify evidence, assumptions, and gaps.</description>
      <category>AI &amp; The Future</category>
      <category>AI</category>
      <category>LLM</category>
      <category>Context Engineering</category>
      <category>Verification</category>
      <category>Developer Tools</category>
    </item>
    <item>
      <title>Why Good Teams Make Risk Visible Early</title>
      <link>https://nguyenlephong.github.io/en/blog/culture/why-good-teams-make-risk-visible-early</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/culture/why-good-teams-make-risk-visible-early</guid>
      <pubDate>Thu, 25 Jun 2026 00:00:00 GMT</pubDate>
      <description>A calm note on why healthy teams surface risk early: not to create fear, but to give the work more room to adjust.</description>
      <category>Engineering Culture</category>
      <category>Engineering Culture</category>
      <category>Risk</category>
      <category>Team Communication</category>
      <category>Trust</category>
      <category>Delivery</category>
    </item>
    <item>
      <title>Designing for the Change You Can Actually See</title>
      <link>https://nguyenlephong.github.io/en/blog/architecture/designing-for-the-change-you-can-actually-see</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/architecture/designing-for-the-change-you-can-actually-see</guid>
      <pubDate>Wed, 24 Jun 2026 00:00:00 GMT</pubDate>
      <description>A practical reflection on designing software around visible change patterns instead of abstract future flexibility that may never arrive.</description>
      <category>Source &amp; Architecture</category>
      <category>Software Architecture</category>
      <category>Change Management</category>
      <category>Technical Debt</category>
      <category>Design</category>
      <category>Product Engineering</category>
    </item>
    <item>
      <title>Writing Next Steps That Actually Help</title>
      <link>https://nguyenlephong.github.io/en/blog/ways-of-working/writing-next-steps-that-actually-help</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/ways-of-working/writing-next-steps-that-actually-help</guid>
      <pubDate>Tue, 23 Jun 2026 00:00:00 GMT</pubDate>
      <description>A practical note on writing next steps that are specific enough to move work forward: owner, action, evidence, and a useful stopping point.</description>
      <category>Ways of Working</category>
      <category>Ways of Working</category>
      <category>Planning</category>
      <category>Team Communication</category>
      <category>Execution</category>
      <category>Documentation</category>
    </item>
    <item>
      <title>A Calm Way to Carry Uncertainty</title>
      <link>https://nguyenlephong.github.io/en/blog/perspectives/a-calm-way-to-carry-uncertainty</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/perspectives/a-calm-way-to-carry-uncertainty</guid>
      <pubDate>Mon, 22 Jun 2026 00:00:00 GMT</pubDate>
      <description>A reflective note on carrying uncertainty without letting it become avoidance: name it, bound it, assign it, and keep moving with care.</description>
      <category>Perspectives &amp; Field Notes</category>
      <category>Reflection</category>
      <category>Decision Making</category>
      <category>Uncertainty</category>
      <category>Communication</category>
      <category>Learning</category>
    </item>
    <item>
      <title>Letting AI Draft While Humans Keep the Map</title>
      <link>https://nguyenlephong.github.io/en/blog/ai/letting-ai-draft-while-humans-keep-the-map</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/ai/letting-ai-draft-while-humans-keep-the-map</guid>
      <pubDate>Sun, 21 Jun 2026 00:00:00 GMT</pubDate>
      <description>A practical reflection on using AI to draft faster while humans keep the system map: constraints, sources, ownership, and verification paths.</description>
      <category>AI &amp; The Future</category>
      <category>AI</category>
      <category>LLM</category>
      <category>Engineering Judgment</category>
      <category>Context Engineering</category>
      <category>Developer Tools</category>
    </item>
    <item>
      <title>The Culture Hidden in Small Reviews</title>
      <link>https://nguyenlephong.github.io/en/blog/culture/the-culture-hidden-in-small-reviews</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/culture/the-culture-hidden-in-small-reviews</guid>
      <pubDate>Sat, 20 Jun 2026 00:00:00 GMT</pubDate>
      <description>A calm note on how engineering culture shows up in small reviews: the phrasing, patience, and care teams bring to ordinary feedback.</description>
      <category>Engineering Culture</category>
      <category>Engineering Culture</category>
      <category>Code Review</category>
      <category>Feedback</category>
      <category>Team Trust</category>
      <category>Communication</category>
    </item>
    <item>
      <title>When Boundaries Need Examples More Than Names</title>
      <link>https://nguyenlephong.github.io/en/blog/architecture/when-boundaries-need-examples-more-than-names</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/architecture/when-boundaries-need-examples-more-than-names</guid>
      <pubDate>Fri, 19 Jun 2026 00:00:00 GMT</pubDate>
      <description>A practical reflection on why software boundaries become clearer when teams anchor them in examples, responsibilities, and behavior instead of only naming layers.</description>
      <category>Source &amp; Architecture</category>
      <category>Software Architecture</category>
      <category>Boundaries</category>
      <category>Examples</category>
      <category>Module Design</category>
      <category>Team Communication</category>
    </item>
    <item>
      <title>Making Handoffs Easier to Receive</title>
      <link>https://nguyenlephong.github.io/en/blog/ways-of-working/making-handoffs-easier-to-receive</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/ways-of-working/making-handoffs-easier-to-receive</guid>
      <pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
      <description>A practical note on making handoffs easier to receive by carrying context, decisions, risks, and the next useful action instead of only transferring files.</description>
      <category>Ways of Working</category>
      <category>Ways of Working</category>
      <category>Product Engineering</category>
      <category>Documentation</category>
      <category>Team Communication</category>
      <category>Ownership</category>
    </item>
    <item>
      <title>The Quiet Cost of Staying Vague</title>
      <link>https://nguyenlephong.github.io/en/blog/perspectives/the-quiet-cost-of-staying-vague</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/perspectives/the-quiet-cost-of-staying-vague</guid>
      <pubDate>Wed, 17 Jun 2026 00:00:00 GMT</pubDate>
      <description>A reflective note on the quiet cost of staying vague: how unclear words create rework, hidden stress, and decisions nobody feels able to inspect.</description>
      <category>Perspectives &amp; Field Notes</category>
      <category>Reflection</category>
      <category>Communication</category>
      <category>Decision Making</category>
      <category>Clarity</category>
      <category>Teamwork</category>
    </item>
    <item>
      <title>What AI Cannot Know From the Prompt Alone</title>
      <link>https://nguyenlephong.github.io/en/blog/ai/what-ai-cannot-know-from-the-prompt-alone</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/ai/what-ai-cannot-know-from-the-prompt-alone</guid>
      <pubDate>Tue, 16 Jun 2026 00:00:00 GMT</pubDate>
      <description>A practical reflection on why prompts are not enough: AI needs source context, runtime evidence, domain constraints, and human judgment to become useful engineering help.</description>
      <category>AI &amp; The Future</category>
      <category>AI</category>
      <category>LLM</category>
      <category>Developer Tools</category>
      <category>Engineering Judgment</category>
      <category>Code Review</category>
    </item>
    <item>
      <title>How Trust Grows in Ordinary Follow-Through</title>
      <link>https://nguyenlephong.github.io/en/blog/culture/how-trust-grows-in-ordinary-follow-through</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/culture/how-trust-grows-in-ordinary-follow-through</guid>
      <pubDate>Mon, 15 Jun 2026 00:00:00 GMT</pubDate>
      <description>A calm note on how engineering trust grows through ordinary follow-through: small promises kept, visible updates, and repairs when reality changes.</description>
      <category>Engineering Culture</category>
      <category>Engineering Culture</category>
      <category>Trust</category>
      <category>Team Communication</category>
      <category>Reliability</category>
      <category>Leadership</category>
    </item>
    <item>
      <title>Keeping Architecture Decisions Small Enough to Revisit</title>
      <link>https://nguyenlephong.github.io/en/blog/architecture/keeping-architecture-decisions-small-enough-to-revisit</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/architecture/keeping-architecture-decisions-small-enough-to-revisit</guid>
      <pubDate>Sun, 14 Jun 2026 00:00:00 GMT</pubDate>
      <description>A practical reflection on making architecture decisions small, explicit, and revisitable so teams can learn without turning every choice into a permanent monument.</description>
      <category>Source &amp; Architecture</category>
      <category>Software Architecture</category>
      <category>Decision Making</category>
      <category>Technical Debt</category>
      <category>Team Communication</category>
      <category>Design Notes</category>
    </item>
    <item>
      <title>Turning Unclear Work Into Shared Notes</title>
      <link>https://nguyenlephong.github.io/en/blog/ways-of-working/turning-unclear-work-into-shared-notes</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/ways-of-working/turning-unclear-work-into-shared-notes</guid>
      <pubDate>Sat, 13 Jun 2026 00:00:00 GMT</pubDate>
      <description>A practical note on using shared notes to turn vague requests into visible context, decisions, examples, and next steps.</description>
      <category>Ways of Working</category>
      <category>Ways of Working</category>
      <category>Product Engineering</category>
      <category>Planning</category>
      <category>Documentation</category>
      <category>Team Communication</category>
    </item>
    <item>
      <title>The Value of a Slower First Answer</title>
      <link>https://nguyenlephong.github.io/en/blog/perspectives/the-value-of-a-slower-first-answer</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/perspectives/the-value-of-a-slower-first-answer</guid>
      <pubDate>Fri, 12 Jun 2026 00:00:00 GMT</pubDate>
      <description>A reflective note on slowing down the first answer just enough to understand context, reduce rework, and respond with more care.</description>
      <category>Perspectives &amp; Field Notes</category>
      <category>Reflection</category>
      <category>Decision Making</category>
      <category>Communication</category>
      <category>Career Growth</category>
      <category>Learning</category>
    </item>
    <item>
      <title>Using AI Without Outsourcing Judgment</title>
      <link>https://nguyenlephong.github.io/en/blog/ai/using-ai-without-outsourcing-judgment</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/ai/using-ai-without-outsourcing-judgment</guid>
      <pubDate>Thu, 11 Jun 2026 00:00:00 GMT</pubDate>
      <description>A practical reflection on using AI as a thinking partner while keeping human judgment anchored in source code, tests, logs, and product context.</description>
      <category>AI &amp; The Future</category>
      <category>AI</category>
      <category>LLM</category>
      <category>Developer Tools</category>
      <category>Engineering Judgment</category>
      <category>Code Review</category>
    </item>
    <item>
      <title>The Quiet Discipline of Saying Not Yet</title>
      <link>https://nguyenlephong.github.io/en/blog/culture/the-quiet-discipline-of-saying-not-yet</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/culture/the-quiet-discipline-of-saying-not-yet</guid>
      <pubDate>Wed, 10 Jun 2026 00:00:00 GMT</pubDate>
      <description>A calm note on why healthy engineering teams sometimes say not yet: to protect quality, trust, and the people who will operate the release later.</description>
      <category>Engineering Culture</category>
      <category>Engineering Culture</category>
      <category>Quality</category>
      <category>Release Management</category>
      <category>Team Trust</category>
      <category>Code Review</category>
    </item>
    <item>
      <title>Designing Interfaces That Outlive Implementations</title>
      <link>https://nguyenlephong.github.io/en/blog/architecture/designing-interfaces-that-outlive-implementations</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/architecture/designing-interfaces-that-outlive-implementations</guid>
      <pubDate>Tue, 09 Jun 2026 00:00:00 GMT</pubDate>
      <description>A practical reflection on designing software interfaces that keep product behavior stable while implementations change underneath.</description>
      <category>Source &amp; Architecture</category>
      <category>Software Architecture</category>
      <category>Interfaces</category>
      <category>Module Boundaries</category>
      <category>Technical Debt</category>
      <category>API Design</category>
    </item>
    <item>
      <title>The Calm Way to Handle Scope Changes</title>
      <link>https://nguyenlephong.github.io/en/blog/ways-of-working/the-calm-way-to-handle-scope-changes</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/ways-of-working/the-calm-way-to-handle-scope-changes</guid>
      <pubDate>Mon, 08 Jun 2026 00:00:00 GMT</pubDate>
      <description>A practical note on scope changes: how teams can discuss new work calmly by making trade-offs visible, protecting focus, and changing plans without blame.</description>
      <category>Ways of Working</category>
      <category>Ways of Working</category>
      <category>Scope Management</category>
      <category>Product Engineering</category>
      <category>Planning</category>
      <category>Prioritization</category>
    </item>
    <item>
      <title>Why Quiet Consistency Compounds</title>
      <link>https://nguyenlephong.github.io/en/blog/perspectives/why-quiet-consistency-compounds</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/perspectives/why-quiet-consistency-compounds</guid>
      <pubDate>Sun, 07 Jun 2026 00:00:00 GMT</pubDate>
      <description>A calm reflection on quiet consistency: why small repeated returns to a craft, relationship, codebase, or habit often become visible long after the effort begins.</description>
      <category>Perspectives &amp; Field Notes</category>
      <category>Reflection</category>
      <category>Consistency</category>
      <category>Learning</category>
      <category>Career Growth</category>
      <category>Personal Growth</category>
    </item>
    <item>
      <title>AI Tools for Reading a Codebase</title>
      <link>https://nguyenlephong.github.io/en/blog/ai/ai-tools-for-reading-a-codebase</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/ai/ai-tools-for-reading-a-codebase</guid>
      <pubDate>Sat, 06 Jun 2026 00:00:00 GMT</pubDate>
      <description>A practical guide to using AI tools while reading a codebase: where summaries help, where they mislead, and how engineers can combine AI assistance with source-level verification.</description>
      <category>AI &amp; The Future</category>
      <category>AI</category>
      <category>Codebase</category>
      <category>LLM</category>
      <category>Developer Tools</category>
      <category>Code Reading</category>
    </item>
    <item>
      <title>The Reviewer as a Future Reader</title>
      <link>https://nguyenlephong.github.io/en/blog/culture/the-reviewer-as-a-future-reader</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/culture/the-reviewer-as-a-future-reader</guid>
      <pubDate>Fri, 05 Jun 2026 00:00:00 GMT</pubDate>
      <description>A reflective note on code review culture: how treating the reviewer as a future reader can make pull requests clearer, kinder, and more useful for the people who will maintain the change later.</description>
      <category>Engineering Culture</category>
      <category>Engineering Culture</category>
      <category>Code Review</category>
      <category>Pull Requests</category>
      <category>Communication</category>
      <category>Maintainability</category>
    </item>
    <item>
      <title>Refactoring Toward a Clearer Core</title>
      <link>https://nguyenlephong.github.io/en/blog/architecture/refactoring-toward-a-clearer-core</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/architecture/refactoring-toward-a-clearer-core</guid>
      <pubDate>Thu, 04 Jun 2026 00:00:00 GMT</pubDate>
      <description>A practical reflection on refactoring toward a clearer core: how teams can reduce coupling, protect behavior, and make the center of a codebase easier for future teammates to understand.</description>
      <category>Source &amp; Architecture</category>
      <category>Software Architecture</category>
      <category>Refactoring</category>
      <category>Codebase</category>
      <category>Technical Debt</category>
      <category>Module Boundaries</category>
    </item>
    <item>
      <title>Managing Dependencies Without Blame</title>
      <link>https://nguyenlephong.github.io/en/blog/ways-of-working/managing-dependencies-without-blame</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/ways-of-working/managing-dependencies-without-blame</guid>
      <pubDate>Wed, 03 Jun 2026 00:00:00 GMT</pubDate>
      <description>A practical note on delivery dependencies: how teams can make blockers visible early, coordinate calmly, and avoid turning normal coupling into personal blame.</description>
      <category>Ways of Working</category>
      <category>Ways of Working</category>
      <category>Software Delivery</category>
      <category>Dependencies</category>
      <category>Planning</category>
      <category>Cross-functional Teams</category>
    </item>
    <item>
      <title>The Difference Between Confidence and Evidence</title>
      <link>https://nguyenlephong.github.io/en/blog/perspectives/difference-between-confidence-and-evidence</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/perspectives/difference-between-confidence-and-evidence</guid>
      <pubDate>Tue, 02 Jun 2026 00:00:00 GMT</pubDate>
      <description>A reflective field note on why confidence becomes useful only when it is tied to evidence, and how teams can keep conviction without losing humility.</description>
      <category>Perspectives &amp; Field Notes</category>
      <category>Reflection</category>
      <category>Decision Making</category>
      <category>Engineering Judgment</category>
      <category>Evidence</category>
      <category>Career Growth</category>
    </item>
    <item>
      <title>From Prototype Demo to Production Behavior</title>
      <link>https://nguyenlephong.github.io/en/blog/ai/from-prototype-demo-to-production-behavior</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/ai/from-prototype-demo-to-production-behavior</guid>
      <pubDate>Mon, 01 Jun 2026 00:00:00 GMT</pubDate>
      <description>A grounded AI product note on the gap between an impressive prototype demo and the production behavior users can safely depend on.</description>
      <category>AI &amp; The Future</category>
      <category>AI</category>
      <category>AI Products</category>
      <category>Production Readiness</category>
      <category>LLM</category>
      <category>Evaluation</category>
    </item>
    <item>
      <title>When Silence in a Team Becomes a Signal</title>
      <link>https://nguyenlephong.github.io/en/blog/culture/when-silence-in-a-team-becomes-a-signal</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/culture/when-silence-in-a-team-becomes-a-signal</guid>
      <pubDate>Sun, 31 May 2026 00:00:00 GMT</pubDate>
      <description>A calm look at team silence: how quiet rooms, missing replies, and low participation can reveal unclear ownership, unsafe disagreement, fatigue, or hidden context.</description>
      <category>Engineering Culture</category>
      <category>Engineering Culture</category>
      <category>Team Communication</category>
      <category>Psychological Safety</category>
      <category>Leadership</category>
      <category>Feedback</category>
    </item>
    <item>
      <title>Architecture Decisions for Future Teammates</title>
      <link>https://nguyenlephong.github.io/en/blog/architecture/architecture-decisions-for-future-teammates</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/architecture/architecture-decisions-for-future-teammates</guid>
      <pubDate>Sat, 30 May 2026 00:00:00 GMT</pubDate>
      <description>A practical reflection on architecture decisions as team memory: how small ADR-style notes help future teammates understand trade-offs, rejected paths, and when to revisit a choice.</description>
      <category>Source &amp; Architecture</category>
      <category>Software Architecture</category>
      <category>Architecture Decisions</category>
      <category>Team Memory</category>
      <category>ADRs</category>
      <category>Technical Leadership</category>
    </item>
    <item>
      <title>Decision Logs for Busy Teams</title>
      <link>https://nguyenlephong.github.io/en/blog/ways-of-working/decision-logs-for-busy-teams</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/ways-of-working/decision-logs-for-busy-teams</guid>
      <pubDate>Fri, 29 May 2026 00:00:00 GMT</pubDate>
      <description>A practical reflection on decision logs: how small written records help busy teams remember trade-offs, reduce repeated debates, and keep delivery aligned without adding heavy process.</description>
      <category>Ways of Working</category>
      <category>Ways of Working</category>
      <category>Decision Logs</category>
      <category>Software Delivery</category>
      <category>Team Communication</category>
      <category>Architecture Decisions</category>
    </item>
    <item>
      <title>The Note You Return to Later</title>
      <link>https://nguyenlephong.github.io/en/blog/perspectives/the-note-you-return-to-later</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/perspectives/the-note-you-return-to-later</guid>
      <pubDate>Thu, 28 May 2026 00:00:00 GMT</pubDate>
      <description>A reflective field note on why small unfinished notes matter: how returning to an old thought can reveal growth, clarify decisions, and make quiet learning visible.</description>
      <category>Perspectives &amp; Field Notes</category>
      <category>Reflection</category>
      <category>Writing</category>
      <category>Learning</category>
      <category>Career Growth</category>
      <category>Notes</category>
    </item>
    <item>
      <title>Human Feedback Loops for AI Work</title>
      <link>https://nguyenlephong.github.io/en/blog/ai/human-feedback-loops-for-ai-work</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/ai/human-feedback-loops-for-ai-work</guid>
      <pubDate>Wed, 27 May 2026 00:00:00 GMT</pubDate>
      <description>A grounded look at AI work habits: why useful AI workflows need human feedback loops, evidence checks, test results, and team memory instead of one-off prompt outputs.</description>
      <category>AI &amp; The Future</category>
      <category>AI</category>
      <category>LLM</category>
      <category>AI Workflow</category>
      <category>Human Feedback</category>
      <category>Verification</category>
    </item>
    <item>
      <title>The Quiet Skill of Asking for Help</title>
      <link>https://nguyenlephong.github.io/en/blog/culture/quiet-skill-of-asking-for-help</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/culture/quiet-skill-of-asking-for-help</guid>
      <pubDate>Tue, 26 May 2026 00:00:00 GMT</pubDate>
      <description>A calm look at asking for help in engineering teams: how to make context visible, protect dignity, and turn stuck moments into shared learning instead of silent pressure.</description>
      <category>Engineering Culture</category>
      <category>Engineering Culture</category>
      <category>Team Trust</category>
      <category>Communication</category>
      <category>Mentorship</category>
      <category>Learning</category>
    </item>
    <item>
      <title>Choosing Boundaries Before Choosing Tools</title>
      <link>https://nguyenlephong.github.io/en/blog/architecture/choosing-boundaries-before-choosing-tools</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/architecture/choosing-boundaries-before-choosing-tools</guid>
      <pubDate>Mon, 25 May 2026 00:00:00 GMT</pubDate>
      <description>A practical reflection on architecture boundaries: why teams should name ownership, data, and change patterns before reaching for frameworks, services, queues, or databases.</description>
      <category>Source &amp; Architecture</category>
      <category>Software Architecture</category>
      <category>System Design</category>
      <category>Bounded Context</category>
      <category>Architecture Decisions</category>
      <category>Technical Leadership</category>
    </item>
    <item>
      <title>When the Roadmap Meets Real Capacity</title>
      <link>https://nguyenlephong.github.io/en/blog/ways-of-working/roadmap-meets-real-capacity</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/ways-of-working/roadmap-meets-real-capacity</guid>
      <pubDate>Sun, 24 May 2026 00:00:00 GMT</pubDate>
      <description>A practical reflection on the moment a roadmap meets real team capacity: how to make trade-offs visible, protect focus, and adjust plans without turning planning into blame.</description>
      <category>Ways of Working</category>
      <category>Roadmap Planning</category>
      <category>Capacity Planning</category>
      <category>Ways of Working</category>
      <category>Software Delivery</category>
      <category>Prioritization</category>
    </item>
    <item>
      <title>The Courage to Write the First Rough Note</title>
      <link>https://nguyenlephong.github.io/en/blog/perspectives/courage-to-write-the-first-rough-note</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/perspectives/courage-to-write-the-first-rough-note</guid>
      <pubDate>Sat, 23 May 2026 00:00:00 GMT</pubDate>
      <description>A calm reflection on why the first rough note matters: how messy writing makes thinking visible, lowers the pressure to sound finished, and helps quiet ideas become useful.</description>
      <category>Perspectives &amp; Field Notes</category>
      <category>Writing</category>
      <category>Reflection</category>
      <category>Learning</category>
      <category>Career Growth</category>
      <category>Thinking</category>
    </item>
    <item>
      <title>The Cost of Trusting a Fluent AI Answer</title>
      <link>https://nguyenlephong.github.io/en/blog/ai/cost-of-trusting-a-fluent-ai-answer</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/ai/cost-of-trusting-a-fluent-ai-answer</guid>
      <pubDate>Fri, 22 May 2026 00:00:00 GMT</pubDate>
      <description>A grounded look at fluent AI answers: why confident language can feel like evidence, where that creates risk, and how teams can keep AI useful by checking claims against sources, tests, and real context.</description>
      <category>AI &amp; The Future</category>
      <category>AI</category>
      <category>LLM</category>
      <category>AI Workflow</category>
      <category>Verification</category>
      <category>Engineering Judgment</category>
    </item>
    <item>
      <title>A Calm Script for Difficult Feedback</title>
      <link>https://nguyenlephong.github.io/en/blog/culture/calm-script-for-difficult-feedback</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/culture/calm-script-for-difficult-feedback</guid>
      <pubDate>Thu, 21 May 2026 00:00:00 GMT</pubDate>
      <description>A practical guide to difficult feedback in engineering teams: how to prepare the facts, keep dignity in the room, name behavior clearly, and turn a tense conversation into a fair next step.</description>
      <category>Engineering Culture</category>
      <category>Engineering Culture</category>
      <category>Feedback</category>
      <category>Communication</category>
      <category>Leadership</category>
      <category>Team Trust</category>
    </item>
    <item>
      <title>Observability as a Design Choice</title>
      <link>https://nguyenlephong.github.io/en/blog/architecture/observability-as-a-design-choice</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/architecture/observability-as-a-design-choice</guid>
      <pubDate>Wed, 20 May 2026 00:00:00 GMT</pubDate>
      <description>A practical explanation of observability as an architecture decision: why teams should design logs, metrics, traces, dashboards, and alerts into the system before production asks hard questions.</description>
      <category>Source &amp; Architecture</category>
      <category>Software Architecture</category>
      <category>Observability</category>
      <category>System Design</category>
      <category>Production Readiness</category>
      <category>Reliability</category>
    </item>
    <item>
      <title>Cross-Functional Teams</title>
      <link>https://nguyenlephong.github.io/en/blog/ways-of-working/cross-functional-teams</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/ways-of-working/cross-functional-teams</guid>
      <pubDate>Tue, 19 May 2026 00:00:00 GMT</pubDate>
      <description>A practical look at cross-functional teams: why they exist, how shared outcomes reduce handoff friction, and what teams need around ownership, rituals, decision-making, specialist depth, and healthy disagreement.</description>
      <category>Ways of Working</category>
      <category>Cross-Functional Teams</category>
      <category>Ways of Working</category>
      <category>Product Engineering</category>
      <category>Team Collaboration</category>
      <category>Software Delivery</category>
    </item>
    <item>
      <title>The Loneliness of the Solo Developer</title>
      <link>https://nguyenlephong.github.io/en/blog/perspectives/loneliness-of-the-solo-developer</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/perspectives/loneliness-of-the-solo-developer</guid>
      <pubDate>Mon, 18 May 2026 00:00:00 GMT</pubDate>
      <description>A reflective essay on solo development: the freedom and pressure of working alone, the missing feedback loops, and the small systems that make solo work more sustainable and less isolating.</description>
      <category>Perspectives &amp; Field Notes</category>
      <category>Solo Developer</category>
      <category>Reflection</category>
      <category>Software Engineering</category>
      <category>Career Growth</category>
      <category>Sustainable Work</category>
    </item>
    <item>
      <title>Vector Databases Explained</title>
      <link>https://nguyenlephong.github.io/en/blog/ai/vector-databases-explained</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/ai/vector-databases-explained</guid>
      <pubDate>Sun, 17 May 2026 00:00:00 GMT</pubDate>
      <description>A beginner-friendly explanation of vector databases: how embeddings represent meaning, why similarity search helps AI products, and what teams need to handle around chunking, metadata, freshness, evaluation, and cost.</description>
      <category>AI &amp; The Future</category>
      <category>AI</category>
      <category>Vector Database</category>
      <category>Embeddings</category>
      <category>Semantic Search</category>
      <category>RAG</category>
    </item>
    <item>
      <title>Fostering Innovation in Teams</title>
      <link>https://nguyenlephong.github.io/en/blog/culture/fostering-innovation-in-teams</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/culture/fostering-innovation-in-teams</guid>
      <pubDate>Sat, 16 May 2026 00:00:00 GMT</pubDate>
      <description>A grounded reflection on fostering innovation in engineering teams: how psychological safety, slack, user context, small experiments, technical quality, and honest prioritization help ideas become useful change.</description>
      <category>Engineering Culture</category>
      <category>Engineering Culture</category>
      <category>Innovation</category>
      <category>Team Trust</category>
      <category>Leadership</category>
      <category>Product Engineering</category>
    </item>
    <item>
      <title>The Outbox Pattern</title>
      <link>https://nguyenlephong.github.io/en/blog/architecture/the-outbox-pattern</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/architecture/the-outbox-pattern</guid>
      <pubDate>Fri, 15 May 2026 00:00:00 GMT</pubDate>
      <description>A practical explanation of the Outbox Pattern: why dual writes fail, how a transactional outbox keeps database state and events aligned, and what teams still need to handle around retries, idempotency, ordering, cleanup, and observability.</description>
      <category>Source &amp; Architecture</category>
      <category>Software Architecture</category>
      <category>Outbox Pattern</category>
      <category>Distributed Systems</category>
      <category>Event-Driven Architecture</category>
      <category>Reliability</category>
    </item>
    <item>
      <title>OKRs for Engineering Teams</title>
      <link>https://nguyenlephong.github.io/en/blog/ways-of-working/okrs-for-engineering-teams</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/ways-of-working/okrs-for-engineering-teams</guid>
      <pubDate>Thu, 14 May 2026 00:00:00 GMT</pubDate>
      <description>A practical guide to engineering OKRs: how to connect outcomes to delivery work, avoid task lists disguised as objectives, choose useful key results, and keep learning visible during the quarter.</description>
      <category>Ways of Working</category>
      <category>OKRs</category>
      <category>Engineering Management</category>
      <category>Ways of Working</category>
      <category>Software Delivery</category>
      <category>Team Planning</category>
    </item>
    <item>
      <title>Learning a New Language Every Year</title>
      <link>https://nguyenlephong.github.io/en/blog/perspectives/learning-a-new-language-every-year</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/perspectives/learning-a-new-language-every-year</guid>
      <pubDate>Wed, 13 May 2026 00:00:00 GMT</pubDate>
      <description>A reflective essay on learning one new programming or human language each year: how unfamiliar grammar, small exercises, patience, and comparison sharpen the way we think and communicate.</description>
      <category>Perspectives &amp; Field Notes</category>
      <category>Learning</category>
      <category>Programming Languages</category>
      <category>Career Growth</category>
      <category>Reflection</category>
      <category>Software Engineering</category>
    </item>
    <item>
      <title>AI in Cybersecurity</title>
      <link>https://nguyenlephong.github.io/en/blog/ai/ai-in-cybersecurity</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/ai/ai-in-cybersecurity</guid>
      <pubDate>Tue, 12 May 2026 00:00:00 GMT</pubDate>
      <description>A practical reflection on AI in cybersecurity: how AI helps detection, triage, secure coding, and incident response while creating new risks around automation, privacy, prompt injection, and false confidence.</description>
      <category>AI &amp; The Future</category>
      <category>AI</category>
      <category>Cybersecurity</category>
      <category>Security Engineering</category>
      <category>Incident Response</category>
      <category>Threat Detection</category>
    </item>
    <item>
      <title>Office Politics Without Losing Your Principles</title>
      <link>https://nguyenlephong.github.io/en/blog/culture/navigating-office-politics</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/culture/navigating-office-politics</guid>
      <pubDate>Mon, 11 May 2026 00:00:00 GMT</pubDate>
      <description>A practical guide to reading incentives, sharing context, pre-aligning openly, disagreeing with evidence, protecting boundaries, and knowing when a workplace is no longer worth the cost.</description>
      <category>Engineering Culture</category>
      <category>Engineering Culture</category>
      <category>Office Politics</category>
      <category>Leadership</category>
      <category>Communication</category>
      <category>Team Trust</category>
    </item>
    <item>
      <title>Do You Need a Service Mesh? Let Production Evidence Decide</title>
      <link>https://nguyenlephong.github.io/en/blog/architecture/service-mesh-do-you-need-it</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/architecture/service-mesh-do-you-need-it</guid>
      <pubDate>Sun, 10 May 2026 00:00:00 GMT</pubDate>
      <description>A practical decision guide for service mesh adoption: which production signals justify it, where the extra layer can fail, and how to pilot and roll back without betting the whole platform.</description>
      <category>Source &amp; Architecture</category>
      <category>Software Architecture</category>
      <category>Service Mesh</category>
      <category>Microservices</category>
      <category>Platform Engineering</category>
      <category>Observability</category>
    </item>
    <item>
      <title>Trunk-Based Development</title>
      <link>https://nguyenlephong.github.io/en/blog/ways-of-working/trunk-based-development</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/ways-of-working/trunk-based-development</guid>
      <pubDate>Sat, 09 May 2026 00:00:00 GMT</pubDate>
      <description>A practical introduction to trunk-based development: small frequent merges, feature flags, fast tests, code review discipline, and the team habits needed to keep the main branch healthy.</description>
      <category>Ways of Working</category>
      <category>Trunk-Based Development</category>
      <category>Continuous Integration</category>
      <category>Feature Flags</category>
      <category>Software Delivery</category>
      <category>Code Review</category>
    </item>
    <item>
      <title>Overcoming Analysis Paralysis</title>
      <link>https://nguyenlephong.github.io/en/blog/perspectives/overcoming-analysis-paralysis</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/perspectives/overcoming-analysis-paralysis</guid>
      <pubDate>Fri, 08 May 2026 00:00:00 GMT</pubDate>
      <description>A reflective essay on analysis paralysis: why careful thinking can turn into delay, how to separate reversible from irreversible choices, and how small experiments help decisions move without rushing.</description>
      <category>Perspectives &amp; Field Notes</category>
      <category>Decision Making</category>
      <category>Reflection</category>
      <category>Career Growth</category>
      <category>Software Engineering</category>
      <category>Learning</category>
    </item>
    <item>
      <title>Reducing Hallucinations in LLMs</title>
      <link>https://nguyenlephong.github.io/en/blog/ai/reducing-hallucinations-in-llms</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/ai/reducing-hallucinations-in-llms</guid>
      <pubDate>Thu, 07 May 2026 00:00:00 GMT</pubDate>
      <description>A practical guide to reducing LLM hallucinations with clearer tasks, bounded context, retrieval, citations, verification, refusals, evaluation sets, and product design that makes uncertainty visible.</description>
      <category>AI &amp; The Future</category>
      <category>AI</category>
      <category>LLM</category>
      <category>Hallucinations</category>
      <category>RAG</category>
      <category>AI Product</category>
    </item>
    <item>
      <title>The Difference Between Mentorship and Sponsorship</title>
      <link>https://nguyenlephong.github.io/en/blog/culture/mentorship-vs-sponsorship</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/culture/mentorship-vs-sponsorship</guid>
      <pubDate>Wed, 06 May 2026 00:00:00 GMT</pubDate>
      <description>A calm explanation of mentorship and sponsorship in engineering careers: how advice, feedback, advocacy, visibility, trust, and opportunity work together without turning growth into politics.</description>
      <category>Engineering Culture</category>
      <category>Engineering Culture</category>
      <category>Mentorship</category>
      <category>Sponsorship</category>
      <category>Career Growth</category>
      <category>Leadership</category>
    </item>
    <item>
      <title>Event Sourcing: A Beginner&apos;s Guide</title>
      <link>https://nguyenlephong.github.io/en/blog/architecture/event-sourcing-beginners-guide</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/architecture/event-sourcing-beginners-guide</guid>
      <pubDate>Tue, 05 May 2026 00:00:00 GMT</pubDate>
      <description>A beginner-friendly guide to Event Sourcing: storing facts as an append-only event history, rebuilding current state through projections, and understanding when the pattern is worth its operational cost.</description>
      <category>Source &amp; Architecture</category>
      <category>Software Architecture</category>
      <category>Event Sourcing</category>
      <category>Event-Driven Architecture</category>
      <category>CQRS</category>
      <category>System Design</category>
    </item>
    <item>
      <title>TDD: Is It Worth the Time?</title>
      <link>https://nguyenlephong.github.io/en/blog/ways-of-working/tdd-is-it-worth-the-time</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/ways-of-working/tdd-is-it-worth-the-time</guid>
      <pubDate>Mon, 04 May 2026 00:00:00 GMT</pubDate>
      <description>A practical reflection on when Test-Driven Development is worth the cost: how TDD shapes design, where it slows teams down, and how to use the red-green-refactor loop without turning it into dogma.</description>
      <category>Ways of Working</category>
      <category>TDD</category>
      <category>Testing</category>
      <category>Software Development</category>
      <category>Code Quality</category>
      <category>Refactoring</category>
    </item>
    <item>
      <title>Reading Code Is Harder Than Writing It</title>
      <link>https://nguyenlephong.github.io/en/blog/perspectives/reading-code-is-harder-than-writing-it</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/perspectives/reading-code-is-harder-than-writing-it</guid>
      <pubDate>Sun, 03 May 2026 00:00:00 GMT</pubDate>
      <description>A reflective essay on why reading code often feels harder than writing it, and how patient tracing, tests, naming, history, and small notes help engineers understand a codebase without rushing to rewrite it.</description>
      <category>Perspectives &amp; Field Notes</category>
      <category>Software Engineering</category>
      <category>Code Reading</category>
      <category>Codebase</category>
      <category>Maintainability</category>
      <category>Debugging</category>
    </item>
    <item>
      <title>Fine-Tuning vs. Prompting vs. RAG</title>
      <link>https://nguyenlephong.github.io/en/blog/ai/fine-tuning-vs-prompting-vs-rag</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/ai/fine-tuning-vs-prompting-vs-rag</guid>
      <pubDate>Sat, 02 May 2026 00:00:00 GMT</pubDate>
      <description>A practical comparison of prompting, RAG, and fine-tuning for AI products: what each approach changes, when it helps, where it fails, and how teams can choose the smallest reliable intervention.</description>
      <category>AI &amp; The Future</category>
      <category>AI</category>
      <category>Prompting</category>
      <category>RAG</category>
      <category>Fine-Tuning</category>
      <category>LLM</category>
    </item>
    <item>
      <title>Onboarding That Actually Helps New Teammates</title>
      <link>https://nguyenlephong.github.io/en/blog/culture/onboarding-that-actually-helps-new-teammates</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/culture/onboarding-that-actually-helps-new-teammates</guid>
      <pubDate>Fri, 01 May 2026 00:00:00 GMT</pubDate>
      <description>A calm look at engineering onboarding that helps people become useful without feeling lost: context, small early wins, clear ownership, buddy support, documentation, feedback loops, and patient team habits.</description>
      <category>Engineering Culture</category>
      <category>Engineering Culture</category>
      <category>Onboarding</category>
      <category>Team Trust</category>
      <category>Mentorship</category>
      <category>Documentation</category>
    </item>
    <item>
      <title>The Saga Pattern for Distributed Transactions</title>
      <link>https://nguyenlephong.github.io/en/blog/architecture/saga-pattern-for-distributed-transactions</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/architecture/saga-pattern-for-distributed-transactions</guid>
      <pubDate>Thu, 30 Apr 2026 00:00:00 GMT</pubDate>
      <description>A practical explanation of the Saga pattern for distributed transactions: why one database transaction stops working across services, how orchestration and choreography differ, and why compensation, observability, and idempotency matter.</description>
      <category>Source &amp; Architecture</category>
      <category>Software Architecture</category>
      <category>Saga Pattern</category>
      <category>Distributed Transactions</category>
      <category>Microservices</category>
      <category>Eventual Consistency</category>
    </item>
    <item>
      <title>Retrospectives That Actually Cause Change</title>
      <link>https://nguyenlephong.github.io/en/blog/ways-of-working/retrospectives-that-actually-cause-change</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/ways-of-working/retrospectives-that-actually-cause-change</guid>
      <pubDate>Wed, 29 Apr 2026 00:00:00 GMT</pubDate>
      <description>A practical look at retrospectives that produce visible follow-through: small experiments, clear action owners, trust, decision records, and measurable behavior change instead of another list of forgotten complaints.</description>
      <category>Ways of Working</category>
      <category>Retrospectives</category>
      <category>Agile</category>
      <category>Team Trust</category>
      <category>Continuous Improvement</category>
      <category>Decision Records</category>
    </item>
    <item>
      <title>Mentoring Junior Developers Effectively</title>
      <link>https://nguyenlephong.github.io/en/blog/perspectives/mentoring-junior-developers-effectively</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/perspectives/mentoring-junior-developers-effectively</guid>
      <pubDate>Tue, 28 Apr 2026 00:00:00 GMT</pubDate>
      <description>A practical reflection on mentoring junior developers through context, calibrated support, confidence, code review, recoverable mistakes, independence, and psychological safety without turning mentorship into control.</description>
      <category>Perspectives &amp; Field Notes</category>
      <category>Software Engineering</category>
      <category>Mentorship</category>
      <category>Junior Developers</category>
      <category>Code Review</category>
      <category>Psychological Safety</category>
    </item>
    <item>
      <title>Ethical Considerations in AI Products</title>
      <link>https://nguyenlephong.github.io/en/blog/ai/ethical-considerations-in-ai-products</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/ai/ethical-considerations-in-ai-products</guid>
      <pubDate>Mon, 27 Apr 2026 00:00:00 GMT</pubDate>
      <description>A practical article on product ethics for AI teams: consent, data boundaries, bias and fairness, human review, explanations, risk controls, and incentives that shape whether AI features remain useful and responsible.</description>
      <category>AI &amp; The Future</category>
      <category>AI</category>
      <category>AI Ethics</category>
      <category>Product Management</category>
      <category>Responsible AI</category>
      <category>Data Privacy</category>
    </item>
    <item>
      <title>Async Communication for Remote Teams</title>
      <link>https://nguyenlephong.github.io/en/blog/culture/async-communication-for-remote-teams</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/culture/async-communication-for-remote-teams</guid>
      <pubDate>Sun, 26 Apr 2026 00:00:00 GMT</pubDate>
      <description>A calm guide to async communication for remote teams: writing enough context, recording decisions, setting response expectations, improving handoffs, building trust, and protecting people from always-on pressure.</description>
      <category>Engineering Culture</category>
      <category>Engineering Culture</category>
      <category>Remote Work</category>
      <category>Async Communication</category>
      <category>Decision Records</category>
      <category>Team Trust</category>
    </item>
    <item>
      <title>API Gateway Patterns</title>
      <link>https://nguyenlephong.github.io/en/blog/architecture/api-gateway-patterns</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/architecture/api-gateway-patterns</guid>
      <pubDate>Sat, 25 Apr 2026 00:00:00 GMT</pubDate>
      <description>A practical look at API gateway responsibilities: routing, authentication boundaries, rate limiting, request aggregation, backend-for-frontend trade-offs, failure modes, and the observability needed to keep the edge of a system understandable.</description>
      <category>Source &amp; Architecture</category>
      <category>Software Architecture</category>
      <category>API Gateway</category>
      <category>Backend for Frontend</category>
      <category>Rate Limiting</category>
      <category>System Design</category>
    </item>
    <item>
      <title>Retrieval-Augmented Generation (RAG) Basics</title>
      <link>https://nguyenlephong.github.io/en/blog/ai/retrieval-augmented-generation-rag-basics</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/ai/retrieval-augmented-generation-rag-basics</guid>
      <pubDate>Fri, 24 Apr 2026 00:00:00 GMT</pubDate>
      <description>A beginner-friendly explanation of Retrieval-Augmented Generation: how documents are split into chunks, turned into embeddings, found with vector search, and used to ground AI answers with citations, evaluation, and clear failure checks.</description>
      <category>AI &amp; The Future</category>
      <category>AI</category>
      <category>RAG</category>
      <category>LLM</category>
      <category>Embeddings</category>
      <category>Vector Search</category>
    </item>
    <item>
      <title>The Value of a &quot;Boring&quot; Tech Stack</title>
      <link>https://nguyenlephong.github.io/en/blog/perspectives/value-of-a-boring-tech-stack</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/perspectives/value-of-a-boring-tech-stack</guid>
      <pubDate>Thu, 23 Apr 2026 00:00:00 GMT</pubDate>
      <description>A calm reflection on why stable, familiar technology often helps teams move with more confidence. The article looks at reliability, hiring, maintainability, shared knowledge, and the trade-offs behind choosing a tech stack that does not need to impress anyone.</description>
      <category>Perspectives &amp; Field Notes</category>
      <category>Software Engineering</category>
      <category>Tech Stack</category>
      <category>Maintainability</category>
      <category>Reliability</category>
      <category>Team Collaboration</category>
    </item>
    <item>
      <title>Hexagonal Architecture in Practice</title>
      <link>https://nguyenlephong.github.io/en/blog/architecture/hexagonal-architecture-in-practice</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/architecture/hexagonal-architecture-in-practice</guid>
      <pubDate>Wed, 22 Apr 2026 00:00:00 GMT</pubDate>
      <description>A practical guide to applying Hexagonal Architecture to one small feature: drawing the boundary, naming ports in business language, keeping adapters at the edge, testing the core, and deciding when the extra structure is worth the cost.</description>
      <category>Source &amp; Architecture</category>
      <category>Software Architecture</category>
      <category>Hexagonal Architecture</category>
      <category>Ports and Adapters</category>
      <category>Testing</category>
      <category>Code Organization</category>
    </item>
    <item>
      <title>Writing Good Acceptance Criteria</title>
      <link>https://nguyenlephong.github.io/en/blog/ways-of-working/writing-good-acceptance-criteria</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/ways-of-working/writing-good-acceptance-criteria</guid>
      <pubDate>Tue, 21 Apr 2026 00:00:00 GMT</pubDate>
      <description>A practical guide to writing acceptance criteria as shared evidence for done behavior: clear examples, important edge cases, reviewable scope, and a calmer handoff between product, engineering, QA, and stakeholders.</description>
      <category>Ways of Working</category>
      <category>Acceptance Criteria</category>
      <category>Agile</category>
      <category>User Stories</category>
      <category>Quality</category>
      <category>Team Collaboration</category>
    </item>
    <item>
      <title>Kanban vs. Scrum: Which Fits Better?</title>
      <link>https://nguyenlephong.github.io/en/blog/ways-of-working/kanban-vs-scrum-which-fits-better</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/ways-of-working/kanban-vs-scrum-which-fits-better</guid>
      <pubDate>Mon, 20 Apr 2026 00:00:00 GMT</pubDate>
      <description>A calm comparison of Kanban and Scrum through the shape of real team work: how requests arrive, how much WIP the team can carry, what kind of predictability the business needs, and which operating rhythm fits the team&apos;s context.</description>
      <category>Ways of Working</category>
      <category>Kanban</category>
      <category>Scrum</category>
      <category>Agile</category>
      <category>WIP</category>
      <category>Delivery</category>
    </item>
    <item>
      <title>Why I Stopped Writing Perfect Code</title>
      <link>https://nguyenlephong.github.io/en/blog/perspectives/why-i-stopped-writing-perfect-code</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/perspectives/why-i-stopped-writing-perfect-code</guid>
      <pubDate>Sun, 19 Apr 2026 00:00:00 GMT</pubDate>
      <description>A reflective essay on moving away from perfectionism in code and toward maintainable, understandable, reviewable work. The piece looks at why good code is not the most impressive version in isolation, but the version a team can safely understand, change, and carry forward.</description>
      <category>Perspectives &amp; Field Notes</category>
      <category>Software Engineering</category>
      <category>Code Quality</category>
      <category>Maintainability</category>
      <category>Career Growth</category>
      <category>Reflection</category>
    </item>
    <item>
      <title>The Context Window Bottleneck</title>
      <link>https://nguyenlephong.github.io/en/blog/ai/context-window-bottleneck</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/ai/context-window-bottleneck</guid>
      <pubDate>Sat, 18 Apr 2026 00:00:00 GMT</pubDate>
      <description>A practical look at context window limits as one of the quiet bottlenecks in AI workflows. The article explains why long chats, big codebases, stale summaries, and missing working memory can make AI assistance drift, and how teams can work around the limit without turning every task into a document dump.</description>
      <category>AI &amp; The Future</category>
      <category>AI</category>
      <category>Context Window</category>
      <category>LLM</category>
      <category>AI Workflow</category>
      <category>Software Engineering</category>
    </item>
    <item>
      <title>Handling Toxic Rockstars</title>
      <link>https://nguyenlephong.github.io/en/blog/culture/handling-toxic-rockstars</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/culture/handling-toxic-rockstars</guid>
      <pubDate>Fri, 17 Apr 2026 00:00:00 GMT</pubDate>
      <description>A calm look at high-output behavior that damages trust: why teams reward it, how feedback loops break, and how leaders can set boundaries while still offering a real repair path.</description>
      <category>Engineering Culture</category>
      <category>Engineering Culture</category>
      <category>Leadership</category>
      <category>Team Trust</category>
      <category>Feedback</category>
      <category>Psychological Safety</category>
    </item>
    <item>
      <title>Hiring for Potential vs. Experience</title>
      <link>https://nguyenlephong.github.io/en/blog/culture/hiring-for-potential-vs-experience</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/en/blog/culture/hiring-for-potential-vs-experience</guid>
      <pubDate>Thu, 16 Apr 2026 00:00:00 GMT</pubDate>
      <description>A calm reflection on balancing experience and potential in engineering hiring. The article focuses on evidence, learning pace, team needs, and the quiet conditions that help a person grow after they join.</description>
      <category>Engineering Culture</category>
      <category>Engineering Culture</category>
      <category>Hiring</category>
      <category>Team Building</category>
      <category>Engineering Leadership</category>
      <category>Career Growth</category>
    </item>
  </channel>
</rss>
