<?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>Forem: Naveen Karasu</title>
    <description>The latest articles on Forem by Naveen Karasu (@thinkkun).</description>
    <link>https://forem.com/thinkkun</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%2F2911102%2Fa69591e1-4e13-492f-a849-6588a8dd2be0.png</url>
      <title>Forem: Naveen Karasu</title>
      <link>https://forem.com/thinkkun</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://forem.com/feed/thinkkun"/>
    <language>en</language>
    <item>
      <title>Day 1/60: Go backend development setup - Go Backend Engineering</title>
      <dc:creator>Naveen Karasu</dc:creator>
      <pubDate>Fri, 24 Apr 2026 17:14:46 +0000</pubDate>
      <link>https://forem.com/thinkkun/day-160-go-backend-development-setup-go-backend-engineering-25a0</link>
      <guid>https://forem.com/thinkkun/day-160-go-backend-development-setup-go-backend-engineering-25a0</guid>
      <description>&lt;h1&gt;
  
  
  Day 1/60: Go backend development setup
&lt;/h1&gt;

&lt;p&gt;&lt;em&gt;60 Day Go Backend Engineering Challenge&lt;/em&gt;&lt;/p&gt;

&lt;p&gt;Today I focused on building a Go backend workspace that makes services easy to run, test, and evolve. The strongest checkpoints were keep the module layout simple enough that handlers, services, and storage code do not bleed together, use go run, go test, and a small local config path as part of the feedback loop instead of as afterthoughts, and treat tooling choices as part of the service design because they compound over 60 days.&lt;/p&gt;

&lt;p&gt;The mistake I wanted to avoid was treating project shape as disposable and rebuilding the same service skeleton every week. The day felt better once the service boundary stayed visible and each component had one job.&lt;/p&gt;

&lt;p&gt;The goal for tomorrow is simple: keep the rule clear enough that the next service still feels related to the same design idea. I also want to keep tracing one request path end to end because it exposes weak assumptions faster than a larger demo.&lt;/p&gt;

</description>
      <category>go</category>
      <category>backend</category>
      <category>api</category>
      <category>softwareengineering</category>
    </item>
    <item>
      <title>Day 1/60: JavaScript DSA environment setup - JavaScript DSA</title>
      <dc:creator>Naveen Karasu</dc:creator>
      <pubDate>Fri, 24 Apr 2026 17:08:15 +0000</pubDate>
      <link>https://forem.com/thinkkun/day-160-javascript-dsa-environment-setup-javascript-dsa-4c82</link>
      <guid>https://forem.com/thinkkun/day-160-javascript-dsa-environment-setup-javascript-dsa-4c82</guid>
      <description>&lt;h1&gt;
  
  
  Day 1/60: JavaScript DSA environment setup
&lt;/h1&gt;

&lt;p&gt;&lt;em&gt;60 Day DSA in JavaScript Challenge&lt;/em&gt;&lt;/p&gt;

&lt;p&gt;Today I focused on building a JavaScript setup that makes daily DSA work fast to run, inspect, and test. The strongest checkpoints were keep the project layout simple enough that daily problems share helpers and quick checks cleanly, use node, console checks, and test scripts as part of the feedback loop instead of as afterthoughts, and treat tooling choices as part of the practice system because they compound over 60 days.&lt;/p&gt;

&lt;p&gt;The mistake I wanted to avoid was treating the setup as disposable and rebuilding the same helpers every day. The day felt better once the invariant stayed visible and each update had one job.&lt;/p&gt;

&lt;p&gt;The goal for tomorrow is simple: keep the rule clear enough that the next variation still feels related to the same idea. I also want to keep tracing tiny examples because they expose weak assumptions faster than large random tests.&lt;/p&gt;

</description>
      <category>javascript</category>
      <category>dsa</category>
      <category>algorithms</category>
      <category>codinginterview</category>
    </item>
    <item>
      <title>Day 1/60: Rust DSA environment setup - Rust DSA</title>
      <dc:creator>Naveen Karasu</dc:creator>
      <pubDate>Fri, 24 Apr 2026 17:02:44 +0000</pubDate>
      <link>https://forem.com/thinkkun/day-160-rust-dsa-environment-setup-rust-dsa-5fkb</link>
      <guid>https://forem.com/thinkkun/day-160-rust-dsa-environment-setup-rust-dsa-5fkb</guid>
      <description>&lt;h1&gt;
  
  
  Day 1/60: Rust DSA environment setup
