GuideIntermediate
Clean Code And Code Review
Learn to write code someone else can read without suffering, and to take part in a review as a professional in both seats: the one proposing — packaging a change, writing the pull request that explains it, and defending your decisions without getting defensive — and the one reviewing — knowing what to look at first, what to comment on and what to let go, and how to say what you see without the other person shutting down. You don't come out with a memorized list of style rules: you come out knowing why each rule exists, when to break it, and how to talk about code with people who don't think like you do. The eight modules revolve around Cardumen, a 14-person startup with a broken review culture — PRs approved in two minutes with an "LGTM", dreaded reviews, people who stopped proposing big changes — and move from readable code to signals that something is rotting, to the change as a unit of communication, to reviewing someone else's code, to the hard conversation, to standards a team actually follows, to reviewing AI-written code, and close with the full loop of a real day of work.
- 64
- lessons
- 8
- modules
- English · Spanish
- available in
- Yes
- certificate
- Free
- access
Outcomes
What you'll be able to do
- Write code someone else can read without suffering: names that need no explanation, functions that fit in your head, comments that explain the why and never the what
- Recognize the signals that code is rotting — duplication, functions doing too much, deep nesting, error handling that hides the error — and name technical debt instead of silently suffering it
- Package a change as a unit of communication: one intent, the right size, with commit messages and a PR description that give context, decision, and risk
- Review someone else's code with an explicit order — intent, design, detail — and label every comment as blocking, suggestion, or opinion
- Review the tests and what isn't in the diff — security, edge cases, data — not just the visible code
- Hold the hard conversation: defend a decision without getting defensive, recognize when the reviewer is right, and disagree and commit when there's no real blocker
- Agree with your team on standards that actually get followed: automate what can be automated, a minimum viable style guide, and review checklists that don't get in the way
- Review AI-written code with a different criterion: verify instead of trust, spot plausible code that doesn't work, and own the authorship of what you ship
- Close the full loop in a single day: propose, receive a tough review, review under time pressure, and diagnose and fix a broken review culture
Before you start
What you need to bring
It's for you if...
- Devs who already code and have worked on shared code, even a little: a repository with someone else, a team, an outside contribution
- Anyone who gets reviews that feel personal, or gives reviews the team dreads
- Teams with a broken review culture: PRs approved in two minutes with an "LGTM", or left unreviewed for days
- Devs starting to receive more AI-generated code than they can thoroughly review, and who need a different criterion for that
Requirements and materials
- Knowing how to code and having worked on shared code, even a little
- Ideally, though not required, having gone through a software development fundamentals guide and a design patterns guide
- The examples use Python with English identifiers, but everything taught applies to any language
Content
The syllabus, module by module
Open any of them to see its lessons.
- 1. Module introduction: who you're actually writing for
- 2. The reader is your code's user
- 3. Names that need no explanation
- 4. Functions that fit in your head
- 5. Comments: the why, never the what
- 6. Consistency beats preference
- 7. Formatting, linters, and the debate you shouldn't have
- 8. Project: make a hostile module readable
- 1. Module introduction: reading code as a symptom
- 2. Duplication: when it matters and when it doesn't
- 3. Functions that do too much
- 4. Parameters, flags, and magic values
- 5. Deep nesting and early returns
- 6. Error handling that hides the error
- 7. Technical debt: naming it instead of suffering it
- 8. Project: write a module's debt inventory
- 1. Module introduction: the PR is a message, not a formality
- 2. One change, one intent
- 3. PR size decides review quality
- 4. Separating refactor from behavior change
- 5. Commit messages that help a year later
- 6. The PR description: context, decision, risk
- 7. Guiding your reviewer through your own change
- 8. Project: package and present a change
- 1. Module introduction: what to look at and in what order
- 2. Before commenting: understand what was asked
- 3. The review's order: intent, design, detail
- 4. What to comment on and what to let go
- 5. Blocking, suggestion, or nitpick: label it
- 6. Reviewing tests, not just code
- 7. Reviewing what you don't see: security, data, edge cases
- 8. Project: review a complete PR
- 1. Module introduction: where teams break
- 2. About the code, never about the person
- 3. Defending a decision without defending yourself
- 4. When the reviewer is right
- 5. When the reviewer is wrong
- 6. Disagreement without deadlock: disagree and commit
- 7. Reviews across experience levels
- 8. Project: respond to a tough review
- 1. Module introduction: why standards get ignored
- 2. Agreeing instead of imposing
- 3. Automate what can be automated
- 4. The minimum viable style guide
- 5. Review checklists that don't get in the way
- 6. The team's definition of "done"
- 7. Exceptions: when to break the standard
- 8. Project: draft your team's agreement
- 1. Module introduction: the reviewer is still human
- 2. What changes (and what doesn't) when the author is a model
- 3. Plausible code that doesn't work
- 4. Verifying instead of trusting
- 5. Volume: when more code arrives than can be reviewed
- 6. Authorship and owning what you ship
- 7. Using AI to review (and its limits)
- 8. Project: review an AI-generated PR
- 1. Module introduction: both chairs in the same day
- 2. From your own code to your proposed change
- 3. Receiving, discussing, and closing
- 4. Reviewing well under time pressure
- 5. What to do when the review never comes
- 6. Measuring whether review culture is healthy
- 7. How a broken review culture gets fixed
- 8. Final project: the full cycle at Cardumen
Common questions
What people usually ask
No limit. It's a free guide: come in whenever you like, as often as you like.
No. Modules run from easier to harder, but you can jump to the one you need. Progress is saved per lesson.
Whatever is needed is listed under “What you need to bring”, above. If nothing is listed there, you can start from zero.
In the Club's WhatsApp group, and every two weeks there's a live with an instructor where questions get worked through.
Yes. It's issued automatically once you finish every lesson, with a verifiable code you can share on LinkedIn.
Start whenever you like
What students say
These reviews are from enrolled students who completed at least 50% of the course. We moderate reviews only on content grounds (spam, offensive language, personal data), never for being critical or negative.
No approved reviews yet.
Be the first to share your experience!