The next month, in order

Ordered by what unblocks what

This is not a summary. It is a sequence, and the order matters: each step makes the next one cheaper or more informative. Doing them in a different order mostly wastes the effort.

There are two tracks, because the useful actions differ depending on whether you are changing your own practice or a team’s.

If you write code: week one

Make reversal instant. Before anything else. Commit small, commit constantly, and learn git add -p properly. Every other practice here assumes that throwing away fifteen minutes of work is free. Until that is true, you will defend bad work because abandoning it is expensive.

Turn on the strictest checker your language has. A strict type configuration, the full linter rule set, warnings as errors on new code with a baseline for the old. This is the only reviewer whose capacity scales with the amount of code you produce, and it runs for ever at no cost.

Start predicting before generating. A comment naming the expected signature and branches, then generate, then diff. Two minutes. It catches bugs today, which is why it will still be happening in March.

Week two

Pick one thing you are about to change and write the negative test first. The one where the wrong user asks for the object and gets a 403. Generated suites almost never contain it and it is the most common serious defect in real systems.

Add secret scanning as a pre-commit hook. gitleaks, under a second, free. Then check that your assistant’s exclusion file actually excludes what you think it does.

Take one measurement. Count the distinct ways your codebase does one common thing: parse a date, retry a call, check a permission. Write the number down with the date. This is your concept-count baseline and it will tell you more in six months than any dashboard.

Weeks three and four

Run the honest ledger on yourself. Two weeks, allocation decided by a coin, measured to merged-and-deployed, with a defect column checked at thirty days, and the decision rule written before you look. This beats every published study for deciding how you should work.

Confine anything that runs unattended. A container without your credentials, with an egress allowlist, with approval on the irreversible steps. Check your setup against the trifecta: private data, untrusted content, an outbound channel. If all three are present, remove one.

Write one page of domain knowledge into the repository. The vocabulary, the rules, the exceptions practitioners told you about. It improves everything you generate afterwards and it is the artefact nobody else can produce.

If you lead a team: the same month, different actions

Compute the four delivery numbers by hand. Last thirty deployments, four columns, a spreadsheet, one afternoon. Do not build a dashboard. Most teams discover their lead time is several times what they believed and that nearly all of it is waiting.

Find the queue. If pull requests arrive faster than they are reviewed, adding writing capacity makes delivery worse. Cap work in progress at that stage rather than exhorting people to review faster.

Put verification in the plan with a name and hours. One sentence per significant change: who confirms what, by which method. Unbudgeted work is the work that gets cut, every time.

Write the tool policy on one page. Approved tools, one specific data rule that names a permitted alternative, the author owning every line, review scrutiny tiered by risk, and an explicit ban on measuring individuals by activity counts. One page, or nobody reads it.

Design one apprenticeship task properly. A diagnosis, an incident write-up, a migration: something where deciding what to do is the expensive part. Put it in the sprint with a deadline.

What to do in three months

Re-take the measurements. The four delivery numbers, the concept count, the median diff size, how many people can explain each service. The comparison is the point; absolute numbers mean little because everybody’s definitions differ.

Then change one thing based on what you see, and only one, so that you can tell what it did.

The two habits underneath all of it

If everything above gets dropped, these two carry most of the value.

Before accepting anything, ask what would have to be true for this to be wrong, and what would catch it. That is the whole of module three in one question, and it converts reading into verification.

When something is unsettled, say so. To your team, to your management, in your estimates. The field is full of confident claims resting on nothing, and the fastest way to be useful in it is to be the person who distinguishes what is known from what is being asserted.

Writing code got cheap. Knowing what to build did not, and neither did knowing whether you built it. That is the whole course, and everything else was detail about where to spend the attention you freed up.