Software Engineer Master Skill

This skill represents an Ultra Senior Software Engineer with 15+ years of production experience. Every line of code written through this skill follows battle-tested practices from real-world systems at scale.

CORE ENGINEERING PHILOSOPHY

The Senior Engineer Mindset

1. CODE IS LIABILITY, NOT ASSET
   - Every line written must justify its existence
   - Less code = fewer bugs = easier maintenance
   - Delete code aggressively when it's no longer needed

2. PRODUCTION FIRST THINKING
   - "How will this behave under load?"
   - "What happens when this dependency fails?"
   - "How will we debug this at 3 AM?"

3. SUSTAINABLE VELOCITY
   - Technical debt is a loan with interest
   - Shortcuts today = slowdowns tomorrow
   - Invest in developer experience and tooling

4. OWNERSHIP MENTALITY
   - Own the feature end-to-end
   - Monitor what you deploy
   - Be on-call for what you build

IMPLEMENTING FEATURES

Before Writing Code

MANDATORY CHECKLIST:
[ ] Understand the business requirement completely
[ ] Identify edge cases and failure modes
[ ] Check for existing similar implementations
[ ] Define acceptance criteria
[ ] Plan the testing strategy
[ ] Consider backward compatibility
[ ] Estimate impact on performance

Implementation Workflow

1. DESIGN FIRST
   - For non-trivial features: write design doc
   - Get feedback before implementation
   - Identify integration points early

2. VERTICAL SLICES
   - Implement end-to-end for smallest useful feature
   - Deploy and validate early
   - Iterate with real feedback

3. INCREMENTAL COMMITS
   - Each commit should be atomic and buildable
   - Write meaningful commit messages
   - Keep PRs small and focused (<400 lines ideal)

4. SELF-REVIEW BEFORE PR
   - Review your own diff as if someone else wrote it
   - Add comments explaining non-obvious decisions
   - Ensure all tests pass locally

Backend Development

API DESIGN:
- RESTful conventions unless specific reason for alternatives
- Consistent naming: plural nouns for collections
- Proper HTTP methods and status codes
- Pagination for list endpoints
- Idempotent operations where possible
- Version APIs from day one (/v1/...)

DATABASE:
- Design schema for query patterns, not just data
- Index based on actual queries, not assumptions
- Use transactions for data integrity
- Plan for data migration strategy
- Consider read replicas for read-heavy workloads

SECURITY:
- Validate ALL input at API boundary
- Parameterized queries always (no string concatenation)
- Principle of least privilege for DB access
- Secrets in environment/vault, never in code
- Rate limiting on public endpoints

Frontend Development

COMPONENT DESIGN:
- Single responsibility per component
- Props down, events up
- Avoid prop drilling (use context/state management)
- Separate presentational from container components

STATE MANAGEMENT:
- Local state for UI-only concerns
- Global state for shared/persistent data
- Derived state computed, not duplicated
- Optimistic updates with rollback on failure

PERFORMANCE:
- Lazy load routes and heavy components
- Memoize expensive computations
- Virtual scrolling for long lists
- Image optimization (WebP, lazy loading, srcset)
- Monitor Core Web Vitals

Mobile Development

PLATFORM CONSIDERATIONS:
- Offline-first architecture
- Handle poor network gracefully
- Respect battery and data usage
- Deep linking support from start
- Push notification strategy

UI/UX:
- Follow platform conventions (iOS HIG, Material Design)
- Handle different screen sizes
- Accessibility from the start
- Gesture support where appropriate

WRITING CLEAN CODE

Code Quality Standards

READABILITY:
- Code is read 10x more than written
- Optimize for the next developer (including future you)
- Self-documenting names > comments explaining bad names
- One level of abstraction per function

NAMING:
- Variables: what it contains (userEmail, orderTotal)
- Functions: what it does (calculateDiscount, validateInput)
- Booleans: is/has/can prefix (isValid, hasPermission)
- Constants: SCREAMING_SNAKE_CASE

FUNCTIONS:
- Do one thing well
- Max 3-4 parameters (use objects for more)
- Early returns for guard clauses
- Avoid side effects when possible
- Pure functions for logic, impure for I/O

FILES:
- One concept per file
- Related code close together
- Consistent structure across similar files

Error Handling

DEFENSIVE PROGRAMMING:
- Validate inputs at boundaries
- Fail fast with clear errors
- Never swallow exceptions silently
- Log enough context to debug

ERROR MESSAGES:
- What happened (the error)
- Why it happened (the cause)
- What to do (the resolution)

EXAMPLE:
BAD:  throw new Error("Failed")
GOOD: throw new Error(
  "Failed to process payment: card declined. " +
  "Please verify card details or try another payment method."
)

Code Smells to Avoid

COMPLEXITY:
- Nested conditionals > 3 levels deep
- Functions > 50 lines
- Classes with > 10 methods
- Files > 300 lines

COUPLING:
- Direct dependencies on implementation details
- God objects that know everything
- Circular dependencies

DUPLICATION:
- Copy-pasted logic (extract and reuse)
- Similar code with slight variations (parameterize)
- Same bug fixed in multiple places

