joebew42/study-path: A Curated Reading Path for Software Design

A syllabus for people who already write code

The problem this repository addresses is not a lack of material. It is the ordering problem. Someone who wants to get better at software design is faced with a shelf of books, a decade of conference talks and a scattered set of katas, and no indication of which comes first or which pairs with which. The README opens by calling the project "a curated, open, and ever-evolving learning path focused on practices of software development, principles of software design, and software architecture", and that framing is accurate: the contribution here is selection and sequence, not original content.

The intended reader is a working developer, or a mentor guiding one. The README says the project began when the author mentored an intern in Agile Software Development and wanted "a clear, practical roadmap for learning foundational concepts, like clean code and TDD". That origin explains the shape of the path. It assumes you can already program in some language, because the exercises ask you to repeat examples "with a programming language at your choice". There is no beginner track for people who have not written code yet, and no language-specific track at all.

How the path is structured: sessions, resources and exercises

The repository is close to a single document. The top level holds .gitignore, an assets/ directory and readme.md, and the README itself is the product. Everything is organised into emoji-labelled sections: a Getting Started section, then Session 1 on SOLID and Clean Code, Session 2 on Test-Driven Design, Session 3 on Refactoring, Session 4 on Working with Legacy Code, and further sessions beyond the truncated portion of the README.

Each session opens with a one-line italic summary of its intent and then lists resources: a YouTube talk, a book with named chapters, a paper, a kata repository. The chapter-level granularity is the most useful part of the design. Session 1 does not say "read Clean Code"; it names Chapter 1, Chapter 2, Chapter 3, Chapter 6, Chapter 7 and Chapter 10. That is a deliberate reduction of a 400-page book to roughly a third of its pages, and it tells you the author has actually worked through the material rather than copied a bibliography.

The exercises are the second structural element, and they are thinner. Session 1 asks you to look at the Racing Car Katas and "try to find where the SOLID principles are violated". Session 3 points at the Tennis Refactoring Kata and a Gilded Rose kata and then asks three open questions: what code smells you found, what steps you followed, and what difficulties you faced. There is no answer key. The path supplies the prompt and the repository, and leaves verification to you or to whoever is mentoring you.

The README explicitly refuses to impose an order: "There is no strict order to follow", it says, and lists browsing, diving into topics, or following the path end to end as equally valid. That is honest about how the resource works, but it also means the sequence is a suggestion rather than a curriculum.

Using it: there is nothing to install, only links to open

This project has no package, no CLI and no configuration, so the README gives no installation steps. The way to use it is to clone the repository so you have the assets locally, then work through readme.md in an editor or on the web.

git clone https://github.com/joebew42/study-path.git

After cloning, the top level should show .gitignore, assets/ and readme.md. The assets/ directory holds the resources the path mirrors locally rather than linking out to, including the PDF of the Pomodoro Technique paper referenced in the Getting Started section.

A first real use is to pick one session and turn its chapter list into a checklist you can actually tick off. Session 2, for example, points at Test-Driven Development: By Example and asks you to study Part I, the Money Example, then repeat it in a language of your choice. That is a bounded piece of work with a clear finish line, and the path does not supply the example code, so the exercise is genuinely yours to produce. Session 3 is different: it links a Java implementation of the movie rental example at joebew42/refactoring-day, which you can read alongside Chapter 1 of Refactoring. The README also links the Gilded Rose kata at joebew42/GildedRose and the Racing Car Katas at emilybache/Racing-Car-Katas, so the practical work is spread across several repositories rather than contained in this one.

What the path does not give you

The largest limitation is link rot. Almost every resource in the path is an outbound link, and a meaningful share of them are fragile. The five SOLID principle entries in Session 1 point at Google Docs documents with opaque identifiers, the kind of URL that breaks when an account changes hands or a sharing setting is revoked. The README does not document any link-checking process, and the repository has no CI configuration at the top level, so nothing in the project will warn you when a resource disappears. The README also does not document rollback, deprecation or replacement of a broken resource, because there is no mechanism for it.

The second limitation is that the path has no assessment. The katas come from other repositories, and the questions after them are rhetorical. If you are learning alone, nothing tells you whether your refactoring was good. The README's own framing accepts this: it says "How you use it is entirely up to you." That is a fair description of a reading list and a poor description of a course.

The third is scope drift. The topics list covers agile, clean architecture, clean code, CQRS and event sourcing, domain-driven design, hexagonal architecture, legacy code, microservice architecture, refactoring, SOLID and TDD. That is a broad surface for a single maintainer, and the README's promise that the path is "ever-evolving" is a promise about future work, not a statement about current coverage. If your interest is narrow, say event sourcing specifically, you are relying on whatever that session happens to contain.

Finally, the path is not a substitute for practice on a real codebase. Reading Refactoring and doing the Gilded Rose kata will not teach you what it feels like to refactor a system with users. The path is aware of this in Session 4, which is about working with large, untested codebases, but the material there is still reading and katas.

How it compares with a structured online course

The obvious alternative is a paid video course or a platform like Pluralsight or O'Reilly, where the same topics are covered in a fixed sequence with exercises, quizzes and a progress tracker. The difference in approach is that a course owns its content and this path does not. A course can update a lesson when a technique changes; this path can only swap a link, and the README does not describe how that happens.

A closer alternative is a personal reading list maintained in a notes app or a wiki. The difference there is curation. The session structure, the chapter-level selections and the pairing of a talk with a book and a kata are the work that a private list usually lacks. The path also carries a licence that makes reuse straightforward, which a private list does not.

A third comparison is with the kata repositories themselves, such as the Racing Car Katas or the Tennis Refactoring Kata. Those give you code and tests but no reading order. This path gives you the reading order and points at the katas. Neither replaces the other, and the path is explicit about depending on them.

Maintenance, licence and what to check before you commit

The repository is not archived, and the last push was on 2026-09-01, which is recent enough that the project is being touched. The README states the author is "committed keeping this path up to date" and invites contributions, and there are no published releases, which is normal for a document-only repository.

The licence is stated in the README as CC BY-SA 4.0, with a link to the Creative Commons deed. Two practical implications follow from that identifier. First, the licence covers the study path itself, meaning the selection and arrangement of resources, not the books, videos and katas it links to; those remain under their own terms, and some of the book links point at Goodreads pages rather than free copies. Second, ShareAlike means that if you republish an adapted version of the path, you must license your version under the same terms. That is a constraint on reuse inside a company wiki or a paid course. This is a description of the licence text, not legal advice; if you plan to redistribute the path commercially, read the deed and the legal code yourself.

The upgrade cost is essentially zero in the software sense, because there is no dependency to bump. The real cost is the periodic link audit. Nothing in the repository performs one.

Editorial conclusion

Adopt joebew42/study-path if you are mentoring someone, running a reading group, or want a pre-sorted sequence of books, talks and katas rather than a search engine. Do not adopt it if you need exercises with automated grading, a fixed curriculum with deadlines, or material that is guaranteed to be reachable, because the path is a set of outbound links and several of them point at Google Docs documents and a Leanpub page. Before committing, open the sessions you care about and check that every link you intend to use still resolves; the repository itself contains no build, no test and no dependency manifest, so nothing will tell you when a resource moves.

Frequently asked questions

Official sources

1. Issues
2. joebew42/study-path on GitHub
3. README