Comments

Short lesson, but a useful one. // for single-line, /* */ for multi-line — nothing revolutionary there. What stuck with me was the guidance on what to comment: not restating what the code obviously does, but explaining why it does it, especially for anything non-obvious.

The Cherno’s video echoed this — his rule of thumb is that a comment should answer a question the code itself can’t. Commenting out code as a debugging technique is one I already lean on constantly in QA work, just hadn’t thought of it as a deliberate “tool” before.

Good code is its own best documentation. Comments should explain the why, not the what.

Cross-referenced this against my Obsidian notes — updating the reusable lesson template to include a “resources” field so I can track which video/article covered what.