Judo Engineering Self-Paced Training Workbook

Date: 2025-01-27
Problem: Need to add monitoring to a Terraform module but there's no documentation about how the nested modules are structured
Force Approach: Reverse engineer the entire module structure by reading through all the .tf files, trying to understand dependencies, and guessing at the intended architecture
Leverage Alternative: Ask the team member who last worked on it for a quick 15-minute walkthrough, then document the key patterns for future reference
Key Learning: Instead of fighting against the lack of documentation, work with the people who have the knowledge

Date: ___________
Problem: _________________________________
Force Approach: __________________________
Leverage Alternative: ____________________
Key Learning: ____________________________

Before: "I need to add a new microservice to our Kubernetes cluster"
Leverage Questions:
- What's the smallest change? → Use existing Helm chart templates instead of creating new ones
- Work with existing systems? → Follow the established naming conventions and resource patterns
- Use constraints as catalysts? → The limited documentation forces me to ask questions and learn the intended patterns

Week of: 2025-01-20

Force Example:
Problem: Need to migrate a production database with zero downtime
Approach: Built a complex custom migration script with multiple rollback scenarios, tested extensively in staging
Outcome: Took 3 weeks to build and test, worked but was overly complex

Leverage Example:
Problem: Same database migration requirement
Approach: Used the existing database's built-in replication features to create a read replica, then switched traffic
Outcome: Completed in 2 days using the database's native capabilities

Key Insight: Instead of fighting against the database's limitations, I worked with its existing features

Week of: ___________

Force Example:
Problem: _________________________________
Approach: ________________________________
Outcome: _________________________________

Leverage Example:
Problem: _________________________________
Approach: ________________________________
Outcome: _________________________________

Key Insight: _____________________________

Problem: Refactor a complex Terraform module with nested dependencies and no documentation
Original Approach: Rewrite the entire module structure, create comprehensive documentation, and migrate all environments
Artificial Constraints: Can only use existing Terraform files, no new documentation, must work within current module structure
Constrained Solution: 
- Add inline comments to existing .tf files explaining the key patterns
- Create a simple README with just the essential module inputs/outputs
- Use Terraform's built-in dependency graph to understand relationships
- Make minimal changes that improve readability without breaking existing functionality
Key Insights: The constraints forced me to work with the existing structure instead of against it, leading to a more maintainable solution

Problem: _________________________________
Original Approach: _______________________
Artificial Constraints: ___________________
Constrained Solution: ____________________
Key Insights: ____________________________

Constraint: "This legacy system doesn't support modern monitoring tools"
Reframing:
- What constraint? → Limited to basic logging and simple health checks
- How could this help? → Forces me to focus on the most critical metrics instead of over-instrumenting
- What opportunities? → Creates a clean, simple monitoring approach that's easier to maintain

Problem: Need to monitor a new microservice in production
Minimum Solution: 
- Add basic health check endpoint
- Use existing log aggregation (no new tools)
- Create simple dashboard with 3 key metrics (response time, error rate, throughput)
Value Created: Immediate visibility into service health with minimal overhead
Where to Add Complexity: 
- Custom alerting rules (high impact, low effort)
- Performance profiling (medium impact, high effort)
- Advanced dashboards (low impact, high effort)
Why: Alerting prevents issues, profiling helps optimization, advanced dashboards are nice-to-have

Problem: _________________________________
Minimum Solution: _______________________
Value Created: ___________________________
Where to Add Complexity: _________________
Why: ____________________________________

Existing System: Basic GitHub Actions workflow that builds and deploys to staging
What's Working: 
- Automated builds on every commit
- Successful staging deployments
- Basic test execution
How We Can Build On It: 
- Add production deployment step (leverage existing staging logic)
- Extend test coverage using existing test framework
- Add security scanning to existing build process
Next Steps: 
- Week 1: Add production deployment step
- Week 2: Enhance test coverage
- Week 3: Integrate security scanning

Existing System: _________________________
What's Working: __________________________
How We Can Build On It: __________________
Next Steps: _____________________________

