<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: Geunwoong Ryu</title>
    <description>The latest articles on DEV Community by Geunwoong Ryu (@gwmage).</description>
    <link>https://dev.to/gwmage</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4035064%2F94fad9f8-4592-4e3e-bfb7-2a385a445008.jpg</url>
      <title>DEV Community: Geunwoong Ryu</title>
      <link>https://dev.to/gwmage</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/gwmage"/>
    <language>en</language>
    <item>
      <title>45% of developers hit a knowledge silo every week. Here's the pattern we kept seeing.</title>
      <dc:creator>Geunwoong Ryu</dc:creator>
      <pubDate>Mon, 20 Jul 2026 00:03:15 +0000</pubDate>
      <link>https://dev.to/gwmage/45-of-developers-hit-a-knowledge-silo-every-week-heres-the-pattern-we-kept-seeing-a3g</link>
      <guid>https://dev.to/gwmage/45-of-developers-hit-a-knowledge-silo-every-week-heres-the-pattern-we-kept-seeing-a3g</guid>
      <description>&lt;p&gt;Every team I've talked to over the past few months has some version of the same story. A new hire joins, gets pointed at Confluence or Notion, and finds pages that are technically accurate and completely useless for understanding why anything is built the way it is.&lt;/p&gt;

&lt;p&gt;Nobody set out to make bad docs. The docs were fine when they were written.&lt;/p&gt;

&lt;p&gt;The problem is nobody links the doc for the payments refactor to the incident that caused it, or the Slack thread where the actual tradeoff got argued out. Six months later that context is gone even though the doc is still sitting there.&lt;/p&gt;

&lt;p&gt;I started digging into how teams actually lose this and it's a smaller list of causes than I expected. Writing it up here.&lt;/p&gt;

</description>
      <category>programming</category>
      <category>productivity</category>
    </item>
    <item>
      <title>Searchable isn't the same as connected: why team docs still make new hires ask 'why'</title>
      <dc:creator>Geunwoong Ryu</dc:creator>
      <pubDate>Sun, 19 Jul 2026 02:54:18 +0000</pubDate>
      <link>https://dev.to/gwmage/searchable-isnt-the-same-as-connected-why-team-docs-still-make-new-hires-ask-why-125h</link>
      <guid>https://dev.to/gwmage/searchable-isnt-the-same-as-connected-why-team-docs-still-make-new-hires-ask-why-125h</guid>
      <description>&lt;p&gt;Every team doc tool these days is "searchable." Notion, Confluence, wikis — you can find any page in seconds. But search only tells you a document exists; it doesn't tell you how it connects to the five other docs that explain why it looks the way it does. New hires still end up pinging three people on Slack to reconstruct the reasoning behind a decision that's technically "documented" somewhere. This post is about the difference between a searchable knowledge base and a connected one — and why most teams have the first but assume they have the second.&lt;/p&gt;

</description>
      <category>ai</category>
      <category>programming</category>
      <category>productivity</category>
      <category>webdev</category>
    </item>
    <item>
      <title>Why Search Isn't Enough for Team Docs — What We Learned Building a Knowledge Graph Layer</title>
      <dc:creator>Geunwoong Ryu</dc:creator>
      <pubDate>Sat, 18 Jul 2026 15:22:17 +0000</pubDate>
      <link>https://dev.to/gwmage/why-search-isnt-enough-for-team-docs-what-we-learned-building-a-knowledge-graph-layer-5b17</link>
      <guid>https://dev.to/gwmage/why-search-isnt-enough-for-team-docs-what-we-learned-building-a-knowledge-graph-layer-5b17</guid>
      <description>&lt;p&gt;Every team doc tool promises "search everything." Ours did too — and it still didn't answer the question new hires actually ask: not "where is this doc," but "why does this decision look the way it does, and what else does it touch?"&lt;/p&gt;

&lt;p&gt;We spent the last few months trying to solve that by treating team docs less like a filing cabinet and more like a graph. Here's what we tried, what broke, and what we'd do differently.&lt;/p&gt;

</description>
      <category>devjournal</category>
      <category>productivity</category>
      <category>showdev</category>
      <category>softwareengineering</category>
    </item>
  </channel>
</rss>
