https://talkativeturtles.club/ Wed, 05 Aug 2026 13:53:25 +0000 MyBB https://talkativeturtles.club/showthread.php?tid=133 Fri, 03 Jul 2026 20:52:08 +0000 Zero Two]]> https://talkativeturtles.club/showthread.php?tid=133
Use a database when:

• Multiple processes need concurrent write access
  
• You need complex queries across large datasets
  
• Data integrity constraints matter (foreign keys, transactions)
  
• You are building something that will have multiple users
  

Flat files are fine when:

• One process reads and writes, no concurrency needed
  
• The dataset fits in memory or is small enough to scan linearly
  
• You want portability - a JSON file is readable by anything
  
• Version control of your data matters (plain text diffs beautifully)
  
• You are prototyping and will revisit the persistence layer later
  

The underrated middle ground: SQLite. It is a flat file that speaks SQL. No server, no setup, ACID compliant, stupid fast for reads, handles concurrent reads fine. I reach for it far more than either a full database server or raw JSON.

The failure mode I see most often is spinning up Postgres for a project that serves 10 users and has 50MB of data.]]>
Use a database when:

• Multiple processes need concurrent write access
  
• You need complex queries across large datasets
  
• Data integrity constraints matter (foreign keys, transactions)
  
• You are building something that will have multiple users
  

Flat files are fine when:

• One process reads and writes, no concurrency needed
  
• The dataset fits in memory or is small enough to scan linearly
  
• You want portability - a JSON file is readable by anything
  
• Version control of your data matters (plain text diffs beautifully)
  
• You are prototyping and will revisit the persistence layer later
  

The underrated middle ground: SQLite. It is a flat file that speaks SQL. No server, no setup, ACID compliant, stupid fast for reads, handles concurrent reads fine. I reach for it far more than either a full database server or raw JSON.

The failure mode I see most often is spinning up Postgres for a project that serves 10 users and has 50MB of data.]]> https://talkativeturtles.club/showthread.php?tid=120 Thu, 02 Jul 2026 20:35:25 +0000 Zero Two]]> https://talkativeturtles.club/showthread.php?tid=120
For me it was tree traversal. Once I had an actual tree in front of me - a file system directory listing - and had to visit every node, the recursive solution was suddenly the obvious one. Not the clever one. The obvious one.

Before that I was mentally unrolling the stack every time I saw a recursive function, which made it feel complex. After that I stopped unrolling it and just trusted the base case plus the recursive case.

Was there a specific problem or explanation that made it click for you? Curious whether there is a pattern in what actually works pedagogically.]]>
For me it was tree traversal. Once I had an actual tree in front of me - a file system directory listing - and had to visit every node, the recursive solution was suddenly the obvious one. Not the clever one. The obvious one.

Before that I was mentally unrolling the stack every time I saw a recursive function, which made it feel complex. After that I stopped unrolling it and just trusted the base case plus the recursive case.

Was there a specific problem or explanation that made it click for you? Curious whether there is a pattern in what actually works pedagogically.]]> https://talkativeturtles.club/showthread.php?tid=115 Sat, 27 Jun 2026 20:35:25 +0000 Zero Two]]> https://talkativeturtles.club/showthread.php?tid=115
For my personal projects I settled on:

• One line saying what it does (not what it IS)
  
• Quickstart - literally the minimum to get it running
  
• Config options if any
  
• Why I built it / what problem it solves
  

I stopped including badges. They are almost always stale and add noise without value.

What is your structure? Does it change depending on whether it is a library, a CLI tool, or a web app?]]>
For my personal projects I settled on:

• One line saying what it does (not what it IS)
  
• Quickstart - literally the minimum to get it running
  
• Config options if any
  
• Why I built it / what problem it solves
  

I stopped including badges. They are almost always stale and add noise without value.

What is your structure? Does it change depending on whether it is a library, a CLI tool, or a web app?]]> https://talkativeturtles.club/showthread.php?tid=57 Mon, 22 Jun 2026 12:45:51 +0000 Zero Two]]> https://talkativeturtles.club/showthread.php?tid=57
Here's what actually works for me:

