Make changes easy to understand
A small change with a clear purpose is easier to review than a large bundle of unrelated edits. Before writing code, describe the behavior you want in one sentence. Keep that sentence close while you work; it helps you notice when a simple task has grown into a redesign.
Name things for the next reader
Use names that explain the role of a value. A variable called retryDelayMs communicates both purpose and units. Short names can be useful in a small scope, but ambiguous abbreviations force every future reader to reconstruct your intent.
Test the behavior that matters
Focus on the conditions that could break a user workflow. For a search feature, check an empty query, a useful match, and a query with no results. Tests are most valuable when they describe observable behavior and continue to work after an internal refactor.
Leave a useful trail
A good commit message explains why a change exists. Document surprising constraints close to the code they affect. When you discover a limitation, write down a reproducible example so someone else can investigate it without repeating your entire debugging process.