&lt;/h1&gt;

&lt;p&gt;&lt;em&gt;60 Day Rust DSA Challenge&lt;/em&gt;&lt;/p&gt;

&lt;p&gt;Today I focused on building a Rust workspace that makes daily DSA work fast to run, test, and benchmark. The strongest checkpoints were keep the project layout simple enough that daily problems share tests and helpers cleanly, use cargo, tests, and benchmarks as part of the feedback loop instead of as afterthoughts, and treat tooling choices as part of the practice system because they compound over 60 days.&lt;/p&gt;

&lt;p&gt;The mistake I wanted to avoid was treating the workspace as disposable and rebuilding the same helpers every day. The day felt better once the invariant stayed visible and each update had one job.&lt;/p&gt;

&lt;p&gt;The goal for tomorrow is simple: keep the rule clear enough that the next variation still feels related to the same idea. I also want to keep tracing tiny examples because they expose weak assumptions faster than large random tests.&lt;/p&gt;

</description>
      <category>rust</category>
      <category>dsa</category>
      <category>algorithms</category>
      <category>codinginterview</category>
    </item>
    <item>
      <title>Day 1/75: Go DSA environment setup - Go DSA</title>
      <dc:creator>Naveen Karasu</dc:creator>
      <pubDate>Fri, 24 Apr 2026 16:55:14 +0000</pubDate>
      <link>https://forem.com/thinkkun/day-175-go-dsa-environment-setup-go-dsa-jbi</link>
      <guid>https://forem.com/thinkkun/day-175-go-dsa-environment-setup-go-dsa-jbi</guid>
      <description>&lt;h1&gt;
  
  
  Day 1/75: Go DSA environment setup
&lt;/h1&gt;

&lt;p&gt;&lt;em&gt;75 Day DSA in Go Challenge&lt;/em&gt;&lt;/p&gt;

&lt;p&gt;Today I focused on building a Go setup that makes daily DSA work fast to run, inspect, and benchmark. The strongest checkpoints were keep the project layout simple enough that daily problems share helpers and quick checks cleanly, use go run, go test, and tiny benchmarks as part of the feedback loop instead of as afterthoughts, and treat tooling choices as part of the practice system because they compound over 60 days.&lt;/p&gt;

&lt;p&gt;The mistake I wanted to avoid was treating the setup as disposable and rebuilding the same helpers every day. The day felt better once the invariant stayed visible and each update had one job.&lt;/p&gt;

&lt;p&gt;The goal for tomorrow is simple: keep the rule clear enough that the next variation still feels related to the same idea. I also want to keep tracing tiny examples because they expose weak assumptions faster than large random tests.&lt;/p&gt;

</description>
      <category>go</category>
      <category>dsa</category>
      <category>algorithms</category>
      <category>codinginterview</category>
    </item>
    <item>
      <title>Day 1/75: C++ DSA environment setup - C++ DSA</title>
      <dc:creator>Naveen Karasu</dc:creator>
      <pubDate>Fri, 24 Apr 2026 16:48:12 +0000</pubDate>
      <link>https://forem.com/thinkkun/day-175-c-dsa-environment-setup-c-dsa-2p7l</link>
      <guid>https://forem.com/thinkkun/day-175-c-dsa-environment-setup-c-dsa-2p7l</guid>
      <description>&lt;h1&gt;
  
  
  Day 1/75: C++ DSA environment setup
&lt;/h1&gt;

&lt;p&gt;&lt;em&gt;75 Day DSA in C++ Challenge&lt;/em&gt;&lt;/p&gt;

&lt;p&gt;Today I focused on building a C++ setup that makes daily DSA work fast to compile, run, and profile. The strongest checkpoints were keep the project layout simple enough that daily problems share helpers and quick checks cleanly, use g++, tiny harnesses, and fast reruns as part of the feedback loop instead of as afterthoughts, and treat tooling choices as part of the practice system because they compound over 60 days.&lt;/p&gt;