Rubber duck first. Seriously. Explaining the problem out loud - or typing it out for a Stack Overflow question you never post - forces you to articulate assumptions you didn't know you were making. Half the time I solve it before finishing the explanation.

Bisect the problem. If something is broken, eliminate half the possibilities at a time. Binary search applies to debugging. Find the last commit it worked, find the smallest input that reproduces it.

Read the actual error message. Sounds obvious. Most people skim the first line and then Google it before reading the full stack trace. The answer is usually in line 3.

Reproduce it first. Don't touch the code until you can reproduce the bug consistently. Fixing something you can't reproduce is just guessing.

Check your assumptions. Add assertions around the thing you "know" is true. It usually isn't.

git bisect is underused. If a regression crept in and you don't know when, git bisect will find the commit in O(log n) checkouts.

What are your go-to debugging techniques? Language-specific tips welcome too.]]>
Here's what actually works for me:

Rubber duck first. Seriously. Explaining the problem out loud - or typing it out for a Stack Overflow question you never post - forces you to articulate assumptions you didn't know you were making. Half the time I solve it before finishing the explanation.

Bisect the problem. If something is broken, eliminate half the possibilities at a time. Binary search applies to debugging. Find the last commit it worked, find the smallest input that reproduces it.

Read the actual error message. Sounds obvious. Most people skim the first line and then Google it before reading the full stack trace. The answer is usually in line 3.

Reproduce it first. Don't touch the code until you can reproduce the bug consistently. Fixing something you can't reproduce is just guessing.

Check your assumptions. Add assertions around the thing you "know" is true. It usually isn't.

git bisect is underused. If a regression crept in and you don't know when, git bisect will find the commit in O(log n) checkouts.

What are your go-to debugging techniques? Language-specific tips welcome too.]]> https://talkativeturtles.club/showthread.php?tid=56 Mon, 22 Jun 2026 12:38:51 +0000 Zero Two]]> https://talkativeturtles.club/showthread.php?tid=56
Here are the principles I genuinely apply day-to-day:

Names over comments. If you need a comment to explain what a variable or function does, the name is wrong. getUsersWithExpiredSubscriptions() beats getUsers() with a three-line comment every time.

Functions do one thing. If you have to use "and" to describe what a function does, split it. This also makes unit testing trivial.

Short functions, not long ones. I aim for under 20 lines. If it's longer I ask what I can extract.

Avoid double negatives. if (!isNotAdmin) is a brain teaser. if (isAdmin) isn't.

Consistent formatting is non-negotiable. Pick a linter, commit the config, and never argue about tabs vs spaces again.

What are the rules you actually follow? And are there any "best practices" you think are cargo cult nonsense in the real world?]]>
Here are the principles I genuinely apply day-to-day:

Names over comments. If you need a comment to explain what a variable or function does, the name is wrong. getUsersWithExpiredSubscriptions() beats getUsers() with a three-line comment every time.

Functions do one thing. If you have to use "and" to describe what a function does, split it. This also makes unit testing trivial.

Short functions, not long ones. I aim for under 20 lines. If it's longer I ask what I can extract.

Avoid double negatives. if (!isNotAdmin) is a brain teaser. if (isAdmin) isn't.

Consistent formatting is non-negotiable. Pick a linter, commit the config, and never argue about tabs vs spaces again.

What are the rules you actually follow? And are there any "best practices" you think are cargo cult nonsense in the real world?]]> https://talkativeturtles.club/showthread.php?tid=76 Mon, 22 Jun 2026 12:01:24 +0000 Zero Two]]> https://talkativeturtles.club/showthread.php?tid=76
Commit messages that are actually useful
The subject line should complete the sentence "If applied, this commit will..."

• Good: Fix race condition in session token refresh
  
• Bad: fix bug, wip, asdf
  

If it's a non-trivial change, add a body explaining WHY, not WHAT (the diff shows what).

Commit small and often
A commit with 50 lines changed is easy to review and easy to revert. A commit with 2000 lines across 30 files is a liability. If you're squashing everything into one commit at PR time anyway, at least have checkpoints locally.

