<?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: Mrinal</title>
    <description>The latest articles on DEV Community by Mrinal (@hi_mrinal).</description>
    <link>https://dev.to/hi_mrinal</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.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F983466%2F228a986f-dbaf-4304-9be3-b53edb537f8c.jpeg</url>
      <title>DEV Community: Mrinal</title>
      <link>https://dev.to/hi_mrinal</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/hi_mrinal"/>
    <language>en</language>
    <item>
      <title>Change of questioning is important</title>
      <dc:creator>Mrinal</dc:creator>
      <pubDate>Fri, 06 Feb 2026 00:12:43 +0000</pubDate>
      <link>https://dev.to/hi_mrinal/change-of-questioning-is-important-2nm9</link>
      <guid>https://dev.to/hi_mrinal/change-of-questioning-is-important-2nm9</guid>
      <description>&lt;p&gt;I think "How should I start open source contribution" question should change into "How do I understand OS Projects enough to contribute" would help more than ever &lt;/p&gt;

&lt;p&gt;One needs a real change from "how to contribute" to "How to navigate huge projects" and in my opinion navigating huge project is one of the longest  skill to acquire, relying less on memorization and more on a set tool proficiency and intuition around architecture.&lt;/p&gt;

&lt;p&gt;All though you cannot really rely on Devin's explanation of the repository (sometimes you can but at the end you need to be intuitive enough with the architecture so that you can quickly adopt to it)&lt;/p&gt;

&lt;p&gt;The intuition part is about intent. One should always start with a concrete goal and trace toward it. If a button triggers an action begin at the UI text or component, then follow the trail until you reach the business logic behind it. Folder structure, filenames and conventions often tell you more than the code itself if you know how to read those signals.&lt;/p&gt;

&lt;p&gt;What I try to avoid entirely is reading code at random. I only read code when I am forming a mental model of specific area or answering a specific question. Hence I conclude, one should only be reading code to confirm a specific hypothesis or build a mental model of a feature, not to absorb the entire project at once.&lt;/p&gt;

</description>
      <category>opensource</category>
      <category>programming</category>
    </item>
  </channel>
</rss>