Project Goal: Migrate from manual server provisioning to Terraform
Existing Energy Sources: 
- DevOps team already using Terraform for some services
- Management wants cost optimization (Terraform can help)
- Developers frustrated with manual deployment processes
How to Channel Energy: 
- Start with services the DevOps team already manages
- Frame as cost optimization initiative (management buy-in)
- Show developers how it reduces deployment friction
Potential Resistance: 
- "We don't have time to learn new tools"
- "Current process works fine"
Mitigation Strategy: 
- Start with non-critical services to prove value
- Provide training sessions during lunch hours
- Show concrete time savings from automation

Project Goal: ____________________________
Existing Energy Sources: _________________
How to Channel Energy: ___________________
Potential Resistance: ____________________
Mitigation Strategy: _____________________

Today's Small Improvement: Add one comment to a complex function explaining its purpose
Expected Compound Effect: 
- Future developers (including me) understand the code faster
- Reduces debugging time when issues arise
- Creates culture of self-documenting code
- Makes code reviews more effective
How to Measure Progress: 
- Track number of functions with clear comments
- Measure time to understand code during reviews
- Count questions asked about code functionality

Today's Small Improvement: _______________
Expected Compound Effect: _______________
How to Measure Progress: _________________

Project: Design monitoring strategy for new microservices architecture
Leverage Approach: 
- Use existing Prometheus setup instead of building new monitoring
- Extend current alerting rules rather than creating new system
- Leverage existing Grafana dashboards as templates
Constraint Strategy: 
- Limited to existing monitoring tools (no new budget)
- Must work with current Kubernetes setup
- Can't modify existing services (only new ones)
Momentum Building: 
- Build on team's existing Prometheus knowledge
- Use established alerting patterns
- Follow current dashboard design standards
Precision Focus: 
- Focus on critical metrics (latency, errors, throughput)
- Skip nice-to-have metrics that don't impact business
- Prioritize alerts that prevent outages over informational dashboards

Project: _________________________________
Leverage Approach: ______________________
Constraint Strategy: _____________________
Momentum Building: ______________________
Precision Focus: _________________________

Opportunity: Code reviews are taking too long and missing important issues
Judo Principle: Leverage over Force - Use existing tools and processes more effectively
Action Plan: 
- Create a simple checklist template for common review items
- Use automated tools (linters, security scanners) to catch basic issues
- Focus human review on business logic and architecture decisions
Expected Impact: 
- Faster reviews (less time on formatting/style issues)
- Better quality (automated tools catch more issues)
- More focused human effort on high-value problems

Opportunity: _____________________________
Judo Principle: __________________________
Action Plan: ____________________________
Expected Impact: ________________________

Team Member: Sarah (Platform Engineer)
Judo Moment: Instead of rebuilding our entire monitoring stack, I extended the existing Prometheus setup to handle the new microservices by creating reusable Helm chart templates
Principle Applied: Momentum over Muscle - Built on existing systems instead of starting from scratch
Key Learning: The existing monitoring was actually well-designed; I just needed to understand how to extend it rather than replace it
Team Discussion: 
- "This approach saved us 3 weeks of work"
- "We should document this pattern for future microservices"
- "Let's create a template library for common monitoring patterns"

Team Member: ____________________________
Judo Moment: ____________________________
Principle Applied: _______________________
Key Learning: ____________________________
Team Discussion: _________________________

Day 1: Force: ___ Leverage: ___
Day 2: Force: ___ Leverage: ___
Day 3: Force: ___ Leverage: ___
Day 4: Force: ___ Leverage: ___
Day 5: Force: ___ Leverage: ___

Total Force: ___ Total Leverage: ___
Ratio: ___% Leverage

Goal: Increase leverage ratio by 10% each week

Week 1: ___/10
Week 2: ___/10
Week 3: ___/10
Week 4: ___/10

Average: ___/10
Trend: ________________

Week 1: ___/10
Week 2: ___/10
Week 3: ___/10
Week 4: ___/10

Average: ___/10
Trend: ________________

High-Impact Work: ___ hours
Low-Impact Work: ___ hours
Ratio: ___% High-Impact

Goal: Increase high-impact ratio by 5% each week