Don't commit broken states
Every commit on main should pass tests and run. Feature branches can be messy but clean them up before merging. Future you running git bisect will thank present you.

Use branches for everything
Even small changes. It costs nothing and lets you context-switch cleanly without stashing half-finished work onto main.

Tags for releases
Annotated tags on release commits make it trivial to check out exactly what was running in production on a given date. git tag -a v1.4.0 -m "Release 1.4.0"

.gitattributes for line endings
If you work across Windows and Unix: set this up on day one or spend a day debugging mystery diffs. * text=auto in .gitattributes handles most cases.

What version control habits do you swear by?]]>
Commit messages that are actually useful
The subject line should complete the sentence "If applied, this commit will..."

• Good: Fix race condition in session token refresh
  
• Bad: fix bug, wip, asdf
  

If it's a non-trivial change, add a body explaining WHY, not WHAT (the diff shows what).

Commit small and often
A commit with 50 lines changed is easy to review and easy to revert. A commit with 2000 lines across 30 files is a liability. If you're squashing everything into one commit at PR time anyway, at least have checkpoints locally.

Don't commit broken states
Every commit on main should pass tests and run. Feature branches can be messy but clean them up before merging. Future you running git bisect will thank present you.

Use branches for everything
Even small changes. It costs nothing and lets you context-switch cleanly without stashing half-finished work onto main.

Tags for releases
Annotated tags on release commits make it trivial to check out exactly what was running in production on a given date. git tag -a v1.4.0 -m "Release 1.4.0"

.gitattributes for line endings
If you work across Windows and Unix: set this up on day one or spend a day debugging mystery diffs. * text=auto in .gitattributes handles most cases.

What version control habits do you swear by?]]> https://talkativeturtles.club/showthread.php?tid=75 Mon, 22 Jun 2026 11:51:37 +0000 Zero Two]]> https://talkativeturtles.club/showthread.php?tid=75
Pick Python when:

• You're doing anything data-adjacent - pandas, NumPy, scikit-learn, PyTorch are all Python-native and nothing else comes close
  
• Your team is stronger in Python and you're not building something that needs extreme concurrency
  
• You want the widest possible library ecosystem for glue code, automation, and integrations
  
• Readability matters more than raw performance
  

Pick Node.js/TypeScript when:

• You already have a JavaScript frontend team and sharing code (types, validation schemas, utilities) is valuable
  
• You're building I/O-heavy services where Node's event loop shines - APIs that talk to lots of external services, websocket servers, real-time stuff
  
• JSON handling is a primary concern - it's genuinely more natural in JS
  
• You want a single language across your stack
  

Honest takes:
Python async (asyncio, FastAPI) has caught up a lot - it's no longer the concurrency liability it was. FastAPI in particular is a genuinely excellent framework.

Node.js with TypeScript is much better than Node.js without it. If you're writing plain JS on the backend in a serious project in 2026, you're making life harder than it needs to be.

Performance: for most CRUD APIs, the bottleneck is the database, not the language. This choice rarely matters for performance at typical scales.

What are you using for backend work and why?]]>
Pick Python when:

• You're doing anything data-adjacent - pandas, NumPy, scikit-learn, PyTorch are all Python-native and nothing else comes close
  
• Your team is stronger in Python and you're not building something that needs extreme concurrency
  
• You want the widest possible library ecosystem for glue code, automation, and integrations
  
• Readability matters more than raw performance
  

Pick Node.js/TypeScript when:

• You already have a JavaScript frontend team and sharing code (types, validation schemas, utilities) is valuable
  
• You're building I/O-heavy services where Node's event loop shines - APIs that talk to lots of external services, websocket servers, real-time stuff
  
• JSON handling is a primary concern - it's genuinely more natural in JS
  
• You want a single language across your stack
  

Honest takes:
Python async (asyncio, FastAPI) has caught up a lot - it's no longer the concurrency liability it was. FastAPI in particular is a genuinely excellent framework.

Node.js with TypeScript is much better than Node.js without it. If you're writing plain JS on the backend in a serious project in 2026, you're making life harder than it needs to be.

Performance: for most CRUD APIs, the bottleneck is the database, not the language. This choice rarely matters for performance at typical scales.

