Lesson overview
This lesson reframes programming as disciplined professional judgement rather than the ability to type working syntax. Learners examine seven rules and turn them into observable habits: predicting complexity, understanding state, evaluating correctness, using existing expertise, judging value, developing others and keeping discovery enjoyable.
Learning objectives
- Distinguish writing code from practising programming as a professional discipline.
- Explain why performance starts with algorithmic reasoning before low-level optimisation.
- Evaluate correctness through automated evidence and human inspection rather than test results alone.
- Justify the use of existing tools, libraries and colleagues as part of efficient professional practice.
- Reflect on career value, team contribution, mentorship and sustainable enjoyment in programming work.
Key vocabulary before you start
Algorithmic complexity
The growth pattern of work or memory as input size changes, before low-level optimisation is considered.
Correctness evidence
A combination of tests, inspection, invariants, specifications and failure analysis used to justify behaviour.
State responsibility
The obligation to understand which values may change, who may change them and what must remain true.
Dependency risk
The failure, maintenance or security exposure created by third-party code and external services.
Professional judgement
A defensible decision that balances correctness, performance, maintainability, cost and team context.
Value delivery
The relationship between technical work and the user, organisational or learning outcome it supports.
Concept map
The seven rules form a progression: first reason about computation, then evaluate behaviour, then use people and tools well, then sustain a worthwhile career.
Estimate timeliness
Be capable of estimating the timeliness of your computation.
Understand computation
Understand what a program is actually doing in a computational sense.
Evaluate correctness
Use automated and human-based approaches to evaluate correctness.
Use existing expertise
Utilise existing program code and expertise.
Realise value
Realise value and worth.
Nurture programmers
Be capable of spotting and nurturing fellow computer programmers.
Enjoy discovery
Ensure that gaining an appropriate solution is a by-product of an enjoyable journey.
Visual model: professional programming judgement loop
Use this loop to connect the seven rules to the evidence a professional programmer should produce before claiming that code is good enough.
Frame the problemState the user need, constraints and definition of acceptable behaviour.
Choose an approachCompare algorithmic, architectural and dependency options before writing code.
Build with evidenceUse small tests, reviewable changes, readable state and clear interfaces.
Evaluate trade-offsCheck performance, correctness, maintainability and operational risk.
Revise responsiblyUse feedback, tools and peer critique to improve the design rather than merely polishing syntax.
Use the loop
Apply the five steps to one rule in the lesson. Produce a short judgement note that names the evidence you would need before accepting the code.
Theory and practice
The lesson begins from a deliberately blunt distinction: someone who can write a program is not automatically a programmer, just as someone who can use scissors is not automatically a hairdresser. Professional programming is judged by appropriateness, reliability and fitness for requirements.
The supplied article argues that theoretical computing science and practical experience must be combined. The theory gives language for limits, complexity and computability; practice gives the discipline to build, inspect and revise actual software.
At Masters level, the point is not to idolise particular books or tools. The point is to ask whether your practice is grounded in deep models of computation as well as evidence from real programs.
Applied task
Choose one program you have written recently. Identify one decision that was driven by theory and one decision that was driven by practical experience.
Performance: time matters
The first rule is about knowing whether a computation is timely. The central question is not merely whether a general-purpose machine can solve a problem, but whether the time taken is known and proportional to the problem size in a way that remains useful.
The lesson uses P and NP as a cultural marker for serious programming: a professional should know whether they are using a deterministic algorithm with explainable bounds, relying on search, or facing a problem whose efficient solution is not known.
The practical warning is clear: algorithmic choice usually matters more than obscure hardware tricks. Optimising an inappropriate algorithm is usually a poor substitute for selecting a better computational approach.
Applied task
For a sorting, searching or scheduling task, state the expected growth behaviour and the largest input size at which your chosen approach remains acceptable.
Correctness: testing is not evaluation
The lesson treats errors as failures of understanding, algorithmic derivation or discipline. That framing is intentionally severe, but it is useful because it refuses to let programmers hide behind output that only appears correct.
Rules 2 and 3 separate program understanding from test success. A program may pass unit tests while still producing impossible state, leaking memory, relying on undefined behaviour, or hiding faults in debug builds.
Automated tests are necessary, but the supplied article insists that human evaluation remains essential. The professional programmer must read code, trace state, use debuggers and understand what the solution is actually computing.
Applied task
Find a case where a passing test would not prove correctness. Describe the missing human evaluation step.
State, third-party code and dependency responsibility
A recurring idea is that state reveals truth. Rather than being hypnotised by execution as a stream of lines, the programmer should ask what state exists, who owns it, when it changes and how those changes can be inspected.
The article extends that duty to third-party code. Depending on a library does not remove responsibility: you still need to understand its contract, assess its behaviour, test the boundary and respond professionally when faults are found.
At Masters level, this becomes a dependency governance problem: trust is not a feeling; it is a claim supported by documentation, tests, source review, maintenance signals, licensing and operational evidence.
Applied task
Select one dependency in a project and list the evidence you have that it is safe, maintained and appropriate.
Efficiency: tools, libraries and colleagues
Rule 4 reframes efficiency as intelligent reuse. Professional programmers exploit existing correct code, reliable tools, debuggers, profilers, version control, specialist hardware interfaces and expert colleagues.
The article rejects the fantasy of the isolated heroic programmer. Software development is collaborative, cumulative and tool-mediated. A programmer who refuses useful tools or ignores colleagues is not preserving craft; they are reducing the team output.
For Masters learners, efficiency should be measured as maintained capability over time: can the team understand, reproduce, test, extend and recover the system?
Applied task
Name one tool or library that genuinely improved your correctness, not just your speed. Explain the evidence.
Career: value, teams and management
Rules 5 and 6 connect programming skill to economic and organisational judgement. The article argues that employers reward contribution, teams reveal competence, and good programmers should be able to identify and nurture other good programmers.
The management section moves beyond writing code. Later-career programming judgement includes hiring, creating productive environments, estimating cost and time, and managing economies of scale in software production.
A Masters course should treat these as technical leadership skills rather than soft extras. Poor management changes architecture, testing, deployment and staffing decisions just as surely as poor code does.
Applied task
Describe how you would tell whether a new team member improves team output without reducing the judgement to raw lines of code.
Enjoyable discovery
Rule 7 is the most human rule: appropriate solutions should emerge from an enjoyable journey of exploration. The supplied lesson argues that students who focus only on achieving an answer often miss the deeper point of programming education.
Introductory tasks such as printing text, sorting values or manipulating lists are not the destination. They are landscapes for exploring syntax, machine behaviour, language design, debugging, state and trade-offs.
At Masters level, enjoyment should not mean comfort or ease. It means curiosity strong enough to sustain careful work, honest failure, repeated revision and deeper questions.
Applied task
Write a short account of one programming problem where the exploration taught more than the final solution.
Applied case lab
Case 1: The fast but wrong service
A team celebrates a microservice that passes all unit tests and responds quickly under demo load. In production, rare inputs produce impossible account states. Apply R2 and R3: what state must be inspected, what test evidence is missing, and what human review must happen?
Case 2: The optimisation distraction
A developer proposes branchless low-level changes to speed up a slow endpoint. Profiling shows the endpoint repeatedly scans a growing list. Apply R1 and R4: how would you redirect the work toward algorithmic choice, data structure choice and existing library support?
Case 3: The AI-assisted senior developer
A programmer uses AI to draft benchmarks, invariants, tests and dependency adapters. Apply all seven rules: which parts can AI accelerate, and which judgements must remain explicitly owned by the human programmer?
Applied task: classify programming decisions
Practise turning broad professional rules into concrete judgement evidence.
Stage 1: classify the issue
A. Match a decision to a rule
Each scenario has a different primary risk.
// Scenario 1: A search feature scans every record on every request.
// Scenario 2: A service passes its tests but violates the written acceptance rule.
// Scenario 3: A team imports a package without checking maintenance or licence status.- Match each scenario to the strongest rule from the lesson.
- Name the evidence you would collect next.
- Explain one trade-off that could make the decision defensible or unacceptable.
Model reasoning
Scenario 1 is mainly performance and algorithmic reasoning. Scenario 2 is correctness beyond tests. Scenario 3 is dependency responsibility. Good answers justify the rule with evidence, not personal preference.
Stage 2: produce judgement evidence
B. Write an acceptance note
A professional judgement should say what was checked and what remains uncertain.
// Decision: keep a simple O(n) scan for the first release.
// Constraint: expected data size is below 500 records for the pilot.
// Risk: growth may make the scan too slow later.- State why the decision may be acceptable now.
- State the metric or trigger that would require redesign.
- Identify what would make this decision irresponsible.
Model reasoning
The O(n) scan can be acceptable for a pilot if response-time evidence is recorded and a growth trigger is agreed. It becomes weak if the team treats the pilot constraint as permanent without monitoring.
Quick checks
1. A program passes every unit test but sometimes returns a value that was never present in the input set. Which rule is most directly being violated?
2. A team tries to optimise a poor algorithm with tiny hardware-level tricks. What is the strongest professional response?
3. Which use of AI best matches the lesson's professional stance?
AI-augmented practice notes
Use these as prompts for disciplined support, not as permission to outsource judgement.
The new division of labour
- Treat AI as a junior dev team: you architect, it drafts.
- Use AI to generate alternatives such as designs, APIs and data structures, then select and refine.
- Keep a traceable workflow: prompt, draft, test, review, integrate.
Turning theory into working code
- Ask AI to derive candidate algorithms with notes on complexity.
- Generate proof sketches or invariants for you to formalise.
- Use AI to integrate theory, code and tests in one notebook.
From tests to evaluation
- Expand unit tests into concurrency and failure scenarios.
- Generate metamorphic tests when exact outputs are tricky.
- Ask AI to highlight coverage gaps and missing edges.
State-first debugging
- Ask AI to propose watch lists and conditional breakpoints.
- Paste traces for AI interpretation, then re-check in the debugger.
- Generate scripted lldb or gdb helpers via AI prompts.
Learning with joy
- Ask AI for three solution paths, implement two and compare.
- Keep a surprises log and have AI format it for review.
- Build a daily loop: one prompt, one test, one reflection.
Assessment tasks
- Write a one-page professional programming manifesto using the seven rules as headings.
- Choose one existing project and audit it against R1, R2 and R3 with specific evidence.
- Select one dependency or tool and justify its use under R4 with evidence about correctness, maintenance and fit.
- Write a judgement note explaining how R7 changes your debugging or practice strategy when a task becomes difficult.
Judgement questions
Which rule do you already practise well?
Give evidence from a real project, not a statement of intent.
Which rule is most likely to fail under deadline pressure?
Describe the pressure, the likely failure mode and the safeguard you will use.
What will you let AI do, and what will you refuse to delegate?
Write this as a personal professional boundary for the course.