Don’t Clean Code
AI Summary
Summary
This episode of “The Standup” features a deep dive into challenging conventional clean code wisdom with Carson Gross, creator of HTMX and professor at Montana State University. The discussion revolves around Carson’s “Coding Dirty” philosophy, which questions three core tenets of clean code methodology.
Main Arguments Against Clean Code
1. Large Functions Can Be Good
- Carson argues that large functions (even hundreds of lines) are not inherently bad
- Provides empirical evidence from studies showing longer methods have fewer bugs per line of code
- Points to successful software like Chrome, Redis, and IntelliJ that contain large functions
- Large functions provide aesthetic hints about importance - there’s no unimportant 100-line function
- Easier to debug with more context available in one place
2. Unit Testing Limitations
- Advocates against test-driven development as the primary methodology
- Prefers integration tests over exhaustive unit testing
- Warns that too many tests create their own mass and can prevent necessary changes
- Tests only catch known bugs, not unknown edge cases
- Recommends testing at the highest level possible to maintain flexibility
3. Over-Abstraction Problems
- Criticizes the tendency to create too many small classes and functions
- Argues that abstraction is not cost-free - it adds complexity through naming, dynamic dispatch, and cognitive overhead
- Small functions with strategy patterns create navigation nightmares where developers lose context
- Good naming cannot fully capture what code actually does - names are inherently lossy abstractions
Key Insights
Development Philosophy:
- Situational programming is better than ideological adherence to rules
- “Beautiful at any size” applies to functions - stop “fat shaming” functions
- Focus on what actually works rather than following dogmatic principles
Testing Strategy:
- End-to-end tests are crucial but must be carefully maintained and focused on critical functionality
- Prefer fewer, higher-level tests over many small unit tests
- Tests should focus on business requirements and outcomes rather than internal state
Abstraction Principles:
- Don’t abstract for abstraction’s sake
- Every abstraction layer loses information about actual implementation
- Sometimes an if statement is just an if statement - polymorphism isn’t always necessary
Discussion on Memes and Development Culture
The episode concludes with a humorous discussion about developer memes, including Casey’s failed Microsoft recruiter meme and TJ’s spot-on Steve Ballmer impression. The conversation touches on the importance of embracing “cringe” in developer culture and not taking oneself too seriously.
Key Takeaways
- Question conventional wisdom in software development
- Consider context over rigid rules
- Embrace larger functions when they make sense
- Test strategically, not exhaustively
- Avoid over-engineering through excessive abstraction
- Maintain flexibility in your development approach