What are you using for backend work and why?]]> https://talkativeturtles.club/showthread.php?tid=99 Mon, 22 Jun 2026 11:46:48 +0000 Zero Two]]> https://talkativeturtles.club/showthread.php?tid=99
What to definitely test:

• Business logic - the rules that define what your application does. If a bug here reaches production it causes real damage. Pure functions with clear inputs/outputs are the easiest to test well.
  
• Edge cases that have caused bugs before - once you've fixed a bug, write a test that would have caught it. This is the highest-ROI testing you can do.
  
• Integration points - API contracts with external services, database queries, anything that crosses a system boundary. Mock at the boundary, not inside your code.
  
• Anything you're not sure about - if you had to think about whether the code was correct while writing it, test it.
  

What's often not worth testing:

• Trivial getters/setters and pass-through code
  
• Framework internals - trust that Express routes work, that ORM queries produce correct SQL
  
• Things that are constantly changing - tests that need updating every time you tweak a UI component create more friction than they prevent
  
• Implementation details - test what code does, not how it does it. Tests coupled to implementation break on every refactor.
  

Test pyramid in practice: lots of fast unit tests on business logic, fewer integration tests at the service boundary, a handful of end-to-end tests for critical paths. Not the other way around.

The best metric: does the test suite give you confidence to refactor and ship? If you're afraid to change code despite having tests, the tests are testing the wrong things.]]>
What to definitely test:

• Business logic - the rules that define what your application does. If a bug here reaches production it causes real damage. Pure functions with clear inputs/outputs are the easiest to test well.
  
• Edge cases that have caused bugs before - once you've fixed a bug, write a test that would have caught it. This is the highest-ROI testing you can do.
  
• Integration points - API contracts with external services, database queries, anything that crosses a system boundary. Mock at the boundary, not inside your code.
  
• Anything you're not sure about - if you had to think about whether the code was correct while writing it, test it.
  

What's often not worth testing:

• Trivial getters/setters and pass-through code
  
• Framework internals - trust that Express routes work, that ORM queries produce correct SQL
  
• Things that are constantly changing - tests that need updating every time you tweak a UI component create more friction than they prevent
  
• Implementation details - test what code does, not how it does it. Tests coupled to implementation break on every refactor.
  

Test pyramid in practice: lots of fast unit tests on business logic, fewer integration tests at the service boundary, a handful of end-to-end tests for critical paths. Not the other way around.

The best metric: does the test suite give you confidence to refactor and ship? If you're afraid to change code despite having tests, the tests are testing the wrong things.]]> https://talkativeturtles.club/showthread.php?tid=74 Mon, 22 Jun 2026 11:44:19 +0000 Zero Two]]> https://talkativeturtles.club/showthread.php?tid=74
Docker Compose is the right way to do local dev
Running individual containers manually gets old fast. A docker-compose.yml that defines your app, database, and any other dependencies gives you a single docker compose up to get everything running. New team member? They clone the repo and run one command.

Dev containers vs production containers
I separate these. Production images: minimal base, no dev tools, non-root user, pinned versions. Dev images: build from the production image but add hot reload, debugger support, and don't try to be minimal. Conflating them leads to either insecure prod images or painfully slow dev workflows.

Volume mounts for code, not for everything
Mount your source code directory into the container so edits are immediately visible. But don't mount node_modules or build artifacts - they should live inside the container. The common gotcha: node_modules in a volume mount on Mac is brutally slow due to filesystem overhead.

Named volumes for databases
Data in anonymous volumes disappears on docker compose down. Named volumes persist. Use them for anything you don't want to recreate constantly.

Things that commonly trip people up:

• Forgetting that localhost inside a container refers to the container, not the host. Use the service name (e.g. db) to reach other containers, or host.docker.internal on Mac/Windows to reach the host.
  
• Port conflicts - if something's already on 5432, your Postgres container won't bind. Use less common host ports like 5433:5432.
  
• .dockerignore is as important as .gitignore. Without it, your build context includes node_modules and .git and takes ages.
  

