<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Learning on Krishnatejaswi S</title>
    <link>https://KTS-o7.github.io/bear/tags/learning/</link>
    <description>Recent content in Learning on Krishnatejaswi S</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-us</language>
    <managingEditor>shentharkrishnatejaswi@gmail.com (Krishnatejaswi S)</managingEditor>
    <webMaster>shentharkrishnatejaswi@gmail.com (Krishnatejaswi S)</webMaster>
    <copyright>Krishnatejaswi S</copyright>
    <lastBuildDate>Sat, 02 May 2026 00:00:00 +0530</lastBuildDate>
    <atom:link href="https://KTS-o7.github.io/bear/tags/learning/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Teaching Myself CS: The Plan</title>
      <link>https://KTS-o7.github.io/bear/notes/teaching_myself_cs/</link>
      <pubDate>Sat, 02 May 2026 00:00:00 +0530</pubDate><author>shentharkrishnatejaswi@gmail.com (Krishnatejaswi S)</author>
      <guid>https://KTS-o7.github.io/bear/notes/teaching_myself_cs/</guid>
      <description>&lt;p&gt;I&amp;rsquo;ve been building things with code for a while now, but there are gaps. Not the kind that show up in day-to-day work &amp;ndash; the kind that show up when you&amp;rsquo;re reading a paper and hit a concept you sort of understand but can&amp;rsquo;t really explain, or when you&amp;rsquo;re debugging something deep in a system and realize you&amp;rsquo;re guessing at the underlying mechanics.&lt;/p&gt;&#xA;&lt;p&gt;The fix is obvious in theory: go back and learn the fundamentals properly. The hard part is doing it without spending two years on a degree or burning out on a curriculum that assumes you have nothing else going on.&lt;/p&gt;</description>
      <content:encoded><![CDATA[<p>I&rsquo;ve been building things with code for a while now, but there are gaps. Not the kind that show up in day-to-day work &ndash; the kind that show up when you&rsquo;re reading a paper and hit a concept you sort of understand but can&rsquo;t really explain, or when you&rsquo;re debugging something deep in a system and realize you&rsquo;re guessing at the underlying mechanics.</p>
<p>The fix is obvious in theory: go back and learn the fundamentals properly. The hard part is doing it without spending two years on a degree or burning out on a curriculum that assumes you have nothing else going on.</p>
<p>I&rsquo;ve been working through <a href="https://teachyourselfcs.com/">teachyourselfcs.com</a> as my backbone. Here&rsquo;s the plan I&rsquo;ve laid out for myself and why I structured it this way.</p>
<h2 id="the-curriculum">The Curriculum</h2>
<p>TYCS breaks CS into 9 subjects and gives you a primary book and video course for each. The order is a suggestion, not a law:</p>
<table>
  <thead>
      <tr>
          <th>Subject</th>
          <th>Book</th>
      </tr>
  </thead>
  <tbody>
      <tr>
          <td>Programming</td>
          <td>SICP</td>
      </tr>
      <tr>
          <td>Computer Architecture</td>
          <td>CS:APP / Nand2Tetris</td>
      </tr>
      <tr>
          <td>Algorithms &amp; Data Structures</td>
          <td>The Algorithm Design Manual (Skiena)</td>
      </tr>
      <tr>
          <td>Math for CS</td>
          <td>MIT 6.042J notes</td>
      </tr>
      <tr>
          <td>Operating Systems</td>
          <td>OSTEP</td>
      </tr>
      <tr>
          <td>Computer Networking</td>
          <td>Top-Down Approach</td>
      </tr>
      <tr>
          <td>Databases</td>
          <td>Readings in Database Systems</td>
      </tr>
      <tr>
          <td>Languages &amp; Compilers</td>
          <td>Crafting Interpreters</td>
      </tr>
      <tr>
          <td>Distributed Systems</td>
          <td>DDIA + MIT 6.824</td>
      </tr>
  </tbody>
</table>
<p>The book choices are deliberate. SICP isn&rsquo;t just a programming book &ndash; it&rsquo;s a book about how to think computationally. OSTEP is genuinely readable in a way most OS textbooks aren&rsquo;t. DDIA is probably the most practically useful book on the list if you&rsquo;re building anything that handles data at scale.</p>
<p>The target is 100-200 hours per subject. That&rsquo;s not a sprint, it&rsquo;s a multi-year project. The goal isn&rsquo;t to finish &ndash; it&rsquo;s to build genuine depth in each area, then keep revisiting.</p>
<h2 id="the-problem-i-had-to-solve-first">The Problem I Had to Solve First</h2>
<p>Standard study advice &ndash; &ldquo;30 minutes every day&rdquo; &ndash; doesn&rsquo;t work for me. I have high activation energy to start anything. Once I&rsquo;m in, momentum takes over and I&rsquo;ll go for hours. But that first 15 minutes of friction is real and it kills sessions before they begin.</p>
<p>So the plan is ignition-focused rather than sustainment-focused:</p>
<ul>
<li>Sessions start with a 15-minute minimum, not a 2-hour block. The bar to start is low. Once started, I usually continue past it.</li>
<li>Entry point is whatever subject feels most alive right now, not necessarily the next one in sequence. The order matters less than actually engaging.</li>
<li>Each subject has a concrete project attached &ndash; something you build, not just something you read. The project gives momentum a direction.</li>
</ul>
<p>The Newton iteration thing from the TYCS intro stuck with me: when you hit something you don&rsquo;t understand, go back to the start of the section and re-read. Each pass gets you further. Don&rsquo;t skip over confusion &ndash; re-enter it.</p>
<h2 id="how-im-ordering-it">How I&rsquo;m Ordering It</h2>
<p>I&rsquo;m starting with three subjects in parallel across the first phase rather than going strictly sequential:</p>
<p><strong>Programming (SICP)</strong> &ndash; Chapters 1-3, doing every exercise. The exercises are the learning. Reading without doing is just moving your eyes across text. I&rsquo;m supplementing with Exercism problems when I want something more applied.</p>
<p><strong>Computer Architecture (CS:APP / Nand2Tetris)</strong> &ndash; Starting with Nand2Tetris projects 1-5 because they&rsquo;re hands-on in a way that makes the abstractions stick. Build an ALU, then a CPU, then an assembler. By the time you reach CS:APP, you&rsquo;ve already built the thing the book describes.</p>
<p><strong>Distributed Systems (DDIA)</strong> &ndash; Running this in parallel because I&rsquo;m already working in this space and the reading compounds immediately with real work. DDIA cover-to-cover, then 2-3 papers per week from the MIT DSG reading list. The project target is implementing a Raft consensus module.</p>
<p>Algorithms and Math for CS come after the first wave. The ML path runs alongside: Andrew Ng&rsquo;s ML course after Algorithms, fast.ai after OS and Networking.</p>
<h2 id="what-im-not-doing">What I&rsquo;m Not Doing</h2>
<p>No video lectures unless I&rsquo;m stuck. The TYCS authors are explicit that books are the primary medium and videos are optional supplements. I&rsquo;ve defaulted to videos too many times in the past &ndash; they feel productive but the retention without active practice is low.</p>
<p>No skipping exercises to &ldquo;get through&rdquo; material faster. The only way through SICP is through the exercises. Same with Nand2Tetris. The projects aren&rsquo;t extra credit, they&rsquo;re the point.</p>
<p>No treating this as interview prep. The goal is actual understanding. Some of it will be useful in interviews, but that&rsquo;s a side effect, not the frame.</p>
<p>I&rsquo;ll track hours per subject and update this post as I go.</p>
]]></content:encoded>
    </item>
  </channel>
</rss>
