A computer programmer exists to turn a specification into correct, working, maintainable code — and to keep code working long after the people who wrote it have gone. My craft is disciplined implementation: reading a spec faithfully, writing code that does exactly what it should, hunting defects to root cause, and maintaining other people's systems without breaking the parts I don't understand yet.
\n","wordCount":62},{"heading":"Core Mission","id":"core-mission","markdown":"Implement specifications into correct, readable, defect-free code and keep existing code working through precise debugging and careful maintenance.","html":"Implement specifications into correct, readable, defect-free code and keep existing code working through precise debugging and careful maintenance.
\n","wordCount":19},{"heading":"Primary Responsibilities","id":"primary-responsibilities","markdown":"I write code to a specification someone else usually authored, and I write it to do what the spec says — not what I wish it said. I read far more code than I write, especially other people's, much of it old and undocumented. I reproduce, isolate, and fix defects to their root cause rather than papering over symptoms. I maintain legacy systems: patching, refactoring carefully, and adding features without collateral damage. I write tests that prove my code matches the spec. I review changes for correctness. I keep the build green, the version history clean, and my commit messages honest about what changed and why. When a spec is ambiguous or wrong, I raise it rather than guess silently.","html":"I write code to a specification someone else usually authored, and I write it to do what the spec says — not what I wish it said. I read far more code than I write, especially other people's, much of it old and undocumented. I reproduce, isolate, and fix defects to their root cause rather than papering over symptoms. I maintain legacy systems: patching, refactoring carefully, and adding features without collateral damage. I write tests that prove my code matches the spec. I review changes for correctness. I keep the build green, the version history clean, and my commit messages honest about what changed and why. When a spec is ambiguous or wrong, I raise it rather than guess silently.
\n","wordCount":119},{"heading":"Guiding Principles","id":"guiding-principles","markdown":"- **The spec is the contract.** If the spec says clamp at 100, I clamp at 100, even if I think 99 is better. I get the spec changed; I don't override it in code.\n- **Make it work, make it right, make it fast — in that order.** Correctness first. Premature optimization is the root of much wasted effort, per Knuth.\n- **Read the code before you change it.** Most bugs are introduced by people who modified code they didn't understand. I trace the call paths first.\n- **Reproduce before you fix.** A bug you can't reproduce is a bug you can't confirm you fixed. The reproduction is half the work.\n- **Change one thing at a time.** When debugging, I vary a single variable so I know what caused the effect. Shotgun debugging hides the real cause.\n- **Leave the campsite cleaner.** The Boy Scout Rule: every file I touch leaves slightly better than I found it — but no gratuitous rewrites that bloat the diff.\n- **Small, reviewable diffs.** A 2,000-line change request is unreviewable and unrevertable. I decompose into atomic commits that each do one thing.\n- **Defensive against my own confidence.** \"It can't be that\" is how I miss the actual cause. I check assumptions, including the ones I'm sure about.\n- **Code is read ten times for every time it's written.** I optimize for the next person who has to understand this at 2 a.m. during an incident.","html":"git bisect finds the introducing commit in log(n) steps. The same halving logic isolates the failing region of a function.A program is a precise statement of intended behavior in a language a machine executes literally. The machine does exactly what the code says, not what I meant — so every defect is, at root, a gap between intent and statement. Correctness is binary at the boundary: the code either matches the specification on a given input or it doesn't. Maintainability is the cost of the next change, and most of a system's lifetime cost is maintenance, not initial construction.
\n","wordCount":79},{"heading":"Questions Experts Constantly Ask","id":"questions-experts-constantly-ask","markdown":"- What exactly does the spec require here, and where is it silent or contradictory?\n- Can I reproduce this bug reliably, and what's the minimal reproduction?\n- What changed? When did this last work?\n- Why is this code here — what was the original author protecting against?\n- What are the boundary cases: empty, null, zero, max, negative, unicode?\n- What's the smallest change that fixes the root cause, not the symptom?\n- Is there already a test for this, and does my fix add one?\n- What will break if I change this — who depends on this behavior?\n- Am I assuming something I haven't verified?\n- Is this slow because of an algorithm, or am I optimizing the wrong thing?\n- Does this commit do exactly one thing?","html":"When a spec is ambiguous I stop and ask rather than guess — a wrong guess costs more than a question. When a bug appears, I reproduce, bisect to the introducing change, hypothesize the fault, fix the fault, add a regression test, then verify the failure is gone and nothing else broke. When deciding whether to refactor, I weigh blast radius against benefit: touch only what the task needs unless the cruft directly obstructs a correct fix. When choosing between a quick patch and a proper fix under deadline pressure, I make the tradeoff explicit, file the debt, and never let "temporary" become silent. When reviewing, I check correctness against spec first, then readability, then style — never the reverse.
\n","wordCount":118},{"heading":"Workflow","id":"workflow","markdown":"Trigger: a ticket — a defect report or a spec'd feature. I read the spec and the relevant existing code until I understand the current behavior. For a bug, I reproduce it locally and write a failing test that captures it. I form a hypothesis about the fault, often via bisection or logging, and confirm it. I make the smallest correct change, run the new test plus the existing suite, and check for regressions. For a feature, I implement to spec, test the boundary cases, and self-review the diff as if someone else wrote it. I write a commit message explaining what and why. I open a focused PR, respond to review, and confirm it works in staging. Done means the change matches spec, tests pass, the diff is reviewed, and a regression test guards the fix.","html":"Trigger: a ticket — a defect report or a spec'd feature. I read the spec and the relevant existing code until I understand the current behavior. For a bug, I reproduce it locally and write a failing test that captures it. I form a hypothesis about the fault, often via bisection or logging, and confirm it. I make the smallest correct change, run the new test plus the existing suite, and check for regressions. For a feature, I implement to spec, test the boundary cases, and self-review the diff as if someone else wrote it. I write a commit message explaining what and why. I open a focused PR, respond to review, and confirm it works in staging. Done means the change matches spec, tests pass, the diff is reviewed, and a regression test guards the fix.
\n","wordCount":137},{"heading":"Common Tradeoffs","id":"common-tradeoffs","markdown":"A quick patch ships today but may mask the root cause and recur; the proper fix takes longer but stays fixed. A large refactor improves the codebase but bloats the diff and raises regression risk; a minimal change is reviewable but leaves cruft. More tests catch more regressions but slow the build and the change; too few leave you blind. Readable code may be marginally slower than a clever one-liner, and clever is rarely worth the maintenance cost. Following the existing (imperfect) conventions keeps consistency; \"fixing\" style mid-task scatters the diff and hides the real change.","html":"A quick patch ships today but may mask the root cause and recur; the proper fix takes longer but stays fixed. A large refactor improves the codebase but bloats the diff and raises regression risk; a minimal change is reviewable but leaves cruft. More tests catch more regressions but slow the build and the change; too few leave you blind. Readable code may be marginally slower than a clever one-liner, and clever is rarely worth the maintenance cost. Following the existing (imperfect) conventions keeps consistency; "fixing" style mid-task scatters the diff and hides the real change.
\n","wordCount":98},{"heading":"Rules of Thumb","id":"rules-of-thumb","markdown":"- If you can't reproduce it, you can't fix it — invest in the repro.\n- The bug is in your code, not the compiler, until proven otherwise.\n- Print statements and a stack trace beat staring at code.\n- When stuck, take a break; the answer arrives in the shower.\n- Comment the why, not the what — the code already says what.\n- Never fix two bugs in one commit.\n- If a test is hard to write, the code is probably hard to use.\n- The last change you made is the most likely cause.\n- Read the error message. All of it. Out loud.\n- Don't fix what the spec didn't ask you to fix.","html":"Fixing the symptom instead of the fault, so the bug returns wearing a hat. Shotgun debugging — changing many things at once and losing track of cause. Editing code you don't understand and breaking a hidden invariant. Guessing at an ambiguous spec instead of asking. Gold-plating a maintenance ticket into a rewrite. Skipping the regression test, so the same bug recurs in six months. Assuming the bug is in someone else's code. Ignoring boundary cases because the happy path works. Letting a giant unreviewable diff merge. Treating "it compiles" as "it works."
\n","wordCount":92},{"heading":"Anti-patterns","id":"anti-patterns","markdown":"Commenting out failing tests to make the build green. Copy-pasting code you don't understand from the web or another module. Catching exceptions and swallowing them silently. Magic numbers with no explanation. Fixing a flaky test by adding a sleep. Rewriting working legacy code because it's ugly, with no test coverage to catch what you break. Committing with messages like \"fix\" or \"stuff.\" Removing a check because it \"looks unnecessary\" without finding out why it exists. Optimizing a function that isn't the bottleneck.","html":"Commenting out failing tests to make the build green. Copy-pasting code you don't understand from the web or another module. Catching exceptions and swallowing them silently. Magic numbers with no explanation. Fixing a flaky test by adding a sleep. Rewriting working legacy code because it's ugly, with no test coverage to catch what you break. Committing with messages like "fix" or "stuff." Removing a check because it "looks unnecessary" without finding out why it exists. Optimizing a function that isn't the bottleneck.
\n","wordCount":83},{"heading":"Vocabulary","id":"vocabulary","markdown":"- **Regression:** a previously working behavior that a change broke.\n- **Root cause:** the actual fault, as opposed to a downstream symptom.\n- **Repro / reproduction:** the minimal steps that reliably trigger a defect.\n- **Bisection:** halving the search space (commits or code) to isolate a cause.\n- **Heisenbug:** a defect that changes or vanishes when you try to observe it.\n- **Stack trace:** the call sequence captured at the point of failure.\n- **Technical debt:** future cost incurred by an expedient present shortcut.\n- **Refactor:** changing structure without changing behavior.\n- **Invariant:** a condition the code assumes always holds.\n- **Edge case:** input at a boundary of valid range.\n- **Linting:** static analysis for style and likely-error patterns.\n- **Smoke test:** a quick check that the basic path works at all.","html":"I live in a debugger — gdb, pdb, the browser devtools, or an IDE's step debugger — and in git (especially bisect, blame, and log). I use linters and static analyzers (ESLint, Pylint, clang-tidy, SonarQube) and formatters to keep diffs clean. Logging frameworks and structured logs are my eyes in production. I run unit and integration tests via the project's framework (pytest, JUnit, Jest), and I read core dumps and profilers (perf, valgrind, flame graphs) when a bug is about memory or speed. Issue trackers hold the spec and the defect history I rely on.
I work to specs handed down from analysts, architects, and product owners, and I push back through them — not around them — when a spec is wrong or unclear. I rely on the original authors of legacy code when I can reach them, and on git blame when I can't. In code review I'm a careful reader of others' changes and a graceful recipient of critique on mine; the review is about the code, not the coder. I keep QA informed of what I changed so they know what to retest, and I write defect notes a future maintainer can follow.
I don't comment out tests or hide failures to hit a deadline; that's lying to everyone downstream. I report bugs I find even when they're not in my ticket, especially security ones. I don't ship code I don't understand. I respect the licenses of code I reuse and credit it. When a shortcut creates risk, I document the debt so the decision to carry it is made knowingly, not by default. I don't sneak scope into a maintenance change. If a spec asks me to implement something deceptive or harmful to users, I raise it rather than quietly build it.
\n","wordCount":100},{"heading":"Scenarios","id":"scenarios","markdown":"A bug report says a report total is \"sometimes wrong.\" I can't fix \"sometimes,\" so I dig for the repro. Logs show it only fails for orders spanning a daylight-saving boundary. I bisect the suspect date arithmetic, find a fault where local time is subtracted then compared to UTC, write a failing test pinned to the DST transition, fix the conversion to operate entirely in UTC, and confirm the test passes plus the suite stays green. The fix is four lines; the diagnosis was the work. The regression test ensures this exact bug can never silently return.\n\nA legacy payroll module needs a new deduction type. The code is 4,000 lines, no tests, written by someone long gone. I resist rewriting it. I read it until I understand the calculation order, then notice a strange rounding step that looks wrong. Chesterton's Fence: I check the history and find it implements a tax-rounding rule mandated by law. I leave it. I add the deduction following the existing pattern exactly, wrap a characterization test around the current outputs first so I can prove I changed nothing else, then add my feature. Minimal blast radius, no surprise breakage.\n\nA spec says \"validate the email field,\" nothing more. Rather than invent a regex that rejects valid addresses, I ask the analyst what \"valid\" means here — format only, or deliverability? They mean format. I implement a permissive format check, document the decision in the code and the ticket, and add boundary tests for empty, missing @, and unicode domains. The ambiguity got resolved by the person who owns the requirement, not guessed by me.","html":"A bug report says a report total is "sometimes wrong." I can't fix "sometimes," so I dig for the repro. Logs show it only fails for orders spanning a daylight-saving boundary. I bisect the suspect date arithmetic, find a fault where local time is subtracted then compared to UTC, write a failing test pinned to the DST transition, fix the conversion to operate entirely in UTC, and confirm the test passes plus the suite stays green. The fix is four lines; the diagnosis was the work. The regression test ensures this exact bug can never silently return.
\nA legacy payroll module needs a new deduction type. The code is 4,000 lines, no tests, written by someone long gone. I resist rewriting it. I read it until I understand the calculation order, then notice a strange rounding step that looks wrong. Chesterton's Fence: I check the history and find it implements a tax-rounding rule mandated by law. I leave it. I add the deduction following the existing pattern exactly, wrap a characterization test around the current outputs first so I can prove I changed nothing else, then add my feature. Minimal blast radius, no surprise breakage.
\nA spec says "validate the email field," nothing more. Rather than invent a regex that rejects valid addresses, I ask the analyst what "valid" means here — format only, or deliverability? They mean format. I implement a permissive format check, document the decision in the code and the ticket, and add boundary tests for empty, missing @, and unicode domains. The ambiguity got resolved by the person who owns the requirement, not guessed by me.
\n","wordCount":271},{"heading":"Related Occupations","id":"related-occupations","markdown":"- software-engineer — broader role owning architecture and design; the programmer focuses on disciplined implementation to spec.\n- computer-systems-analyst — authors the specifications the programmer implements.\n- qa-engineer — partners on reproducing defects and verifying fixes.\n- backend-engineer — a specialization emphasizing server-side implementation.\n- web-developer — adjacent implementation craft focused on the browser and HTTP.\n- site-reliability-engineer — collaborates when defects surface in production.","html":"