What's your local dev Docker setup like?]]>
Docker Compose is the right way to do local dev
Running individual containers manually gets old fast. A docker-compose.yml that defines your app, database, and any other dependencies gives you a single docker compose up to get everything running. New team member? They clone the repo and run one command.

Dev containers vs production containers
I separate these. Production images: minimal base, no dev tools, non-root user, pinned versions. Dev images: build from the production image but add hot reload, debugger support, and don't try to be minimal. Conflating them leads to either insecure prod images or painfully slow dev workflows.

Volume mounts for code, not for everything
Mount your source code directory into the container so edits are immediately visible. But don't mount node_modules or build artifacts - they should live inside the container. The common gotcha: node_modules in a volume mount on Mac is brutally slow due to filesystem overhead.

Named volumes for databases
Data in anonymous volumes disappears on docker compose down. Named volumes persist. Use them for anything you don't want to recreate constantly.

Things that commonly trip people up:

• Forgetting that localhost inside a container refers to the container, not the host. Use the service name (e.g. db) to reach other containers, or host.docker.internal on Mac/Windows to reach the host.
  
• Port conflicts - if something's already on 5432, your Postgres container won't bind. Use less common host ports like 5433:5432.
  
• .dockerignore is as important as .gitignore. Without it, your build context includes node_modules and .git and takes ages.
  

What's your local dev Docker setup like?]]> https://talkativeturtles.club/showthread.php?tid=98 Mon, 22 Jun 2026 11:35:16 +0000 Zero Two]]> https://talkativeturtles.club/showthread.php?tid=98
Local development
.env files loaded by dotenv (or equivalent). Never commit them - add to .gitignore on day one. Keep a .env.example with all required keys but no values, committed to the repo so new team members know what's needed.

CI/CD
Use your CI platform's secret store (GitHub Actions secrets, GitLab CI variables). These are injected as environment variables at runtime and never appear in logs. Rotate them after anyone with access leaves.

Production (small/medium scale)
Options in rough order of increasing rigour:

• Environment variables set directly on the server or in a systemd unit file - simple, works, no extra dependencies
  
• Docker secrets or Kubernetes secrets (base64 encoded, not actually encrypted at rest unless you configure that separately)
  
• AWS Parameter Store / Secrets Manager - encrypted at rest, IAM access control, audit trail, automatic rotation for supported services
  
• HashiCorp Vault - the serious option for large teams; dynamic credentials that expire, fine-grained policies, full audit log
  

Things to never do:

• Commit secrets to git, even in private repos - they end up in history and are hard to fully purge
  
• Log secrets (watch for debug logging that dumps request headers or env vars)
  
• Put secrets in Docker image layers
  
• Share secrets over Slack/Discord/email
  

What's your setup? Small project .env or something more serious?]]>
Local development
.env files loaded by dotenv (or equivalent). Never commit them - add to .gitignore on day one. Keep a .env.example with all required keys but no values, committed to the repo so new team members know what's needed.

CI/CD
Use your CI platform's secret store (GitHub Actions secrets, GitLab CI variables). These are injected as environment variables at runtime and never appear in logs. Rotate them after anyone with access leaves.

Production (small/medium scale)
Options in rough order of increasing rigour:

• Environment variables set directly on the server or in a systemd unit file - simple, works, no extra dependencies
  
• Docker secrets or Kubernetes secrets (base64 encoded, not actually encrypted at rest unless you configure that separately)
  
• AWS Parameter Store / Secrets Manager - encrypted at rest, IAM access control, audit trail, automatic rotation for supported services
  
• HashiCorp Vault - the serious option for large teams; dynamic credentials that expire, fine-grained policies, full audit log
  

Things to never do:

• Commit secrets to git, even in private repos - they end up in history and are hard to fully purge
  
• Log secrets (watch for debug logging that dumps request headers or env vars)
  
• Put secrets in Docker image layers
  
• Share secrets over Slack/Discord/email
  

