Tag: engineering Basic
This content is a draft and will not be included in production builds.
37 articles tagged engineering:
- 12-factor and build once, deploy many: config lives in the environment
- 12-factor config: one artifact, many environments, fail fast
- ADRs and technical docs: record why, not just what
- Beyond ADRs: design docs, Diátaxis, runbooks and C4 diagrams
- Blameless postmortems: template, example, and tracking action items to done
- Clean code: common mistakes when writing and refactoring backend code
- Code review anti-patterns and the metrics worth measuring
- Code review: reviewing and being reviewed like a senior
- Common API mistakes: injection, authorization, secrets, retries
- Common code review mistakes: comments, process and bugs that slip through
- Common database and transaction mistakes (PostgreSQL, ORMs)
- Common mistakes in Node.js, NestJS and PostgreSQL backend code
- Common mistakes when logging, debugging, responding to incidents and writing postmortems
- Common mistakes when reading config and env vars in Node.js
- Common mistakes when writing ADRs, runbooks and READMEs
- Common naming mistakes: from code and database to APIs and events
- Communication during response: IC, Ops and Comms roles and status updates
- Config on Kubernetes: Secrets, restarts, rotation, feature flags, drift
- Debugging production incidents and writing blameless postmortems
- Error handling, comments, duplication and dependency direction
- Functions and side effects: guard clauses, no flags, a pure core
- Hypothesis-driven debugging with the Node.js and PostgreSQL toolkit
- Incident response: declare early, mitigate first, root cause later
- Keeping docs alive: docs-as-code, owners and review checklists
- Naming in backend systems: code, database, API and events
- Naming in PostgreSQL: snake_case, 63 bytes and constraint names
- Naming REST APIs, events, Kafka topics, env vars and git branches
- Parse and validate env at startup: report every error, then exit
- PR authors: small PRs, clear descriptions, self-review first
- Pragmatic clean code: write code the next person can change safely
- Reviewers: respond fast, read the design first
- Safe refactoring: characterization tests and commits that separate behavior changes
- Six naming rules and how to apply them in TypeScript and NestJS
- What an ADR is, when to write one, Nygard or MADR
- What review is for, what to look at first, and the lifecycle of a PR
- Writing good ADRs: a full example, lifecycle and superseding
- Writing review comments and handling disagreement