{"course":{"slug":"how-software-changed","title":"How Software Development Changed","url":"https://addaly.com/learn/how-software-changed","level":"intermediate","track":"work"},"lesson":{"slug":"what-to-do-on-monday","title":"The next month, in order","url":"https://addaly.com/learn/how-software-changed/what-to-do-on-monday","position":87,"of":87,"minutes":9,"answer":"Make reversal instant first, add the always-on checkers second, and only then change how you work.","keyIdea":"Make reversal instant first, add the always-on checkers second, and only then change how you work, because every practice worth adopting assumes that throwing away fifteen minutes of work is free and that something mechanical is watching while you read."},"body":{"format":"markdown","text":"## Ordered by what unblocks what\n\nThis 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.\n\nThere are two tracks, because the useful actions differ depending on whether you are changing your own practice or a team's.\n\n## If you write code: week one\n\n**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.\n\n**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.\n\n**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.\n\n## Week two\n\n**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.\n\n**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.\n\n**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.\n\n## Weeks three and four\n\n**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.\n\n**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.\n\n**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.\n\n## If you lead a team: the same month, different actions\n\n**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.\n\n**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.\n\n**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.\n\n**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.\n\n**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.\n\n## What to do in three months\n\nRe-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.\n\nThen change one thing based on what you see, and only one, so that you can tell what it did.\n\n## The two habits underneath all of it\n\nIf everything above gets dropped, these two carry most of the value.\n\n**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.\n\n**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.\n\n> 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."},"check":{"question":"Why does making reversal cheap come before every other practice in this sequence?","options":[{"text":"Version control discipline is the habit most likely to be abandoned, so it needs the most time to establish.","correct":false,"tempting":"Ranks by difficulty of adoption rather than by what the other practices depend on."},{"text":"Frequent commits produce the history needed to compute delivery measures like lead time.","correct":false,"tempting":"A genuine side benefit, but measurement is not what the later practices require in order to work."},{"text":"Small commits make generated changes easier for reviewers to read, which improves defect detection.","correct":false,"tempting":"Diff size does help review, but that is an effect of the practice rather than the reason for its position."},{"text":"Every later practice assumes work can be discarded freely, and costly reversal breeds defending it.","correct":true}]},"prev":{"slug":"the-questions-that-stay-open","title":"What this course could not tell you","url":"https://addaly.com/learn/how-software-changed/the-questions-that-stay-open"},"next":null,"authorship":"Founder and series editor: Dr Mustafa Mun. Written by AI models to a written standard. Exam keys checked blind by a second model: 3,665 of 3,666 agreed. Academic review invited.","review":{"status":"Draft, open for academic review"},"cite":"Addaly (2026) 'The next month, in order', in How Software Development Changed. Edited by M. Mun. Addaly. Available at: https://addaly.com/learn/how-software-changed/what-to-do-on-monday (Accessed: 13 October 2026).","licence":{"name":"CC BY-NC-SA 4.0","url":"https://creativecommons.org/licenses/by-nc-sa/4.0/"},"reader":{"schema":1,"title":"The next month, in order","courseTitle":"How Software Development Changed","module":{"index":9,"slug":"what-did-not-change","title":"What did not change, and what to do now"},"answer":null,"keyIdea":"Make reversal instant first, add the always-on checkers second, and only then change how you work, because every practice worth adopting assumes that throwing away fifteen minutes of work is free and that something mechanical is watching while you read.","hero":{"kind":"plate","image":null,"alt":null,"caption":null},"blocks":[{"t":"h2","id":"ordered-by-what-unblocks-what","runs":[{"text":"Ordered by what unblocks what"}]},{"t":"p","runs":[{"text":"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."}]},{"t":"p","runs":[{"text":"There are two tracks, because the useful actions differ depending on whether you are changing your own practice or a team’s."}]},{"t":"h2","id":"if-you-write-code-week-one","runs":[{"text":"If you write code: week one"}]},{"t":"p","runs":[{"text":"Make reversal instant.","b":true},{"text":" Before anything else. Commit small, commit constantly, and learn "},{"text":"git add -p","code":true},{"text":" 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."}]},{"t":"p","runs":[{"text":"Turn on the strictest checker your language has.","b":true},{"text":" 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."}]},{"t":"p","runs":[{"text":"Start predicting before generating.","b":true},{"text":" 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."}]},{"t":"h2","id":"week-two","runs":[{"text":"Week two"}]},{"t":"p","runs":[{"text":"Pick one thing you are about to change and write the negative test first.","b":true},{"text":" 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."}]},{"t":"p","runs":[{"text":"Add secret scanning as a pre-commit hook.","b":true},{"text":" "},{"text":"gitleaks","code":true},{"text":", under a second, free. Then check that your assistant’s exclusion file actually excludes what you think it does."}]},{"t":"p","runs":[{"text":"Take one measurement.","b":true},{"text":" 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."}]},{"t":"h2","id":"weeks-three-and-four","runs":[{"text":"Weeks three and four"}]},{"t":"p","runs":[{"text":"Run the honest ledger on yourself.","b":true},{"text":" 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 "},{"text":"you","i":true},{"text":" should work."}]},{"t":"p","runs":[{"text":"Confine anything that runs unattended.","b":true},{"text":" 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."}]},{"t":"p","runs":[{"text":"Write one page of domain knowledge into the repository.","b":true},{"text":" 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."}]},{"t":"h2","id":"if-you-lead-a-team-the-same-month-different-actions","runs":[{"text":"If you lead a team: the same month, different actions"}]},{"t":"p","runs":[{"text":"Compute the four delivery numbers by hand.","b":true},{"text":" 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."}]},{"t":"p","runs":[{"text":"Find the queue.","b":true},{"text":" 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."}]},{"t":"p","runs":[{"text":"Put verification in the plan with a name and hours.","b":true},{"text":" One sentence per significant change: who confirms what, by which method. Unbudgeted work is the work that gets cut, every time."}]},{"t":"p","runs":[{"text":"Write the tool policy on one page.","b":true},{"text":" 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."}]},{"t":"p","runs":[{"text":"Design one apprenticeship task properly.","b":true},{"text":" 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."}]},{"t":"h2","id":"what-to-do-in-three-months","runs":[{"text":"What to do in three months"}]},{"t":"p","runs":[{"text":"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."}]},{"t":"p","runs":[{"text":"Then change one thing based on what you see, and only one, so that you can tell what it did."}]},{"t":"h2","id":"the-two-habits-underneath-all-of-it","runs":[{"text":"The two habits underneath all of it"}]},{"t":"p","runs":[{"text":"If everything above gets dropped, these two carry most of the value."}]},{"t":"p","runs":[{"text":"Before accepting anything, ask what would have to be true for this to be wrong, and what would catch it.","b":true},{"text":" That is the whole of module three in one question, and it converts reading into verification."}]},{"t":"p","runs":[{"text":"When something is unsettled, say so.","b":true},{"text":" 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."}]},{"t":"quote","runs":[{"text":"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."}]}],"check":{"question":[{"text":"Why does making reversal cheap come before every other practice in this sequence?"}],"options":[{"text":[{"text":"Version control discipline is the habit most likely to be abandoned, so it needs the most time to establish."}],"correct":false,"tempting":[{"text":"Ranks by difficulty of adoption rather than by what the other practices depend on."}]},{"text":[{"text":"Frequent commits produce the history needed to compute delivery measures like lead time."}],"correct":false,"tempting":[{"text":"A genuine side benefit, but measurement is not what the later practices require in order to work."}]},{"text":[{"text":"Small commits make generated changes easier for reviewers to read, which improves defect detection."}],"correct":false,"tempting":[{"text":"Diff size does help review, but that is an effect of the practice rather than the reason for its position."}]},{"text":[{"text":"Every later practice assumes work can be discarded freely, and costly reversal breeds defending it."}],"correct":true,"tempting":null}],"order":[0,3,1,2],"why":null},"prev":{"slug":"the-questions-that-stay-open","title":"What this course could not tell you","minutes":9},"next":null}}