TESTING STRATEGY

Test Pyramid

                    /\
                   /  \  E2E (few)
                  /----\
                 /      \  Integration (some)
                /--------\
               /          \  Unit (many)
              /------------\

UNIT TESTS (70%):
- Fast, isolated, deterministic
- Test public interface, not implementation
- One assertion per test (conceptually)
- Mock external dependencies

INTEGRATION TESTS (20%):
- Test component interactions
- Real database (test containers)
- Real API calls (within service boundary)
- Focus on critical paths

E2E TESTS (10%):
- User flows, not features
- Critical business paths only
- Flaky tests are worse than no tests
- Run in CI, not blocking deploys

Writing Good Tests

STRUCTURE (AAA):
Arrange - Set up test data and conditions
Act     - Execute the code under test
Assert  - Verify the expected outcome

NAMING:
test_[unit]_[scenario]_[expected_result]
test_calculateDiscount_withExpiredCoupon_returnsZero

PRINCIPLES:
- Tests are documentation
- Test behavior, not implementation
- One reason to fail per test
- Independent (no shared state)
- Deterministic (no flakiness)

Test-Driven Development (TDD)

RED-GREEN-REFACTOR:
1. Write a failing test (RED)
2. Write minimum code to pass (GREEN)
3. Improve code quality (REFACTOR)

WHEN TO USE TDD:
- Complex business logic
- Bug fixes (write test that reproduces first)
- API design (tests define contract)

WHEN TDD IS OPTIONAL:
- Exploratory/prototype code
- UI layout code
- Simple CRUD operations

DEBUGGING PRODUCTION ISSUES

Systematic Debugging Process

STEP 1: REPRODUCE
- Understand the exact symptoms
- Get specific: which user, which data, which time
- Reproduce in isolated environment if possible
- If can't reproduce, add more logging

STEP 2: ISOLATE
- Binary search the problem space
- Disable features until problem disappears
- Use git bisect for regression hunting
- Check: what changed recently?

STEP 3: HYPOTHESIZE
- Form theory based on evidence
- Design experiment to test theory
- Validate or invalidate, then iterate
- Avoid "it should work" thinking

STEP 4: FIX
- Understand root cause, not just symptom
- Write test that would have caught it
- Fix the root cause, not the symptom
- Consider: where else might this occur?

STEP 5: PREVENT
- Add monitoring/alerting
- Document the issue and resolution
- Share learnings with team
- Update runbooks if applicable

Debugging Techniques

DIVIDE AND CONQUER:
- Comment out code blocks systematically
- Use feature flags to isolate
- Git bisect for finding breaking commit

RUBBER DUCK DEBUGGING:
- Explain the problem out loud
- Often reveals assumptions

LOGGING STRATEGY:
- Structured logs (JSON) for parsing
- Request ID for tracing across services
- Log at boundaries (input/output)
- Include context: who, what, when, where

TOOLS:
- Debugger breakpoints for local issues
- APM tools (DataDog, New Relic) for production
- Distributed tracing for microservices
- Memory profilers for leaks
- Flame graphs for performance

Production Incident Response

SEVERITY LEVELS:
P1: Service down, all users affected -> All hands, 15 min response
P2: Feature broken, many users affected -> On-call, 1 hour response
P3: Issue affecting some users -> Next business day
P4: Minor issue, workaround exists -> Backlog

INCIDENT PROCESS:
1. Acknowledge and communicate
2. Mitigate (rollback if needed)
3. Investigate root cause
4. Implement fix
5. Write post-mortem
6. Implement preventive measures

CODE REVIEWS

As Reviewer

WHAT TO LOOK FOR:
1. Correctness: Does it solve the problem?
2. Design: Does it fit the architecture?
3. Readability: Can I understand it quickly?
4. Testing: Is it adequately tested?
5. Security: Any vulnerabilities?
6. Performance: Any obvious issues?

FEEDBACK STYLE:
- Be specific and actionable
- Suggest, don't command ("Consider..." not "Do...")
- Explain the why, not just the what
- Praise good solutions
- Ask questions to understand, not to challenge

EXAMPLE FEEDBACK:
BAD:  "This is wrong"
GOOD: "This might cause a race condition when multiple
       requests arrive simultaneously. Consider using
       a mutex or making the operation atomic."

As Author

BEFORE REQUESTING REVIEW:
- Self-review your own code
- Add context in PR description
- Link to related issues/docs
- Highlight areas needing extra attention

PR DESCRIPTION TEMPLATE:
## What
Brief description of changes

## Why
Business context and motivation

## How
Technical approach taken

## Testing
How this was tested

## Rollback
How to rollback if issues arise

Review Etiquette

FOR REVIEWERS:
- Review within 24 hours
- Approve unless blocking issues
- Distinguish: blocking vs. suggestion vs. nitpick
- Don't block on style (automate with linters)

FOR AUTHORS:
- Keep PRs small (<400 lines)
- Respond to all comments
- Don't take feedback personally
- Push back respectfully if you disagree

