Predict whether a variable's bytes land on the stack or the heap from its lifetime, not its type, and trace why heap residency is what costs you at collection time.

Declare `struct Point` as a local and it sits in one place; make it a field of a class and the identical bytes sit somewhere else entirely. The type never changed, only its address did.

Trace what a single `=` copies for a struct versus a class, a whole value or just a shared handle, and predict the aliasing, boxing, and default-equality behavior that follows from that one keyword.

Write `b = a`, then `b.X = 9`. Whether `a.X` reads 9 or stays untouched comes down to one keyword you picked pages earlier, `struct` or `class`, and nothing else about those two lines tells you which way it goes.

Follow the collector from the roots it marks to the survivors it promotes and compacts to new addresses, and predict how allocation rate, not a timer, sets how often it runs.

You write `new Order()` ten thousand times in a loop and never free one of them, yet memory stays flat. Something is walking your objects, deciding which are still in use, and reclaiming the rest behind your back.

Read a constructed generic's type argument back at run time, the move Java's erasure forbids, then connect it to why `List<int>` never boxes and why `Counter<int>` and `Counter<string>` keep separate statics.

Put `int` between the angle brackets of `List<int>` and that choice does not evaporate when you hit Build: you can ask the running program what it was and get `System.Int32` back, something Java cannot do.

Slice a string or array into a zero-copy view instead of allocating a fresh copy, and choose Span<T> for synchronous hot paths but Memory<T> the moment a buffer must survive an await.

Call `text.Substring(16)` inside a parsing loop and every iteration quietly allocates a brand-new string on the heap and copies characters into it, yet there is a way to read those exact same characters with zero new allocations at all.

Separate the `?` that is an erased compiler note on `string` from the `?` that builds a real `Nullable<int>` struct, and read nullable warnings as compile-time intent the build can ship past, not a runtime guarantee.

Append `?` to `int` and the compiler builds a whole new struct, `Nullable<int>`, carrying its own `HasValue` flag. Append the same `?` to `string` and it builds nothing new: the type is identical and only which warnings you get changes.