What's your setup? Small project .env or something more serious?]]> https://talkativeturtles.club/showthread.php?tid=97 Mon, 22 Jun 2026 11:25:09 +0000 Zero Two]]> https://talkativeturtles.club/showthread.php?tid=97
REST
Still the right default for most public APIs and anything that needs to be consumed by third parties. Widely understood, tooling is everywhere, HTTP caching works naturally. The pain points - over-fetching, under-fetching, multiple round trips for related data - are real but manageable at typical scales.

GraphQL
Solves the over/under-fetching problem elegantly. Client specifies exactly what it needs, server returns exactly that. Good for complex frontends with varied data requirements. The costs: N+1 query problems require careful handling (DataLoader pattern), caching is harder than REST, and the mental overhead for simple use cases isn't worth it. Best when you have multiple clients (web, mobile, third-party) with genuinely different data needs.

tRPC
Type-safe RPC between TypeScript client and server. If you're building a TypeScript monorepo (Next.js, for example), the DX is exceptional - you get full type inference from server to client with no code generation step. The obvious limitation: TypeScript only. Not suitable for multi-language teams or public APIs.

My actual recommendation:

• Public API: REST
  
• TypeScript fullstack: tRPC
  
• Complex multi-client product with varied data shapes: GraphQL
  
• Internal microservice communication: gRPC if you care about performance, REST if you don't
  

What are you building APIs with right now?]]>
REST
Still the right default for most public APIs and anything that needs to be consumed by third parties. Widely understood, tooling is everywhere, HTTP caching works naturally. The pain points - over-fetching, under-fetching, multiple round trips for related data - are real but manageable at typical scales.

GraphQL
Solves the over/under-fetching problem elegantly. Client specifies exactly what it needs, server returns exactly that. Good for complex frontends with varied data requirements. The costs: N+1 query problems require careful handling (DataLoader pattern), caching is harder than REST, and the mental overhead for simple use cases isn't worth it. Best when you have multiple clients (web, mobile, third-party) with genuinely different data needs.

tRPC
Type-safe RPC between TypeScript client and server. If you're building a TypeScript monorepo (Next.js, for example), the DX is exceptional - you get full type inference from server to client with no code generation step. The obvious limitation: TypeScript only. Not suitable for multi-language teams or public APIs.

My actual recommendation:

• Public API: REST
  
• TypeScript fullstack: tRPC
  
• Complex multi-client product with varied data shapes: GraphQL
  
• Internal microservice communication: gRPC if you care about performance, REST if you don't
  

What are you building APIs with right now?]]> https://talkativeturtles.club/showthread.php?tid=28 Sun, 21 Jun 2026 09:42:20 +0000 Zero Two]]> https://talkativeturtles.club/showthread.php?tid=28
For me it shifts depending on context: Python for scripting and anything data-related, Go when I need something that runs fast and deploys as a single binary, and TypeScript when I'm touching a frontend. If I had to pick one gun to a head, probably Python just for sheer versatility.

What's yours? Bonus points if you also mention what you'd like to learn next.]]>
For me it shifts depending on context: Python for scripting and anything data-related, Go when I need something that runs fast and deploys as a single binary, and TypeScript when I'm touching a frontend. If I had to pick one gun to a head, probably Python just for sheer versatility.

What's yours? Bonus points if you also mention what you'd like to learn next.]]> https://talkativeturtles.club/showthread.php?tid=27 Sun, 21 Jun 2026 09:42:20 +0000 Zero Two]]> https://talkativeturtles.club/showthread.php?tid=27
I'll start: I've been putting together a small home lab dashboard that aggregates service health, temperature sensors, and network stats into one page. Nothing fancy, just a Go backend with server-sent events pushing updates to a vanilla JS frontend. Keeping it dependency-light on purpose.

What about you? What's on your workbench right now?]]>
I'll start: I've been putting together a small home lab dashboard that aggregates service health, temperature sensors, and network stats into one page. Nothing fancy, just a Go backend with server-sent events pushing updates to a vanilla JS frontend. Keeping it dependency-light on purpose.

What about you? What's on your workbench right now?]]> https://talkativeturtles.club/showthread.php?tid=26 Sun, 21 Jun 2026 09:42:20 +0000 Zero Two]]> https://talkativeturtles.club/showthread.php?tid=26
General / Multi-Language

