1. Static Code Analysis Tools
1.1. Find Bugs Report
1.2. Cyclomatic Complexity
2. Relational vs Hierarchical Thinking
3. easy to use/learn
3.1. simple
3.2. functional completeness
3.3. overall coherence
3.3.1. Evolutionary Design
4. Persistent
5. Collaboration
5.1. Sufficient communication
5.2. Frequent
6. Self Improvement
6.1. intentional practice
6.1.1. book discussions
6.1.2. online communities
6.1.3. Reading
6.1.4. Code Kata
6.1.5. local user groups
6.1.6. open source projects
6.1.7. conferences
6.2. retroflection
6.2.1. Daily self reflection
6.2.2. Self Management
6.2.3. Common Pitfalls
6.2.4. Self Awareness
6.3. balance
6.3.1. Keeping Motivated
6.3.1.1. autonomy
6.3.1.2. mastery
6.3.1.3. purpose
6.3.2. work/ health/ friends
6.3.3. social captial (networking)
6.3.4. slack
7. Product
7.1. vision
7.1.1. clear problem domain
7.1.1.1. Visualization and Presentation Techniques
7.1.1.2. Wireframe/Paper Prototyping
7.1.1.3. working directly with whole team
7.1.2. explicit goals
7.1.2.1. managed scope
7.1.3. measured progress
7.1.3.1. success metrics
7.1.3.2. split testing
7.2. solves real/valuable problems
8. Confidence
8.1. Definition of Done
8.1.1. working software
8.1.2. validated learning
8.1.3. High Quality
8.1.3.1. Zero Bugs
8.2. Visibility
8.2.1. Storyboard
8.2.2. Informative Build
8.2.3. Burn-up/down charts
8.2.4. transparency
8.2.4.1. open decision making
8.2.4.2. continuous improvement
8.2.4.2.1. Plan Do Check Act
8.2.5. Reliable Cadence
8.2.6. Using Version Control
8.2.6.1. Distributed
8.2.6.2. Optimistic vs Pessimistic Locking
8.2.6.3. branching
8.2.7. Continuous Integration (CI)
8.2.7.1. CI Tools
8.2.7.2. automated deployment
8.2.7.3. automated build
8.2.7.3.1. ten-minute build
8.2.7.4. automated deployment
8.2.7.5. frequent check-in
9. Database Refactoring
9.1. testing databases
9.2. abstracting away from dbms
10. customer satisfaction
10.1. split testing
11. Bugs
12. Performance / Response Time
13. Non-functional requirements
13.1. Load / Capacity
13.2. Robustness / Long Duration
14. Critiquing the Product
14.1. Test Harness for Legacy Code
14.1.1. test seams
14.1.2. dependency breaking
14.1.3. sprouts and strangling
15. Domain-Driven Design
16. JDUF-just enough design up front
17. Code Smells
17.1. Don't Repeat Yourself
17.2. Law of Demeter (Tell Don't Ask)
17.3. Metrics
17.3.1. Test Coverage
17.3.2. Lines of Code (sphags)
18. Business Value
18.1. validating
18.1.1. Release Management
18.1.1.1. Flow
18.1.1.2. Stories
18.1.1.2.1. Story Estimation
18.1.1.2.2. Story Splitting
18.1.1.2.3. Story Writing
18.1.1.3. Delivering In Small Slices
18.1.1.3.1. Incremental
18.1.1.3.2. Iterative
18.1.1.4. Product Backlog
18.1.1.4.1. Sprint Backlog
18.1.1.5. frequent delivery
18.1.1.6. Basic Throughput Accounting
18.1.1.6.1. Cadence
18.1.1.6.2. Limiting Work in Progress
18.1.1.6.3. Optimize the whole
18.1.1.6.4. Value Stream Mapping
18.1.1.7. Kanban
18.1.2. Time management
18.1.2.1. Pomodoro
18.1.2.2. Getting Things Done
18.1.2.3. Timeboxes
18.2. avoiding waste (muda)
18.2.1. Extra features
18.2.2. Heavy specs
18.2.3. Handoffs
18.2.4. Waiting
18.2.5. Multi-step analyze-dev-test-verify...
18.2.6. Re-creating knowledge
19. Supportive Culture
19.1. Conflict management
19.1.1. diagnosis
19.1.1.1. dissapointment
19.1.1.2. friction
19.1.1.3. disconnect
19.1.1.4. disagreement
19.1.2. productive discussion
19.1.2.1. Consent-based decision making
19.1.2.2. Knowledge vs Information
19.1.2.3. Facilitation
19.2. respect
19.2.1. Craftsmanship Manifesto
19.2.2. Declaration of Interdependence
19.2.3. Agile Manifesto
19.2.4. growing trust
19.2.5. individuals and interactions over processes and tools
19.2.6. give teams what they need & trust them to get the job done
19.3. commitment
19.3.1. Nudging for Improvement
19.3.1.1. Jiggling (Change Agent)
19.3.2. help
19.3.2.1. Knowing when you're blocked
19.3.2.2. Ask first, conclude later
19.3.2.3. Active Listening
19.3.2.4. Mentoring
19.3.2.5. Helping
19.3.3. Patrick Lencioni’s Five Dysfunctions of a team
19.3.3.1. Absence of Trust
19.3.3.2. Fear of Conflict
19.3.3.3. Lack of Commitment
19.3.3.4. Avoidance of Accountability
19.3.3.5. Inattention to Results
19.3.4. whole team attitude
19.3.4.1. Cross-functional teams
19.3.4.2. generalizing specialists
19.3.4.3. product focus
19.3.4.4. responsibility
19.3.4.5. autonomy
19.3.5. permanent team attitude
19.3.5.1. improves productivity
19.3.5.2. enhances commitment
19.3.5.3. shared history
19.4. Space to learn
19.4.1. slack
19.4.2. accepting failure
19.4.3. sustainable pace
19.4.4. risk taking
20. Technical Excellence
20.1. Simple Design
20.1.1. KISS - Keep it simple, stupid!
20.1.1.1. Architecture--simplest thing that could possibly work
20.1.1.2. One level of abstraction
20.1.2. Design Patterns
20.1.2.1. Evolutionary Iterative Development
20.1.2.2. Emergent Design
20.1.2.2.1. Refactoring to Framework
20.1.2.2.2. Avoid Speculative Generality
20.1.2.3. MVP / MVC Patterns
20.1.2.4. Separation of Concerns
20.1.2.5. FCoI - Favour Composition over Inheritance
20.1.2.6. Modeling
20.1.2.6.1. CRC (class responsibility collaborator) cards
20.1.2.6.2. UML diagrams
20.1.2.6.3. whiteboard discussions
20.1.3. Craftsmanship
20.1.3.1. Clean Code
20.1.3.2. Boy Scout Rule
20.1.3.3. Source Code Conventions
20.2. Refactoring
20.2.1. SOLID
20.2.1.1. Single Responsibility Principle
20.2.1.1.1. Coding by Intention
20.2.1.2. Open Closed Principle
20.2.1.3. Liskov Substitution Principle
20.2.1.4. Interface Segregation Principle
20.2.1.5. Dependency Inversion Principle
20.2.2. Common Refactorings
20.2.2.1. Compose Method
20.2.2.2. Extract Method
20.2.2.3. Inline Method
20.2.2.4. Rename
20.2.3. Test Refactoring
20.2.4. Modular Design
20.3. Testing
20.3.1. developer tests
20.3.1.1. Unit Testing
20.3.1.1.1. xUnit
20.3.1.2. Design-for-Testability
20.3.2. test-first
20.3.2.1. Test-Driven Development
20.3.2.1.1. TDD Cycle - Red, Green, Refactor
20.3.2.1.2. Which test next?
20.3.2.1.3. TDD with GUIs
20.3.2.2. Tests Used for Design
20.3.2.3. Behavior-Driven Development
20.3.2.3.1. StoryTest-Driven Development
20.3.3. customer tests
20.3.3.1. Acceptance Testing
20.3.3.2. Exploratory Testing
20.3.3.3. Testing Quadrants
20.3.3.3.1. Supporting Programming
20.3.3.3.2. Robustness / Fault Tolerance
20.3.3.3.3. Technology Facing
20.3.3.3.4. Business Facing
20.3.4. Test Automation
20.3.4.1. Test Automation Patterns
20.3.4.1.1. Test Doubles
20.3.4.1.2. 3A Pattern: Arrange, Act, Assert