--- title: Where do you go to learn beyond tutorials | daily.dev description: Read GitHub repos, engineering blogs, RFCs, and PRs to learn how real software is designed, debated, and maintained. Explore practical developer news, tutorials, and tools read by millions of developers worldwide. canonical: https://daily.dev/blog/where-to-learn-beyond-tutorials/ og:type: article og:url: https://daily.dev/blog/where-to-learn-beyond-tutorials/ og:title: Where do you go to learn beyond tutorials | daily.dev og:description: Read GitHub repos, engineering blogs, RFCs, and PRs to learn how real software is designed, debated, and maintained. Explore practical developer news, tutorials, and tools read by millions of developers worldwide. og:image: https://media.daily.dev/image/upload/s--tfIQRT7p--/f_auto,q_auto/v1/recruiter-landing/6a9373acf0ae24ed42a3532b_1788051369943_5998ea88fe?_a=BAMAMiB80 og:site_name: daily.dev og:locale: en_US article:published_time: 2026-08-30 article:modified_time: 2026-08-30T01:21:12.472Z article:author: Kevin Nguyen twitter:card: summary_large_image twitter:site: @dailydotdev twitter:creator: @dailydotdev twitter:title: Where do you go to learn beyond tutorials | daily.dev twitter:description: Read GitHub repos, engineering blogs, RFCs, and PRs to learn how real software is designed, debated, and maintained. Explore practical developer news, tutorials, and tools read by millions of developers worldwide. twitter:image: https://media.daily.dev/image/upload/s--tfIQRT7p--/f_auto,q_auto/v1/recruiter-landing/6a9373acf0ae24ed42a3532b_1788051369943_5998ea88fe?_a=BAMAMiB80 --- **If you want to get past [tutorial-only learning](https://daily.dev/blog/stuck-in-tutorial-hell-heres-a-way-to-breakout), go where engineers build, debate, and maintain code in public.** I’d keep it simple: read **GitHub repos**, **engineering blogs**, **RFCs/design docs**, and **PR review threads**. That mix shows code, design choices, limits, mistakes, and team judgment - parts most tutorials skip. Here’s the short version: - **Repositories** show how software is put together. - **Engineering blogs** explain trade-offs, failures, and fixes. - **RFCs and design docs** show why teams picked one path over another. - **Conference talks and PR threads** show how ideas hold up in day-to-day work. A good path is to start with one source from each group: - **GitHub:** React, Django, PostgreSQL, [Rust](https://rust-lang.org/) RFC repo - **Blogs:** Stripe, Uber, Meta, Google Research, dev.to - **RFCs/docs:** HTTP Semantics, HTTP/2, TLS 1.3, Go proposals, Rust RFCs - **Talks/reviews:** GOTO, QCon, InfoQ, merged PRs on GitHub **One detail that matters:** most open source work happens on GitHub, which hosts _more than 100 million developers_ and _hundreds of millions of repositories_. That means you can study not just code, but also issues, tests, and review comments in one place. | Source | What I learn there | Good starting point | | --- | --- | --- | | GitHub repos | Code structure, tests, API shape | React, Django, PostgreSQL | | Engineering blogs | Trade-offs, migrations, failures | Stripe, Uber, Meta | | RFCs/design docs | Reasoning behind decisions | RFC 9110, RFC 9113, RFC 8446 | | Talks + PRs | Team judgment, review habits, system change | GOTO, QCon, GitHub PRs | _The main idea is simple:_ don’t read more tutorials. **Read how software gets built, argued over, and maintained.** ::: @figure {4 Best Resources to Learn Software Engineering Beyond Tutorials} ## 1\. [GitHub](https://github.com) repositories worth reading Some repositories teach more than others. The best ones don't just give you code. They let you see the whole chain: the README, the implementation, and the review threads where people argued through the hard parts. That matters because code on its own can feel like walking into the middle of a conversation. When the docs and discussions are right there too, you can see _why_ something was built that way, not just _what_ ended up in the repo. ### Read production framework code in [React](https://github.com/facebook/react) and [Django](https://github.com/django/django) [React](https://github.com/facebook/react) is a good place to study rendering models, APIs, and long-lived abstractions in a massive frontend ecosystem. Start in `packages/react-reconciler`. Read the tests first. They show edge cases and expected behavior, which makes the source much less opaque. [Django](https://github.com/django/django) is great for learning request flow, ORM structure, and strict backward compatibility. Start in `django/core/handlers/base.py`, then move to `django/db/models` so you can trace how requests move through the framework and how the ORM is put together. If you want deeper systems tradeoffs, shift from frameworks to databases and kernels. ### Study systems thinking in [PostgreSQL](https://github.com/postgres/postgres) and [Linux kernel docs](https://docs.kernel.org/) [PostgreSQL](https://github.com/postgres/postgres) is useful for studying storage, concurrency, and subsystem boundaries. A smart starting point is `src/backend/access/README`. It gives you the storage layer first, which makes the C code easier to follow later. The [Linux kernel docs](https://docs.kernel.org/) show how a large project explains subsystem boundaries. That's a big deal. In codebases this large, clear docs aren't just nice to have. They're part of how people stay oriented. From there, move on to RFCs to see how those same tradeoffs get turned into formal decisions. ### Use proposal repos like [rust-lang/rfcs](https://github.com/rust-lang/rfcs) to connect design to implementation The `text/` directory in [rust-lang/rfcs](https://github.com/rust-lang/rfcs) contains public language design discussions. Each RFC lays out the motivation, the rejected alternatives, and the final decision. Read the RFC before the code. It gives you the design rationale up front, so when you reach the implementation, the choices don't feel like random twists in the road. ## 2\. [Engineering blogs](https://stripe.com/blog/engineering) from real teams Engineering blogs are where you see what happened _behind_ the code: the tradeoffs, the mistakes, and the fixes. That context matters. Code shows what a team built. The blog post usually shows **why** they built it that way. ### Follow [Stripe Engineering](https://stripe.com/blog/engineering) and Uber Engineering for backend architecture and scale [Stripe Engineering](https://stripe.com/blog/engineering) writes about backend systems, payments, API design, and migrations. The useful part is that the posts don’t stop at the polished end result. They walk through constraints, failures, and fixes too. Uber Engineering focuses on real-time systems, infrastructure, and reliability at scale. Its migration and performance posts are especially helpful when you want to see how big systems change over time instead of all at once. ### Use [Meta Engineering](https://engineering.fb.com/) and [Google Research](https://research.google/blog/) for platform and systems depth [Meta Engineering](https://engineering.fb.com/) covers platform reliability, AI infrastructure, and large-scale systems work. It often goes deep into hardware and software co-design, which makes it useful when you want more than a surface-level view. [Google Research](https://research.google/blog/) leans more toward research. It’s a good place to study the reasoning behind new AI approaches, compiler work, and core algorithms, explained by the people who built them. ### Add [dev.to](https://dev.to) as a companion source for practical write-ups [dev.to](https://dev.to) is a good companion source for practical case studies and learning notes. [daily.dev](https://daily.dev) is useful for finding and reading that kind of material, but it should stay a starting point, not the source itself. After that, move to RFCs and design docs for the formal rationale. ## 3\. [RFCs](https://www.rfc-editor.org/) and design documents that explain why systems are designed the way they are Blog posts usually tell you _what_ a team shipped. RFCs and design docs tell you _why_ they made those calls in the first place. That difference matters. If you're trying to understand systems at a deeper level, "what happened" only gets you so far. The useful part is seeing the trade-offs, the constraints, and the problems people were trying to solve. ### Read web standards like [HTTP Semantics](https://www.rfc-editor.org/rfc/rfc9110), [HTTP/2](https://www.rfc-editor.org/rfc/rfc9113), and [TLS 1.3](https://www.rfc-editor.org/rfc/rfc8446) These docs deal with the stuff that shows up once systems meet actual traffic: cache behavior, connection performance, and encrypted traffic that acts a little differently than you expected. [HTTP Semantics (RFC 9110)](https://www.rfc-editor.org/rfc/rfc9110) lays out status codes, headers, and caching rules. If you've ever wondered why a response was cached, skipped, or treated in an odd way by a client or proxy, this is where the answers usually live. [HTTP/2 (RFC 9113)](https://www.rfc-editor.org/rfc/rfc9113) explains multiplexing and binary framing. That becomes important when you're debugging performance at the connection level, where the problem isn't your app code so much as how requests and responses move across the wire. [TLS 1.3 (RFC 8446)](https://www.rfc-editor.org/rfc/rfc8446) is tougher to read, but it's worth the effort. It explains why the handshake was redesigned to cut latency and what security trade-offs came with that change. ### Use [Go design discussions](https://github.com/golang/go/issues) and [Rust RFCs](https://github.com/rust-lang/rfcs) to follow language design debates For language changes, don't stop at the release notes. Read the argument behind the change. Proposal threads show you the trade-offs, rejected ideas, and compatibility constraints behind a new feature or syntax update. That's where the story is. You see what people wanted, what they pushed back on, and what the maintainers had to protect. In other words, you're not just reading the final answer. You're watching how the answer got shaped. ## 4\. [Conference talks](https://www.youtube.com/@GOTO-) and public code review threads If RFCs show the decision on paper, talks and PR threads show what happens when that decision meets the mess of day-to-day work. ### Watch architecture talks from [GOTO Conferences](https://www.youtube.com/@GOTO-), [QCon](https://qconferences.com/), and [InfoQ](https://www.infoq.com/) Pay attention to talks about migrations, postmortems, platform choices, and scaling trade-offs from [GOTO Conferences](https://www.youtube.com/@GOTO-), [QCon](https://qconferences.com/), and [InfoQ](https://www.infoq.com/). These are often the talks where teams stop speaking in theory and start talking about what broke, what changed, and why they picked one path over another. Start with the abstract and slides. That gives you the short version before you spend time on the full talk. ### Read merged pull requests and review threads on [GitHub](https://github.com) to see maintainer judgment Once you've watched a few talks, jump into PR threads for the line-by-line version of that same judgment. This is where you see how maintainers think under pressure: what they push back on, what they let pass, and what they ask to be rewritten. Read merged PRs in mature projects to study things like: - naming debates - test scope - API boundaries - performance trade-offs If you studied [React](https://github.com/facebook/react) or [Django](https://github.com/django/django) earlier, go read their merged PRs too. A good review thread can teach you more than a polished blog post, because you get the back-and-forth instead of just the polished final take. ## Conclusion The best places to learn beyond tutorials are the places where real software gets built, argued over, and maintained in public. Public repositories, engineering blogs, RFCs, and PR threads give you that view. Put them together, and you have a practical path for learning. Start with one source from each category, then dig in. Don’t try to read everything. **One deep read beats a dozen half-finished tutorials.** ## FAQs ### How do I choose my first repo to read? Start with projects built in languages or frameworks you already know. That way, you can spend your energy on patterns, architecture, and coding style instead of getting stuck on new syntax. It also helps to pick repos with active communities, clear docs, and file sizes that won’t bury you. Smaller tools, plugins, or libraries you already use are often a smart place to begin. They’re easier to follow, and you’ll have a better feel for what the code is doing behind the scenes. ### What should I read first in a large codebase? Start with the **README** and any architecture docs so you understand what the codebase is for and how it’s laid out. Then look at the entry points and main config files to see how the app boots up and routes requests. After that, check the test suite and folder structure to find the core modules. If design docs or RFCs are available, read those too. ### How do I turn PRs and RFCs into practice? Treat pull requests and RFCs as **blueprints**, not just docs. Clone the related repo, set up a local dev environment, and walk through the changes line by line. Then reproduce the issue or build the feature yourself in a sandbox branch. That extra hands-on step makes the RFC feel less abstract and a lot more concrete. As you go, compare the RFC’s design choices with the final code. Then read through the PR discussion to see where the team changed course, what they debated, and which tradeoffs shaped the end result. ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/og-image.png?v=a830cdf1","width":1200,"height":630},"sameAs":["https://twitter.com/dailydotdev","https://www.linkedin.com/company/dailydotdev","https://github.com/dailydotdev","https://www.instagram.com/dailydotdev"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","description":"Free, personalized developer news aggregator. Stay on top of software development news, AI coding tools, and web dev - curated daily from trusted sources.","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}},{"@type":"WebPage","@id":"https://daily.dev/blog/where-to-learn-beyond-tutorials/","url":"https://daily.dev/blog/where-to-learn-beyond-tutorials/","name":"Where do you go to learn beyond tutorials | daily.dev","description":"Read GitHub repos, engineering blogs, RFCs, and PRs to learn how real software is designed, debated, and maintained. Explore practical developer news, tutorials, and tools read by millions of developers worldwide.","inLanguage":"en-US","isPartOf":{"@id":"https://daily.dev/#website"},"timeRequired":"PT8M"},{"@type":"Article","@id":"https://daily.dev/blog/where-to-learn-beyond-tutorials/#article","headline":"Where do you go to learn beyond tutorials","url":"https://daily.dev/blog/where-to-learn-beyond-tutorials/","datePublished":"2026-08-30","dateModified":"2026-08-30T01:21:12.472Z","isPartOf":{"@id":"https://daily.dev/#website"},"publisher":{"@id":"https://daily.dev/#organization"},"mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/blog/where-to-learn-beyond-tutorials/"},"description":"Read GitHub repos, engineering blogs, RFCs, and PRs to learn how real software is designed, debated, and maintained. Explore practical developer news, tutorials, and tools read by millions of developers worldwide.","image":{"@type":"ImageObject","url":"https://media.daily.dev/image/upload/s--tfIQRT7p--/f_auto,q_auto/v1/recruiter-landing/6a9373acf0ae24ed42a3532b_1788051369943_5998ea88fe?_a=BAMAMiB80"},"author":{"@type":"Person","name":"Kevin Nguyen"},"timeRequired":"PT8M","potentialAction":{"@type":"ReadAction","target":"https://daily.dev/blog/where-to-learn-beyond-tutorials/"}},{"@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev/"},{"@type":"ListItem","position":2,"name":"Blog","item":"https://daily.dev/blog/"},{"@type":"ListItem","position":3,"name":"Trends","item":"https://daily.dev/categories/trends/"},{"@type":"ListItem","position":4,"name":"Where do you go to learn beyond tutorials","item":"https://daily.dev/blog/where-to-learn-beyond-tutorials/"}]},{"@type":"FAQPage","@context":"https://schema.org","mainEntity":[{"name":"How do I choose my first repo to read?","@type":"Question","acceptedAnswer":{"text":"\u003cp>Start with projects built in languages or frameworks you already know. That way, you can spend your energy on patterns, architecture, and coding style instead of getting stuck on new syntax.\u003c/p> \u003cp>It also helps to pick repos with active communities, clear docs, and file sizes that won’t bury you. Smaller tools, plugins, or libraries you already use are often a smart place to begin. They’re easier to follow, and you’ll have a better feel for what the code is doing behind the scenes.\u003c/p>","@type":"Answer"}},{"name":"What should I read first in a large codebase?","@type":"Question","acceptedAnswer":{"text":"\u003cp>Start with the \u003cstrong>README\u003c/strong> and any architecture docs so you understand what the codebase is for and how it’s laid out. Then look at the entry points and main config files to see how the app boots up and routes requests.\u003c/p> \u003cp>After that, check the test suite and folder structure to find the core modules. If design docs or RFCs are available, read those too.\u003c/p>","@type":"Answer"}},{"name":"How do I turn PRs and RFCs into practice?","@type":"Question","acceptedAnswer":{"text":"\u003cp>Treat pull requests and RFCs as \u003cstrong>blueprints\u003c/strong>, not just docs. Clone the related repo, set up a local dev environment, and walk through the changes line by line.\u003c/p> \u003cp>Then reproduce the issue or build the feature yourself in a sandbox branch. That extra hands-on step makes the RFC feel less abstract and a lot more concrete.\u003c/p> \u003cp>As you go, compare the RFC’s design choices with the final code. Then read through the PR discussion to see where the team changed course, what they debated, and which tradeoffs shaped the end result.\u003c/p>","@type":"Answer"}}]}]} ```