&lt;p&gt;The mistake I wanted to avoid was treating the setup as disposable and rebuilding the same helpers every day. The day felt better once the invariant stayed visible and each update had one job.&lt;/p&gt;

&lt;p&gt;The goal for tomorrow is simple: keep the rule clear enough that the next variation still feels related to the same idea. I also want to keep tracing tiny examples because they expose weak assumptions faster than large random tests.&lt;/p&gt;

</description>
      <category>cpp</category>
      <category>dsa</category>
      <category>algorithms</category>
      <category>codinginterview</category>
    </item>
    <item>
      <title>Day 1/60: Go backend development setup - Go Backend Engineering</title>
      <dc:creator>Naveen Karasu</dc:creator>
      <pubDate>Fri, 24 Apr 2026 00:34:54 +0000</pubDate>
      <link>https://forem.com/thinkkun/day-160-go-backend-development-setup-go-backend-engineering-1lpa</link>
      <guid>https://forem.com/thinkkun/day-160-go-backend-development-setup-go-backend-engineering-1lpa</guid>
      <description>&lt;h1&gt;
  
  
  Day 1/60: Go backend development setup
&lt;/h1&gt;

&lt;p&gt;&lt;em&gt;60 Day Go Backend Engineering Challenge&lt;/em&gt;&lt;/p&gt;

&lt;p&gt;Today I focused on building a Go backend workspace that makes services easy to run, test, and evolve. The strongest checkpoints were keep the module layout simple enough that handlers, services, and storage code do not bleed together, use go run, go test, and a small local config path as part of the feedback loop instead of as afterthoughts, and treat tooling choices as part of the service design because they compound over 60 days.&lt;/p&gt;

&lt;p&gt;The mistake I wanted to avoid was treating project shape as disposable and rebuilding the same service skeleton every week. The day felt better once the service boundary stayed visible and each component had one job.&lt;/p&gt;

&lt;p&gt;The goal for tomorrow is simple: keep the rule clear enough that the next service still feels related to the same design idea. I also want to keep tracing one request path end to end because it exposes weak assumptions faster than a larger demo.&lt;/p&gt;

</description>
      <category>go</category>
      <category>backend</category>
      <category>api</category>
      <category>softwareengineering</category>
    </item>
    <item>
      <title>Day 1/60: JavaScript DSA environment setup - JavaScript DSA</title>
      <dc:creator>Naveen Karasu</dc:creator>
      <pubDate>Fri, 24 Apr 2026 00:26:54 +0000</pubDate>
      <link>https://forem.com/thinkkun/day-160-javascript-dsa-environment-setup-javascript-dsa-45hn</link>
      <guid>https://forem.com/thinkkun/day-160-javascript-dsa-environment-setup-javascript-dsa-45hn</guid>
      <description>&lt;h1&gt;
  
  
  Day 1/60: JavaScript DSA environment setup
&lt;/h1&gt;

&lt;p&gt;&lt;em&gt;60 Day DSA in JavaScript Challenge&lt;/em&gt;&lt;/p&gt;

&lt;p&gt;Today I focused on building a JavaScript setup that makes daily DSA work fast to run, inspect, and test. The strongest checkpoints were keep the project layout simple enough that daily problems share helpers and quick checks cleanly, use node, console checks, and test scripts as part of the feedback loop instead of as afterthoughts, and treat tooling choices as part of the practice system because they compound over 60 days.&lt;/p&gt;

&lt;p&gt;The mistake I wanted to avoid was treating the setup as disposable and rebuilding the same helpers every day. The day felt better once the invariant stayed visible and each update had one job.&lt;/p&gt;

&lt;p&gt;The goal for tomorrow is simple: keep the rule clear enough that the next variation still feels related to the same idea. I also want to keep tracing tiny examples because they expose weak assumptions faster than large random tests.&lt;/p&gt;

