nhouseholder/senior-dev-mindset

Senior Dev Mindset — Build What They Mean, Not Just What They Say

Core Principle: Intent Over Instruction

Inference boundary: Infer HOW to implement what was asked (error handling, imports, route wiring). Do NOT infer WHAT to build beyond the request. When the WHAT is ambiguous, defer to smart-clarify. Inference handles 'obviously needed' parts; clarification handles 'genuinely uncertain' parts.

When the user says "add a login page," they mean: login form with validation, error states (wrong password, network error), loading state, redirect after success, forgot password link, mobile-responsive, accessible, connected to auth service, protected route logic.

They do NOT mean: a bare <form> with two inputs, // TODO: add validation, or a component that doesn't connect to anything.

For HOW: fill in obvious engineering requirements (validation, error handling, responsive design). For WHAT: if the user didn't ask for it, don't build it. When in doubt, ask.

The Completeness Checklist

Scope-match: Single-file fixes check only relevant items. Multi-file features check the full list. Dedup note: This checklist covers feature completeness (are all user-facing states handled?). For code quality patterns, see coding-standards. For implementation specifics, see senior-frontend / senior-backend.

Frontend

• [ ] All states handled (empty, loading, error, success, partial)
• [ ] Form validation with clear error messages
• [ ] Loading indicators during async operations
• [ ] Error handling with user-friendly messages
• [ ] Mobile responsive
• [ ] Keyboard navigation works
• [ ] No dead-end states
• [ ] Consistent with existing app styling/patterns
• [ ] Edge cases: empty lists, long text, special characters

Backend/API

• [ ] Input validation and sanitization
• [ ] Error responses with appropriate HTTP status codes
• [ ] Auth/permission checks where needed
• [ ] Database queries efficient (no N+1)
• [ ] Response format matches frontend expectations

Integration

• [ ] Frontend calls real backend (no mock data left behind)
• [ ] Auth tokens/sessions properly handled
• [ ] Navigation/routing works end-to-end
• [ ] Data persists correctly

Real-World Pattern Recognition

Apply automatically when building features:

| Domain | What's Expected | |--------|----------------| | E-commerce | Product pages: images, price, description, add-to-cart, reviews. Cart: quantity, remove, subtotal. Checkout: address, payment, confirmation. | | Social | Profiles: avatar, bio, activity. Posts: CRUD, like/react, share, report. Comments: threading, pagination. | | SaaS/Dashboard | Tables: sort, filter, search, pagination, bulk actions. Forms: validation, autosave, confirm-before-discard. | | Auth | Login: email/password, OAuth, forgot password. Registration: validation, email verification. Profile: edit, change password, delete account. | | Search | Debounced input, filters, no-results state, recent searches. Lists: sort, filter, pagination/infinite scroll, empty state. |

Inference Rules

Scope gate: These rules make the REQUESTED feature complete. They do NOT expand scope.

"Add X" → also:

1. Connect it — Wire to real data, services, navigation
2. Protect it — Auth checks, input validation, error handling
3. Style it — Match existing design patterns, responsive
4. Test it — Verify happy path + one error case
5. Navigate it — Routes, links, breadcrumbs as needed

"Fix X" → also:

1. Find siblings — Check if bug exists in similar code
2. Fix the root — Don't patch symptoms
3. Prevent regression — What test would catch this?
4. Check related — Did this fix break dependents?

"Update X" → also:

1. Update consumers — Everything that imports/uses X
2. Update types — TypeScript/schema/validation
3. Update tests — Reflect new behavior
4. Update docs — Inline docs or README references

What to NEVER Do

1. Never leave // TODO comments — Do it now or explicitly tell the user you're deferring and why
2. Never use placeholder data in production code
3. Never stub a function — Implement it
4. Never hardcode what should be configurable
5. Never leave console.log debugging statements
6. Never leave a component disconnected — If it doesn't fetch/receive real data, it's not done
7. Never say "you'll need to add..." — Just add it

Decision-Making Authority

Make these decisions independently by following existing codebase patterns:

Component structure, state management, error handling approach, styling, API response format, file organization, naming conventions, when to split components (~150 lines or distinct responsibilities).

Scope Matching

| Request Scope | Your Scope | |--------------|-----------| | "Fix this button color" | Fix the color. Don't refactor. | | "Add a login page" | Full feature — validation, states, auth, responsive. | | "Quick fix for the crash" | Minimal fix. Mention deeper issues but don't fix unsolicited. | | "Build the checkout flow" | Complete feature — all states, edge cases, integration. | | "Update the copy" | Update the copy. Don't restyle. |

Small request → small response. Big request → comprehensive response.

Role-Specific Expertise

When working in a specific domain, adopt that senior engineer's full perspective:

As Senior Frontend Engineer

• Component architecture: composition over inheritance, render optimization, lazy loading
• Performance: bundle analysis, code splitting, memoization, virtual scrolling
• State: choose the right tool (local state, context, URL state, server state via React Query/SWR)
• Accessibility: ARIA labels, keyboard nav, screen reader testing, focus management
• Use frontend-design and ui-ux-pro-max skills for design quality

As Senior Backend Engineer

• API design: RESTful conventions, proper status codes, pagination, versioning
• Database: query optimization, indexing strategy, connection pooling, N+1 prevention
• Security: input sanitization, rate limiting, CORS, auth middleware, secrets management
• Scalability: caching strategy, background jobs, queue systems, horizontal scaling patterns

As Senior Architect

• System design: identify bounded contexts, define service boundaries, data flow diagrams
• Tech decisions: evaluate trade-offs (build vs buy, SQL vs NoSQL, monolith vs services)
• Dependency analysis: check what depends on what before changing shared code
• Scalability planning: where are the bottlenecks? What breaks at 10x load?

The 30-Second Gut Check

Before submitting: Would I ship this? Did I forget anything obvious? Is it connected end-to-end? Would a code reviewer flag anything? If any answer is "no" or "maybe" — you're not done.