A course is for reading in order and taking in; a project is for building one thing all the way through. Rather than handing you the requirements and walking off, each one carries the steps, a worked answer and the places people get stuck.
24 in total
Starting from a single orders CSV, you narrow down where sales are falling, working from the whole to the breakdown to one candidate. Using nothing but pandas aggregation, you finish with a one-page report holding a conclusion, its evidence, what the data cannot tell you, and one next step.
You build a pricing table of three plans that holds its shape from a 360px phone up to a wide screen. The aim is to let it wrap because the content is cramped, without writing a single @media rule.
You take a function that does not match its spec and fix it by writing a failing test first rather than diving in. You learn how to pick the boundaries, and what to leave behind once it is fixed.
Writing types protects you at compile time, but a type annotation cannot protect a value that came from outside. You build a type guard that narrows from unknown, rejecting the rows that do not fit while counting them.
An old response overwrites a newer one, a double click sends the order twice, and a failure vanishes without a word. You stop bugs that never raise an error and only ever show up as a screen that is out of step.
Your instinct about what is slow is usually wrong. You print the times before touching anything, and check afterwards that the answer has not changed. You also find one rewrite that turns out to do nothing.
You reproduce, with your own hands, a search box that hands over every member's email address, and a file name that reaches outside the public folder. Then you close both.
Labels, how errors are conveyed, where focus goes. Make it something you can finish with the keyboard alone and it becomes a faster form for sighted people too.
Split on whitespace and take a field by number, and a small change in the shape of a line breaks it. You take fields by their shape instead, and count the lines you could not read.
Releasing blocked tasks does not compile: E0502. Rather than reaching for clone() or Rc, you separate reading from writing. You also find out what Rc<RefCell<T>> actually moves to runtime.
Why can Rust not even express code that another language would happily run with numbers that do not add up? You read what Send is saying, get it compiling, and measure three ways of writing it.
You write split_at_mut yourself. You find out why safe Rust cannot express it, cut the unsafe down to six lines, and leave behind a written account of why it is sound.
Writing async does not help if there is no await to yield at. You watch a heartbeat skip, then fix the difference between gather and TaskGroup and the way cancellation is handled.
You print the peak with tracemalloc and cut it in two directions: making one item smaller (__slots__) and holding fewer at once (generators). The second one is what pays.
Are your rules only enforced inside __init__? Then nothing stops anyone afterwards. You check on every assignment with a descriptor, and work out derived values rather than holding them.
With Box<dyn Error> all you learn is that it failed. You write the possible failures out as an enum, so that adding one makes the compiler stop every caller. Up to where thiserror ends and anyhow begins.
Before the screens, decide which value lives where. Money is a Decimal, the database guards the stock, and the cart holds ids only and looks the price up every time. N+1 is watched by query count.
One item in stock and two customers at the same moment: code written the ordinary way lets both through. You reproduce it on PostgreSQL, fix it, and make the payment notification safe to receive twice.
You fix a search screen that stutters on every keystroke. Before adding any memo, you count how many times each component redraws. Once you count, the first thing you find is not a re-render at all.
You fix a bug where the display simply freezes, with no error and no warning. By counting redraws and watch triggers, you check one place at a time to find where the link between ref/reactive and the screen broke.
You look up a key you know you put in, and get null back. There are four causes, and all of them compile. You measure how entries become unreachable, sort out what a record fixes and what it doesn't, and finish by making the keys immutable.
A goroutine you start with go doesn't end until someone stops it. You count 100 of them lingering after a timeout gives up, find the line where they're stuck, stop them with channels and context, and pin down "no leaks" with a test.
You take a server that stopped because its disk was full, recreate it yourself on a throwaway disk, and bring it back. You trigger, on the spot, all three reasons df and du can disagree.
reset --hard, a deleted branch, a rebase you didn't mean, a dropped stash. You cause all four accidents on purpose and recover from every one, then check with your own hands where the line lies for what truly can't come back.