Practical Habits for Software Developers

Define success for the task

Replace “work on the feature” with a small observable result: reproduce one defect, add one failing test, document one API response or complete one reviewable slice. A precise finish condition reduces hidden scope and makes it easier to stop, ask for help or continue tomorrow.

Work in small reversible changes

Keep a change narrow enough to understand and review. Separate formatting, dependency updates and behaviour changes when practical. Check the diff before committing, and do not include generated files, secrets or unrelated edits. Small changes do not guarantee correctness, but they make evidence easier to inspect.

Reproduce before fixing

Record the input, environment, observed result and expected result. Reduce the case until the failure is understandable. A fix without a reproducible case may only hide the symptom. Preserve a minimal regression test when the project can support one.

Test at the right boundary

Use focused unit tests for local rules, integration tests for component contracts and a small end-to-end check for critical flows. Also inspect failure paths and invalid inputs. Passing tests are evidence for the cases they cover, not proof that every possible condition works.

Read and explain unfamiliar code

Trace data from its input to its output, write down assumptions and identify who calls the code before editing it. Use documentation and source links for behaviour that may change. If you cannot explain an existing rule, isolate the uncertainty rather than guessing around it.

Ask for review with context

Provide the problem, chosen approach, alternatives considered, tests run and known limits. Point reviewers to the risky lines instead of sending a large diff without guidance. Treat review comments as questions about the change; verify suggestions rather than applying them mechanically.

Keep an engineering log

A short log can record what was planned, what was tested, what was reviewed and which gaps remain. It should not become attendance theatre or a ranking system. Use it to find repeated friction, such as changes that reach review without a failure-path test.

Run a weekly retrospective

Choose one recurring gap and one small experiment for the next week. For example, add a five-minute diff check before every review request. Compare the next log with the previous one, but do not turn a tiny sample into a productivity or career claim. Sustainable learning, breaks and honest limits matter.

Summarize a small plan–test–review practice log

export function summarizePracticeLog(entries) {
  if (!Array.isArray(entries)) throw new TypeError("entries must be an array");
  const dates = new Set();
  const summary = { days: entries.length, planned: 0, tested: 0, reviewed: 0, gaps: [] };

  for (const entry of entries) {
    if (!entry || typeof entry !== "object" || Array.isArray(entry)) {
      throw new TypeError("each entry must be an object");
    }
    if (!/^\d{4}-\d{2}-\d{2}$/.test(entry.date) || dates.has(entry.date)) {
      throw new RangeError("dates must use YYYY-MM-DD and be unique");
    }
    dates.add(entry.date);
    for (const field of ["planned", "tested", "reviewed"]) {
      if (typeof entry[field] !== "boolean") {
        throw new TypeError(`${field} must be boolean`);
      }
      if (entry[field]) summary[field] += 1;
      else summary.gaps.push(`${entry.date}: ${field}`);
    }
  }

  return summary;
}

Expected result

For the three synthetic entries in the companion test: {"days":3,"planned":3,"tested":2,"reviewed":2,"gaps":["2026-10-19: reviewed","2026-10-20: tested"]}. The result describes recorded actions only; it does not score developer ability or predict career outcomes.

Further reading

• Git documentation: reviewing changes with git diff
• Node.js documentation: test runner