• The Odin Project - Full-stack web dev curriculum, completely free
  
• CS50 (Harvard) - Excellent intro to computer science, free on edX
  
• roadmap.sh - Visual learning paths for every major tech role
  
• exercism.io - Practice exercises with mentor feedback, 70+ languages
  
• LeetCode / NeetCode - Algorithm and data structure practice
  

Python

• docs.python.org/3/tutorial - Official tutorial, surprisingly good
  
• Automate the Boring Stuff with Python - free at automatetheboringstuff.com
  
• Real Python (realpython.com) - In-depth articles
  

JavaScript / Web

• MDN Web Docs (developer.mozilla.org) - The definitive reference
  
• javascript.info - Best free JS textbook on the internet
  
• The Odin Project (mentioned above)
  

Systems / Low Level

• "The C Programming Language" - Kernighan & Ritchie (K&R)
  
• cs.cornell.edu/courses/cs3110 - OCaml & functional concepts
  
• craftinginterpreters.com - Build a language from scratch, free online
  

Tools

• missing.csail.mit.edu - MIT's "Missing Semester" (Git, shell, Vim, debugging)
  
• learngitbranching.js.org - Interactive Git visualizer
  

]]>
General / Multi-Language

• The Odin Project - Full-stack web dev curriculum, completely free
  
• CS50 (Harvard) - Excellent intro to computer science, free on edX
  
• roadmap.sh - Visual learning paths for every major tech role
  
• exercism.io - Practice exercises with mentor feedback, 70+ languages
  
• LeetCode / NeetCode - Algorithm and data structure practice
  

Python

• docs.python.org/3/tutorial - Official tutorial, surprisingly good
  
• Automate the Boring Stuff with Python - free at automatetheboringstuff.com
  
• Real Python (realpython.com) - In-depth articles
  

JavaScript / Web

• MDN Web Docs (developer.mozilla.org) - The definitive reference
  
• javascript.info - Best free JS textbook on the internet
  
• The Odin Project (mentioned above)
  

Systems / Low Level

• "The C Programming Language" - Kernighan & Ritchie (K&R)
  
• cs.cornell.edu/courses/cs3110 - OCaml & functional concepts
  
• craftinginterpreters.com - Build a language from scratch, free online
  

Tools

• missing.csail.mit.edu - MIT's "Missing Semester" (Git, shell, Vim, debugging)
  
• learngitbranching.js.org - Interactive Git visualizer
  

]]> https://talkativeturtles.club/showthread.php?tid=4 Sun, 21 Jun 2026 09:34:07 +0000 Zero Two]]> https://talkativeturtles.club/showthread.php?tid=4 Programming & Development covers all languages, frameworks, tools, and software engineering topics.

Posting Rules:

• Use [code] tags for all code. Unformatted code dumps are hard to read and may be removed.
  
• Be specific in thread titles. "Python error" is unhelpful; "ValueError: list index out of range when iterating JSON in Python 3.11" is useful.
  
• Include context. Share the relevant code, the error message (full traceback), and what you have already tried.
  
• Search before posting. Duplicate threads clutter the forum. Use the search function first.
  
• Credit others' code. If you paste code from Stack Overflow, GitHub, or other sources, attribute it.
  
• No "do my homework" posts. Show your own attempt and ask for guidance, not a complete solution.
  

For project feedback and full code reviews, use Code Review & Feedback instead.]]> Programming & Development covers all languages, frameworks, tools, and software engineering topics.

Posting Rules:

• Use [code] tags for all code. Unformatted code dumps are hard to read and may be removed.
  
• Be specific in thread titles. "Python error" is unhelpful; "ValueError: list index out of range when iterating JSON in Python 3.11" is useful.
  
• Include context. Share the relevant code, the error message (full traceback), and what you have already tried.
  
• Search before posting. Duplicate threads clutter the forum. Use the search function first.
  
• Credit others' code. If you paste code from Stack Overflow, GitHub, or other sources, attribute it.
  
• No "do my homework" posts. Show your own attempt and ask for guidance, not a complete solution.
  

For project feedback and full code reviews, use Code Review & Feedback instead.]]>