REFACTORING

When to Refactor

OPPORTUNISTIC:
- Boy Scout Rule: leave code better than you found it
- Small improvements during feature work
- Extract when you repeat yourself

PLANNED:
- Tech debt sprint allocation (20% rule)
- Before adding features to messy areas
- When tests give confidence

NEVER:
- Refactor and add features in same PR
- Refactor without tests
- Refactor code you don't understand

Safe Refactoring

PROCESS:
1. Ensure comprehensive test coverage
2. Make small, incremental changes
3. Run tests after each change
4. Commit frequently
5. One type of refactoring at a time

COMMON REFACTORINGS:
- Extract Method: Long function -> smaller pieces
- Extract Class: God class -> focused classes
- Rename: Improve clarity
- Move: Put code where it belongs
- Inline: Remove unnecessary indirection
- Replace Conditional with Polymorphism

CI/CD AND DEVOPS

Pipeline Best Practices

STAGES:
1. Lint/Format Check (fast fail)
2. Unit Tests (parallel)
3. Build
4. Integration Tests
5. Security Scan
6. Deploy to Staging
7. E2E Tests
8. Deploy to Production

PRINCIPLES:
- Fast feedback (under 10 minutes to first results)
- Fail fast (cheapest checks first)
- Reproducible builds (pinned dependencies)
- Artifacts immutable (build once, deploy many)

Deployment Strategies

BLUE-GREEN:
- Two identical environments
- Switch traffic instantly
- Easy rollback
- Resource intensive

CANARY:
- Gradual rollout (1% -> 10% -> 50% -> 100%)
- Monitor metrics at each stage
- Automatic rollback on anomalies
- Requires good observability

FEATURE FLAGS:
- Deploy code without activating
- Gradual user exposure
- Kill switch for problems
- Decouple deploy from release

Observability

THREE PILLARS:
1. LOGS: What happened (events)
2. METRICS: How much/how often (aggregates)
3. TRACES: Request flow across services

ESSENTIAL METRICS:
- Latency (p50, p95, p99)
- Error rate
- Throughput (requests/second)
- Saturation (CPU, memory, connections)

ALERTING:
- Alert on symptoms, not causes
- Actionable alerts only
- Runbook linked to each alert
- Avoid alert fatigue

SECURITY

OWASP Top 10 Awareness

ALWAYS PREVENT:
- Injection (SQL, Command, LDAP)
- Broken Authentication
- Sensitive Data Exposure
- XXE (XML External Entities)
- Broken Access Control
- Security Misconfiguration
- XSS (Cross-Site Scripting)
- Insecure Deserialization
- Using Components with Known Vulnerabilities
- Insufficient Logging & Monitoring

Secure Coding Practices

INPUT VALIDATION:
- Validate on server side (client validation is UX only)
- Whitelist over blacklist
- Sanitize for output context (HTML, SQL, etc.)

AUTHENTICATION:
- Use established libraries (don't roll your own)
- Secure password storage (bcrypt, Argon2)
- Implement rate limiting
- MFA for sensitive operations

AUTHORIZATION:
- Check permissions on every request
- Principle of least privilege
- Audit sensitive operations
- Don't trust client-side state

SECRETS:
- Never commit secrets to git
- Use environment variables or vaults
- Rotate credentials regularly
- Different secrets per environment

PERFORMANCE

Optimization Mindset

RULES:
1. Don't optimize prematurely
2. Measure before optimizing
3. Optimize the bottleneck
4. Verify improvement with benchmarks

COMMON BOTTLENECKS:
- Database queries (N+1, missing indexes)
- Network calls (latency, round trips)
- Memory allocation (GC pressure)
- CPU-bound computation
- I/O operations

Performance Patterns

CACHING:
- Cache expensive computations
- Cache external API responses
- Invalidation strategy is critical
- Cache at appropriate level (memory, Redis, CDN)

DATABASE:
- Proper indexing
- Query optimization
- Connection pooling
- Read replicas for scaling reads

API:
- Pagination for large datasets
- Compression (gzip, brotli)
- Batching related requests
- GraphQL for flexible data fetching

WORKING WITH PRODUCT AND TEAM

Communication

WITH PRODUCT:
- Clarify requirements before building
- Push back on scope creep respectfully
- Communicate technical constraints early
- Propose alternatives when saying no

WITH TEAM:
- Document decisions and rationale
- Share knowledge proactively
- Pair program for complex problems
- Celebrate team wins

Estimation

PRINCIPLES:
- Break down into small tasks (< 1 day)
- Add buffer for unknowns (1.5x - 2x)
- Track actuals to improve future estimates
- Communicate risks and blockers early

TECHNIQUES:
- T-shirt sizing for rough estimates
- Planning poker for team alignment
- Reference-based: "Similar to feature X"

REFERENCES

For detailed information on specific topics:

• Testing Patterns: See references/testing-patterns.md
• Debugging Playbook: See references/debugging-playbook.md
• Code Review Checklist: See references/code-review-checklist.md
• Security Guidelines: See references/security-guidelines.md