<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>theboring.dev</title>
    <link>https://theboring.dev/</link>
    <description>Recent content on theboring.dev</description>
    <generator>Hugo</generator>
    <language>en</language>
    <copyright>&amp;copy; 2025 &amp;middot; &lt;a href=&#34;https://theboring.dev/&#34;&gt;theboring.dev&lt;/a&gt;
</copyright>
    <lastBuildDate>Tue, 27 Jul 2021 01:26:00 +0545</lastBuildDate>
    <atom:link href="https://theboring.dev/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>You don&#39;t know what you don&#39;t know!</title>
      <link>https://theboring.dev/ramblings/you-dont-know-what-you-dont-know/</link>
      <pubDate>Wed, 02 Jun 2021 20:33:00 +0545</pubDate>
      <guid>https://theboring.dev/ramblings/you-dont-know-what-you-dont-know/</guid>
      <description>&lt;p&gt;When working with computers, we often encounter issues that we never anticipate. If you have written a piece of software, you might have faced issues where something goes haywire, but you don&amp;rsquo;t know the root cause behind it. These issues could have come from the code itself, the operating system, the network, an external dependency or something else. It can often be intimidating to debug these issues because it needs a thorough root cause analysis before we can patch them. For example, let&amp;rsquo;s say you have a memory leak in your code, and every so often, your backend service goes down because it is asking for more memory than what the system has. The classic makeshift solution to something like this is to turn the service off and on again, and yes, the heap is free. However, the fair resolution is to figure out that it is an actual memory leak, find the culprit code, and patch it up.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
