---
name: dev
description: |
    Use when working with fundamental software development knowledge — patterns, algorithms, architecture, and craftsmanship principles drawn from canonical published works.
    USE FOR: development fundamentals, pattern selection, architecture decisions, algorithm choice, code quality principles, choosing between architectural styles
    DO NOT USE FOR: specific pattern implementations (use sub-skills: design-patterns, integration-patterns, algorithms, etc.), testing strategy (use testing), infrastructure (use iac)
license: MIT
metadata:
  displayName: "Development Fundamentals"
  author: "Tyler-R-Kendrick"
compatibility: claude, copilot, cursor
references:
  - title: "Refactoring.Guru — Design Patterns"
    url: "https://refactoring.guru/design-patterns"
  - title: "Enterprise Integration Patterns — Hohpe & Woolf"
    url: "https://www.enterpriseintegrationpatterns.com/"
  - title: "Martin Fowler — Software Architecture Guide"
    url: "https://martinfowler.com/architecture/"
---

# Development Fundamentals

## Overview
This skill covers the foundational knowledge every software developer should command — drawn from canonical published works and industry-proven practices. It spans from low-level algorithms through code craftsmanship to system-level architecture.

## Knowledge Map

```
┌─────────────────────────────────────────────────────────┐
│  Architecture                                           │
│  Microservices, Monoliths, DDD, Event-Driven,          │
│  Hexagonal, Well-Architected Frameworks                 │
├─────────────────────────────────────────────────────────┤
│  Frontend                    │  Backend                 │
│  SPA, PWA, Micro-frontends, │  Data Modeling, API      │
│  SSR, Islands Architecture  │  Design, Caching, Auth   │
├─────────────────────────────────────────────────────────┤
│  Integration Patterns        │  Design Patterns         │
│  EIP: Messaging, Routing,   │  GoF: Creational,        │
│  Transformation, Endpoints  │  Structural, Behavioral  │
├─────────────────────────────────────────────────────────┤
│  Algorithms & Data Structures                           │
│  Sorting, Searching, Graphs, DP, Combinatorial          │
├─────────────────────────────────────────────────────────┤
│  Craftsmanship                                          │
│  Clean Code, Clean Architecture, SOLID, 12-Factor,     │
│  Refactoring, Boy Scout Rule                            │
└─────────────────────────────────────────────────────────┘
```

## Canonical Works

| Book | Author | Covers |
|------|--------|--------|
| *Design Patterns* | Gamma, Helm, Johnson, Vlissides (GoF) | 23 object-oriented patterns |
| *Enterprise Integration Patterns* | Hohpe & Woolf | Messaging, routing, transformation |
| *The Art of Computer Programming* | Donald Knuth | Algorithms, data structures, combinatorics |
| *Clean Code* | Robert C. Martin | Naming, functions, formatting, comments |
| *Clean Architecture* | Robert C. Martin | Dependency rule, boundaries, layers |
| *Refactoring* | Martin Fowler | Code smells, refactoring catalog |
| *Domain-Driven Design* | Eric Evans | Bounded contexts, aggregates, ubiquitous language |
| *Building Microservices* | Sam Newman | Service decomposition, communication, deployment |
| *The Pragmatic Programmer* | Hunt & Thomas | Career, approach, tools, pragmatic philosophy |
| *The Twelve-Factor App* | Adam Wiggins (Heroku) | Cloud-native application methodology |
| *Release It!* | Michael Nygard | Stability patterns, capacity, deployment |
| *Fundamentals of Software Architecture* | Richards & Ford | Architecture styles, characteristics, decisions |

## Choosing the Right Pattern Category

| Problem | Look In |
|---------|---------|
| Object creation complexity | Design Patterns → Creational |
| Composing objects / adapting interfaces | Design Patterns → Structural |
| Object communication / state management | Design Patterns → Behavioral |
| Service-to-service messaging | Integration Patterns |
| Algorithm selection / optimization | Algorithms |
| Code readability and maintainability | Craftsmanship |
| System decomposition and boundaries | Architecture |
| Client-side application structure | Frontend |
| Server-side data and API structure | Backend |

## Best Practices
- Learn patterns as a vocabulary, not a checklist — apply them when the problem calls for it, not preemptively.
- Start with the simplest architecture that works (monolith), evolve toward complexity (microservices) only when you have evidence you need it.
- Apply the Boy Scout Rule: leave code better than you found it, every time you touch it.
- Use SOLID principles as guardrails for daily decisions, not just for greenfield design.
- Prefer composition over inheritance — most GoF patterns are variations of this principle.
- Study algorithms for problem-solving intuition, not memorization — know when to reach for a graph algorithm vs. dynamic programming.
- Keep integration patterns in mind whenever systems need to communicate — messaging solves problems that synchronous calls create.