Software Engineering Workbook

Date: 2025-01-27
Problem: Need to handle errors from multiple API calls in a Go service
Force Approach: Wrap every API call in try-catch style error handling, creating deeply nested if-else blocks
Leverage Alternative: Use Go's error wrapping and create a custom error type that implements the error interface, then use error handling middleware
Key Learning: Instead of fighting against Go's error handling patterns, work with them using the language's built-in error interface

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

Before: "I need to process a large dataset concurrently in Go"
Leverage Questions:
- What's the smallest change? → Use goroutines with a worker pool pattern instead of creating thousands of goroutines
- Work with existing systems? → Leverage Go's built-in sync package and channels
- Use constraints as catalysts? → Limited memory forces me to use bounded concurrency, which is actually better design

Week of: 2025-01-20

Force Example:
Problem: Need to test a complex Go function with many dependencies
Approach: Created mock objects for every dependency, wrote extensive test cases covering every branch
Outcome: Took 2 days to write tests, tests were brittle and hard to maintain

Leverage Example:
Problem: Same complex function testing requirement
Approach: Used Go's built-in testing package with table-driven tests, created minimal test doubles only where needed
Outcome: Completed in 4 hours using Go's native testing patterns, tests were maintainable and clear

Key Insight: Instead of fighting against Go's testing philosophy, I worked with its built-in patterns

Problem: Design a REST API for a microservice in Go
Original Approach: Use a full-featured framework like Gin or Echo, implement all CRUD operations, add comprehensive middleware
Artificial Constraints: Can only use standard library, must work with existing HTTP server, no external dependencies
Constrained Solution: 
- Use net/http package with custom routing
- Implement basic CRUD using standard library patterns
- Create simple middleware using function composition
- Use Go's built-in JSON marshaling/unmarshaling
Key Insights: The constraints forced me to understand Go's standard library better, resulting in a more maintainable solution

Constraint: "This Go application has strict memory limits and can't use more than 100MB"
Reframing:
- What constraint? → Limited to 100MB memory usage
- How could this help? → Forces me to focus on efficient data structures and avoid memory leaks
- What opportunities? → Creates a clean, efficient application that scales better

Problem: Need to implement logging for a Go microservice
Minimum Solution: 
- Use Go's built-in log package
- Create simple log levels (INFO, ERROR)
- Write to stdout (let container orchestration handle log collection)
Value Created: Basic logging with zero external dependencies
Where to Add Complexity: 
- Structured logging (high impact, medium effort)
- Log rotation (medium impact, high effort)
- Centralized logging (high impact, high effort)
Why: Basic logging provides immediate value, advanced features can be added incrementally

Existing System: Basic Go HTTP service with simple endpoints
What's Working: 
- Stable HTTP server with good performance
- Basic error handling
- Simple request/response patterns
How We Can Build On It: 
- Add middleware for common functionality (logging, auth)
- Implement graceful shutdown using existing server patterns
- Add health checks using existing HTTP handlers
Next Steps: 
- Week 1: Add logging middleware
- Week 2: Implement graceful shutdown
- Week 3: Add health check endpoints

Project Goal: Migrate from monolithic Go application to microservices
Existing Energy Sources: 
- Team already familiar with Go and HTTP services
- Management wants better scalability (microservices can help)
- Developers frustrated with monolithic deployment issues
How to Channel Energy: 
- Start with extracting one service from the monolith
- Use existing Go patterns and libraries
- Show how microservices solve specific deployment problems
Potential Resistance: 
- "We don't have time to learn new architecture patterns"
- "Current monolith works fine"
Mitigation Strategy: 
- Start with non-critical service to prove value
- Use existing Go knowledge and patterns
- Show concrete benefits (independent deployment, scaling)

Today's Small Improvement: Add one comment to a complex Go function explaining its purpose
Expected Compound Effect: 
- Future developers (including me) understand the code faster
- Reduces time spent debugging complex logic
- 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

Project: Design a new Go microservice for user authentication
Leverage Approach: 
- Use existing Go HTTP patterns instead of learning new frameworks
- Extend current authentication logic rather than rebuilding from scratch
- Leverage existing database connection patterns
Constraint Strategy: 
- Limited to existing infrastructure and databases
- Must work with current security and compliance requirements
- Can't modify existing services (only new ones)
Momentum Building: 
- Build on team's existing Go knowledge
- Use established coding patterns and conventions
- Follow current testing and deployment practices
Precision Focus: 
- Focus on core authentication functionality (login, token validation)
- Skip nice-to-have features that don't impact security
- Prioritize reliability over complex features

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 Go review items
- Use automated tools (gofmt, go vet, golint) 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

Team Member: Sarah (Software Engineer)
Judo Moment: Instead of rewriting our entire data processing pipeline, I optimized the existing Go code by using sync.Pool for object reuse and implementing worker pools for concurrent processing
Principle Applied: Momentum over Muscle - Built on existing code instead of starting from scratch
Key Learning: The existing code structure was actually good; I just needed to optimize the performance bottlenecks rather than rebuild everything
Team Discussion: 
- "This approach saved us 2 weeks of development time"
- "We should document this optimization pattern for future use"
- "Let's create a performance optimization checklist"

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