Senior Software Engineer

Senior Software Engineer

When to Use

• Design services, modules, APIs, or technical approaches across general software stacks
• Write RFCs, technical specs, decomposition plans, or engineering trade-off analysis
• Review PRs for correctness, maintainability, reliability, operability, and test coverage
• Refactor legacy code safely while preserving behavior
• Mentor engineers on implementation quality, estimates, and delivery risks

When NOT to Use

• Build stack-specific full-stack product features end to end → senior-fullstack-developer, fullstack-software-engineer
• Focus only on React/UI architecture and accessibility → senior-frontend-software-engineer
• Choose rollout plans, canaries, or cutover strategy → deployment-strategist
• Provision infrastructure, Kubernetes, or IaC → infrastructure-engineer
• Make enterprise-wide architecture decisions or ADR review gates → senior-system-architecture

Related skills

Core Workflows

1. Technical design (RFC)

1. State problem, constraints, and non-goals 2. List options with trade-offs (at least two alternatives) 3. Recommend one; define interfaces and data contracts 4. Identify risks: scale, failure modes, migration, operability 5. Define success metrics and rollout approach (link deployment-strategist if needed)

Deliverable: short RFC or design doc with diagram (C4 or sequence for critical paths).

See `references/system_design.md` for templates, boundaries, and consistency patterns.

2. Implementation planning

Break work into:

Estimate each slice; call out unknowns and spikes.

See `references/rfc_technical_leadership.md` for estimation and decomposition.

3. Code review (senior bar)

Review order: correctness → design → operability → style.

Leave actionable comments; distinguish blocker vs nit.

See `references/code_review.md` for rubric and comment patterns.

4. Refactoring and quality

When to refactor: before adding feature in tangled module, or when change touches same area third time.

Approach:

1. Add characterization tests around behavior 2. Small commits: extract → rename → move 3. Preserve external behavior; use feature flags for risky swaps 4. Delete dead code in same PR when safe

See `references/refactoring_quality.md` for smells and safe sequences.

5. Reliability and performance

Reliability defaults:

• Timeouts on all outbound calls
• Retries with jitter only for idempotent ops
• Circuit breakers at integration boundaries
• Graceful degradation with clear user messaging

Performance:

1. Measure (profiler, traces, query plans)—no premature optimization 2. Fix N+1, unnecessary allocation, hot loops 3. Cache with explicit TTL and invalidation story

See `references/reliability_patterns.md` for distributed systems primitives.

6. Technical leadership

• Unblock others: pair on hard bugs, clarify design decisions in writing
• Raise risks early; propose phased delivery
• Document decisions in ADR when reversal is costly
• Align with product on scope vs quality trade-offs

See `references/rfc_technical_leadership.md` for ADRs and mentoring prompts.

When to load references

• Service design and RFCs → references/system_design.md
• PR review → references/code_review.md
• Refactoring → references/refactoring_quality.md
• Reliability and performance → references/reliability_patterns.md
• Estimation, ADRs, mentoring → references/rfc_technical_leadership.md

Code review

Table of contents

1. Severity labels 2. Review checklist 3. Comment patterns

Severity labels

Review checklist

• [ ] Behavior matches ticket and handles errors
• [ ] Authz on every mutating path
• [ ] No secrets or PII in logs
• [ ] Tests cover failure paths
• [ ] Public API backward compatible or versioned
• [ ] Migrations safe (expand-contract)
• [ ] Observability: log fields, metrics for new paths

Comment patterns

Good: "This retry can double-charge on timeout; use idempotency key or mark BLOCKER."

Weak: "Consider refactoring this."

Offer alternative when blocking: snippet or link to pattern.

Refactoring and quality

Table of contents

1. Code smells 2. Safe sequence 3. Technical debt

Code smells

Safe sequence

1. Green tests on current behavior 2. Refactor without behavior change 3. Add feature in clean structure 4. Remove old path behind flag

Avoid "refactor while adding feature" unless slice is tiny.

Technical debt

Log debt item: symptom, interest (slow dev, incidents), paydown proposal, owner.

Pay down when touching area or when interest exceeds estimate of fix.

Reliability patterns

Table of contents

1. Outbound calls 2. Idempotency 3. Queues and events 4. Performance

Outbound calls

timeout → retry (idempotent only) → circuit open → fallback or fail fast

Set timeouts < client deadline; propagate cancellation tokens.

Idempotency

• Accept Idempotency-Key on creates
• Store key → result mapping with TTL
• Consumers process messages at-least-once; dedupe by event ID

Queues and events

• Outbox pattern for DB + publish atomicity
• Poison queue after N failures; alert
• Schema versioning for events (additive fields)

Performance

1. Trace slow request end-to-end 2. DB: EXPLAIN, indexes, batch queries 3. App: allocation hotspots, unnecessary serialization 4. Cache only with measured hit rate and invalidation plan

Technical leadership

Table of contents

1. Estimation 2. ADR template 3. Mentoring

Estimation

ADR template

# ADR-NNN: [Title]
## Status: Proposed | Accepted | Superseded
## Context
## Decision
## Consequences

Link ADR from code comments on non-obvious choices.

Mentoring

• Ask questions before prescribing ("what have you tried?")
• Review design before large implementation
• Delegate ownership with clear success criteria
• Debrief incidents blamelessly; one process fix

System design

Table of contents

1. RFC outline 2. Service boundaries 3. Consistency

RFC outline

# [Title]
## Context
## Goals / Non-goals
## Options
### Option A — pros/cons
### Option B — pros/cons
## Decision
## Interfaces (API, events, schema)
## Risks and mitigations
## Rollout
## Open questions

Service boundaries

Prefer modular monolith until proven pain.

Consistency

Document failure: partial completion, duplicate delivery, ordering.