How to Get Cracked at Programming

Main ideas / lessons (6 programming principles)

Principle 1: Study the level below the one you’re working at

• Don’t only add more frameworks/tools; understand the underlying “problem layer” they solve.
• Tools expire; problems don’t.
  • Every tool answers a question that existed before the tool.
  • Learning the question (the underlying problem) transfers across technologies for years/decades.

Instructional takeaway (layering approach):

• Identify the abstractions you’re using (framework, library).
• Spend about 1 hour studying the layer directly below it (e.g., OS/file system, database internals, transport protocol).
• Don’t try to study the entire broader layer/stack.

Example given (durability via logging):

• Question: how does a database prevent data loss if power fails mid-write?
• Answer: write an intent/log first, then write actual data later.
  • If the machine fails after the log, the system replays/restores from the log on reboot.

Examples mentioned:

• Postgres
• MySQL InnoDB (when “pre-log mode” is enabled)
• SQLite (in similar journaling behavior)

---

Principle 2: Avoid “textbook hell”

Textbooks and tutorials can create an illusion of competence because they show working systems without real confusion/edge cases.

Instructional takeaway (learning by failure):

• Build something without relying on fully decided scaffolding.
• Choose projects where you must confront missing architecture decisions and tricky protocol details.

Example given (TCP message boundaries):

• When building a basic HTTP server on raw sockets:
  • The speaker assumed one socket read == one full request.
  • Real behavior: TCP is a byte stream without message boundaries.
  • HTTP includes mechanisms like Content-Length to determine where a message ends.

Lesson: learn to ask the consistent foundational question:

• “Where does one message end?”

This applies to multiple protocols mentioned:

• WebSockets, gRPC, message queues

---

Principle 3: Become a code archaeologist

Use your repository history to find answers to past problems and mistakes.

Instructional takeaway (Git-first workflow): Use two Git commands heavily:

• git blame
  • Shows who last changed a line and in which commit.
  • Before deleting misunderstood code: read the commit message (often explains the bug/why a change was made).
• git bisect
  • Finds the commit where a bug was introduced by repeatedly narrowing the range between “known broken” and “known working.”

Outcome claim:

• A large history can be searched quickly (e.g., resolving many commits in ~10 checks rather than guessing for a full day).

---

Principle 4: Debug like a scientist (structured debugging method)

A repeatable 3-step loop is presented:

1. Step 1: Hypothesize

   • Don’t touch code yet.
   • Be specific about what is not working.
   • Hypotheses are things you can be wrong about—use that to refine your model.

2. Step 2: Isolate

   • Remove everything that isn’t part of the error.
   • Find the smallest instance that reproduces the failure.
   • Many errors are discovered at this stage.

3. Step 3: Protest

   • Write a test that fails.
   • Once the failure is reliably reproduced, the fix is usually straightforward.
   • Keep the test forever to prevent regression.

Tooling advice: learn a real debugger

• Examples mentioned: PDB, Delve, Chrome DevTools
• Example feature: conditional breakpoints to inspect variables in precisely the failing condition.
• Analogy: debugging with a conditional breakpoint is like “MRI” vs “poking someone with a stick.”

---

Principle 5: Assume everything will break (resilience-first coding)

Treat network calls like probabilistic events:

• Every network call is a coin toss (success/failure you can’t see in advance).

Instructional habits:

1. Idempotency / “efficiency of the element”

   • Ensure doing something twice has the same effect as doing it once.
   • Use a mechanism like an idempotency key:
     • Client sends a unique key (often via header).
     • Server stores the key with the result.
     • If the same key is seen again, return the stored result rather than re-executing.
   • Reason: requests can succeed but acknowledgements can be lost, causing retries that otherwise double-charge.
   • Example mentioned: a payment retry led to double charging when the idempotency key wasn’t used.

2. Exponential backoff with jitter

   • Retry delays grow exponentially: 1s, 2s, 4s, 8s…
   • Add random jitter so clients don’t retry in synchronized waves.
   • Set explicit timeouts for each network call (do not rely on defaults).

Warning:

• If many clients retry simultaneously (perfect rhythm), it can create a self-amplifying failure (like a denial-of-service against yourself).

---

Principle 6: Measure, don’t guess (prove performance claims)

Intuition about performance is unreliable; measurement must replace guessing.

Instructional takeaway (profiling approach):

• Know why performance differs:
  • Arrays vs linked lists: arrays benefit from cache locality (cache lines ~64 bytes).
  • Linked lists often suffer pointer chasing and poor locality.
• Use profilers to identify bottlenecks:
  • Examples mentioned:
    • PySpy (Python)
    • pprof (Go)
    • Chrome DevTools (JavaScript)
  • Use flame graphs:
    • Wider bars indicate more time spent in a function.
    • Find the widest area, then ask “why?”
• Profile not just CPU but also other effects:
  • In GC languages, “slow functions” may just trigger garbage collection.
  • Hidden costs might come from unexpected helpers or issues like N+1 queries.
• Do comparative before/after analysis:
  • You must show a number proving it got faster.
  • Otherwise you may have made the code uglier without real gains.

---

Conclusion / prioritized adoption plan

• Don’t try to do all six principles immediately (nobody does).
• Recommended starting point:
  • Start with point 4: learn your debugger properly
  • It takes about a day and pays off quickly.
• Also, the video includes a sponsored suggestion to use TryHackMe (see “Speakers/Sources”).

---

Speakers / sources featured

• TryHackMe (video sponsor; mentioned multiple times for training content and a discount/code)

Code / technology mentioned as examples (not as speakers)

Databases:

• Postgres, MySQL InnoDB, SQLite

File system:

• EXT4 journaling

Protocols/tools:

• React, Vue, Svelte, Next
• Express/Flask/Gin
• WebSockets, gRPC

Git commands:

• git blame, git bisect

Debuggers/profilers/tools:

• PDB, Delve, Chrome DevTools
• PySpy, pprof

Languages/framework ecosystem mentioned:

• Python, Go, JavaScript, Axios, Go http.Client, Python requests

Performance concepts:

• cache, cache lines (64 bytes), L1 vs main memory
• flame graphs