</description>
      <category>javascript</category>
      <category>dsa</category>
      <category>algorithms</category>
      <category>codinginterview</category>
    </item>
    <item>
      <title>Day 1/60: Rust DSA environment setup - Rust DSA</title>
      <dc:creator>Naveen Karasu</dc:creator>
      <pubDate>Fri, 24 Apr 2026 00:19:09 +0000</pubDate>
      <link>https://forem.com/thinkkun/day-160-rust-dsa-environment-setup-rust-dsa-4c6a</link>
      <guid>https://forem.com/thinkkun/day-160-rust-dsa-environment-setup-rust-dsa-4c6a</guid>
      <description>&lt;h1&gt;
  
  
  Day 1/60: Rust DSA environment setup
&lt;/h1&gt;

&lt;p&gt;&lt;em&gt;60 Day Rust DSA Challenge&lt;/em&gt;&lt;/p&gt;

&lt;p&gt;Today I focused on building a Rust workspace that makes daily DSA work fast to run, test, and benchmark. The strongest checkpoints were keep the project layout simple enough that daily problems share tests and helpers cleanly, use cargo, tests, and benchmarks as part of the feedback loop instead of as afterthoughts, and treat tooling choices as part of the practice system because they compound over 60 days.&lt;/p&gt;

&lt;p&gt;The mistake I wanted to avoid was treating the workspace as disposable and rebuilding the same helpers every day. The day felt better once the invariant stayed visible and each update had one job.&lt;/p&gt;

&lt;p&gt;The goal for tomorrow is simple: keep the rule clear enough that the next variation still feels related to the same idea. I also want to keep tracing tiny examples because they expose weak assumptions faster than large random tests.&lt;/p&gt;

</description>
      <category>rust</category>
      <category>dsa</category>
      <category>algorithms</category>
      <category>codinginterview</category>
    </item>
    <item>
      <title>Day 1/75: Go DSA environment setup - Go DSA</title>
      <dc:creator>Naveen Karasu</dc:creator>
      <pubDate>Fri, 24 Apr 2026 00:10:24 +0000</pubDate>
      <link>https://forem.com/thinkkun/day-175-go-dsa-environment-setup-go-dsa-5god</link>
      <guid>https://forem.com/thinkkun/day-175-go-dsa-environment-setup-go-dsa-5god</guid>
      <description>&lt;h1&gt;
  
  
  Day 1/75: Go DSA environment setup
&lt;/h1&gt;

&lt;p&gt;&lt;em&gt;75 Day DSA in Go Challenge&lt;/em&gt;&lt;/p&gt;

&lt;p&gt;Today I focused on building a Go setup that makes daily DSA work fast to run, inspect, and benchmark. The strongest checkpoints were keep the project layout simple enough that daily problems share helpers and quick checks cleanly, use go run, go test, and tiny benchmarks as part of the feedback loop instead of as afterthoughts, and treat tooling choices as part of the practice system because they compound over 60 days.&lt;/p&gt;

&lt;p&gt;The mistake I wanted to avoid was treating the setup as disposable and rebuilding the same helpers every day. The day felt better once the invariant stayed visible and each update had one job.&lt;/p&gt;

&lt;p&gt;The goal for tomorrow is simple: keep the rule clear enough that the next variation still feels related to the same idea. I also want to keep tracing tiny examples because they expose weak assumptions faster than large random tests.&lt;/p&gt;

</description>
      <category>go</category>
      <category>dsa</category>
      <category>algorithms</category>
      <category>codinginterview</category>
    </item>
    <item>
      <title>Day 1/75: C++ DSA environment setup - C++ DSA</title>
      <dc:creator>Naveen Karasu</dc:creator>
      <pubDate>Fri, 24 Apr 2026 00:02:35 +0000</pubDate>
      <link>https://forem.com/thinkkun/day-175-c-dsa-environment-setup-c-dsa-30k</link>
      <guid>https://forem.com/thinkkun/day-175-c-dsa-environment-setup-c-dsa-30k</guid>
      <description>&lt;h1&gt;
  
  
  Day 1/75: C++ DSA environment setup
&lt;/h1&gt;

&lt;p&gt;&lt;em&gt;75 Day DSA in C++ Challenge&lt;/em&gt;&lt;/p&gt;

