All categories/Code and debugging
Code and debugging
Reading code, isolating faults, implementing, testing. Hypotheses before conclusions.
50 entries here · one process per category, checkpoints written per job
- Reading unfamiliar code: map before detailYou inherit a repo with dozens of directories and no idea where to start.
- Error triage: hypotheses before patchesPaste an error and the usual reply is 'try this', and it still fails.
- Add tests: boundaries before casesYou need to test someone else's function and do not know how far to go.
- Code review: by blast radius, not by styleA change lands and you want the parts that can actually break things.
- Production 500: logs to root causeAn endpoint returns 500 intermittently. The log holds one stack trace.
- Unfamiliar repo: entry point and data flowTaking over a 100k-line project and needing to ship a change within three days.
- Profiling: which segment is slowP99 went from 200ms to 2s. Database, serialisation, or a downstream call?
- Memory leak: OOM after a dayThe service hits the memory ceiling daily and restarts. Find the leak.
- Concurrency: intermittent corruptionUnder load, order states occasionally corrupt and logs show nothing.
- Dependency conflict: the package that will not installAfter upgrading one library another reports an incompatible version and the app will not start.
- Major upgrade: what to check before and afterThe framework's next major version is breaking. I need a checklist.
- Code review: only where it will breakA 600-line PR needs a review that is useful, not nitpicking.
- Security review: where does input enterA public endpoint is shipping. Check for injection, authorisation gaps, leaks.
- Refactoring: tests before structureAn 800-line function needs restructuring without changing behaviour.
- Dead code: confirming before deletingThe project has code nobody uses, and deleting it feels risky.
- Flaky tests: passes locally, fails in CIA test passes locally and fails randomly in CI.
- Logging: enough to investigateProduction problems can only be guessed at because the logs say nothing.
- On-call: stop the bleeding or find the causeAn alert fires and the error rate climbs. A decision is needed within ten minutes.
- Rollback: when to go backMetrics worsened after a release, but the link is not certain.
- Canary: ship to one percent firstA new feature ships gradually. Design the batches and what to watch.
- Monitoring: which few numbers matterAfter launch nobody knows what to monitor: either too many alerts or none.
- Packet analysis: what was actually sentThe frontend says it sent the request; the backend says it never arrived.
- Encoding: Chinese turns into question marksChinese text garbles in transit. Find which layer does it.
- Time bugs: zones and daylight savingA scheduled job runs at the wrong time, or timestamps are off by eight hours.
- Slow endpoint: who is slowUsers say the page is slow. Is it the API, rendering, or network?
- Failing unit test: assertion or environmentA batch of unit tests suddenly fails. Code or environment?
- Legacy rewrite: wrap or rebuildA five-year-old system needs work, and the team argues rewrite versus evolve.
- New feature: contract firstAdd an export feature. The requirement is one sentence.
- API design: usable without askingDesigning an API for another team: paths, parameters, error codes.
- Unit tests: what is worth testingCoverage is decent yet production keeps breaking. Re-prioritise the tests.
- Boundary list: enumerate before codingImplementing paginated queries that break on odd data.
- Error handling: callers must be able to decideThe low-level function returns null on failure and callers cannot tell empty from broken.
- Retry policy: how many, how longAn external call times out occasionally, naive retries created duplicate orders.
- Idempotency: the same request twiceA flaky network sent the payment twice. Charge once.
- Caching: when not to cacheAdded a cache and users complain about stale data.
- Migration script: back up firstAdd a column and backfill in production. The script must be reversible.
- Scripts: even one-offs should be re-runnableA batch script failed halfway and I do not want to reprocess.
- Regex: test cases firstWriting a regex to pull fields out of log lines; several attempts failed.
- CLI design: usable without docsA CLI for the team that must work first time.
- Config: managing environment differencesDev, test and production configs differ, and test settings keep shipping to production.
- Concurrency: define the critical sectionConcurrent requests overwrite each other on the same row.
- Structured logging: not string concatenationLogs are string-concatenated everywhere, so filtering by field is impossible.
- Comments: why, not whatComments are scarce and the business rules are opaque.
- Code smells: one kind at a timeThe code is getting messy and every refactor breaks something.
- Integrating an SDK: read the failure pathsIntegrating a payment or push SDK whose samples only show the happy path.
- Choosing a structure: read-write ratio firstA feature needs a data structure and the team disagrees.
- Performance: measure before optimisingSomeone says this code is slow, but nobody measured it.
- Code generation: templates that are easy to changeGenerating many similar modules by hand is too slow.
- Docs drift: stale comments are worse than noneAPI docs lag behind and new callers fail by following them.
- Dependency choice: should we add this libraryA feature needs a new dependency. Is it worth it?
Try another category
- Writing and copy47
- Office and documents52
- Data and analysis50
- Learning and exams47
- Life and decisions53
- Agents and automation48
- Image and video45
- Job hunting30
- Workplace communication39
- Marketing and growth36
- E-commerce36
- Teaching and training36
- Research35
- Translation and localisation28
- Legal and contracts35
- Finance and operations35
- Product and design39
- Health35
- Customer support48
- Hiring and people ops48
- Social and content ops47
- Engineering and manufacturing48
- Security and operations48