&lt;p&gt;Today I focused on building a C++ setup that makes daily DSA work fast to compile, run, and profile. The strongest checkpoints were keep the project layout simple enough that daily problems share helpers and quick checks cleanly, use g++, tiny harnesses, and fast reruns as part of the feedback loop instead of as afterthoughts, and treat tooling choices as part of the practice system because they compound over 60 days.&lt;/p&gt;

&lt;p&gt;The mistake I wanted to avoid was treating the setup as disposable and rebuilding the same helpers every day. The day felt better once the invariant stayed visible and each update had one job.&lt;/p&gt;

&lt;p&gt;The goal for tomorrow is simple: keep the rule clear enough that the next variation still feels related to the same idea. I also want to keep tracing tiny examples because they expose weak assumptions faster than large random tests.&lt;/p&gt;

</description>
      <category>cpp</category>
      <category>dsa</category>
      <category>algorithms</category>
      <category>codinginterview</category>
    </item>
    <item>
      <title>Day 1/75: Java DSA environment setup - Java DSA</title>
      <dc:creator>Naveen Karasu</dc:creator>
      <pubDate>Thu, 23 Apr 2026 23:54:38 +0000</pubDate>
      <link>https://forem.com/thinkkun/day-175-java-dsa-environment-setup-java-dsa-5425</link>
      <guid>https://forem.com/thinkkun/day-175-java-dsa-environment-setup-java-dsa-5425</guid>
      <description>&lt;h1&gt;
  
  
  Day 1/75: Java DSA environment setup
&lt;/h1&gt;

&lt;p&gt;&lt;em&gt;75 Day DSA in Java Challenge&lt;/em&gt;&lt;/p&gt;

&lt;p&gt;Today I focused on building a Java setup that makes daily DSA work fast to compile, run, and test. The strongest checkpoints were keep the project layout simple enough that daily problems share helpers and quick checks cleanly, use javac, small harnesses, and unit tests as part of the feedback loop instead of as afterthoughts, and treat tooling choices as part of the practice system because they compound over 60 days.&lt;/p&gt;

&lt;p&gt;The mistake I wanted to avoid was treating the setup as disposable and rebuilding the same helpers every day. The day felt better once the invariant stayed visible and each update had one job.&lt;/p&gt;

&lt;p&gt;The goal for tomorrow is simple: keep the rule clear enough that the next variation still feels related to the same idea. I also want to keep tracing tiny examples because they expose weak assumptions faster than large random tests.&lt;/p&gt;

</description>
      <category>java</category>
      <category>dsa</category>
      <category>algorithms</category>
      <category>codinginterview</category>
    </item>
    <item>
      <title>Day 1/75: Python DSA environment setup - Python DSA</title>
      <dc:creator>Naveen Karasu</dc:creator>
      <pubDate>Thu, 23 Apr 2026 23:47:07 +0000</pubDate>
      <link>https://forem.com/thinkkun/day-175-python-dsa-environment-setup-python-dsa-4c72</link>
      <guid>https://forem.com/thinkkun/day-175-python-dsa-environment-setup-python-dsa-4c72</guid>
      <description>&lt;h1&gt;
  
  
  Day 1/75: Python DSA environment setup
&lt;/h1&gt;

&lt;p&gt;&lt;em&gt;75 Day DSA in Python Challenge&lt;/em&gt;&lt;/p&gt;

&lt;p&gt;Today I focused on building a Python setup that makes daily DSA work fast to run, inspect, and test. The strongest checkpoints were keep the project layout simple enough that daily problems share helpers and quick checks cleanly, use the Python REPL, small scripts, and test files as part of the feedback loop instead of as afterthoughts, and treat tooling choices as part of the practice system because they compound over 60 days.&lt;/p&gt;

&lt;p&gt;The mistake I wanted to avoid was treating the setup as disposable and rebuilding the same helpers every day. The day felt better once the invariant stayed visible and each update had one job.&lt;/p&gt;

&lt;p&gt;The goal for tomorrow is simple: keep the rule clear enough that the next variation still feels related to the same idea. I also want to keep tracing tiny examples because they expose weak assumptions faster than large random tests.&lt;/p&gt;

</description>
      <category>python</category>
      <category>dsa</category>
      <category>algorithms</category>
      <category>codinginterview</category>
    </item>
  </channel>
</rss>
