It's also interesting that the pair vs TDD divide is often based on the solution space.
Service/backend programmers often extol TDD because it is easy when working in a single language where your only IO is strings (i.e. Undergrad CS)
Front-end programmers may use TDD in certain established contexts, but pair may be more important when there are numerous integrations across unsupported toolchains. For example, when was the last time you used TDD with CSS? Oh? Too hard to verify that the CSS for a page makes it so that you can't click a button or print a page? Oh? Market bug isn't your responsibility?
Yeah, I see a lot of defensiveness when TDD is impossibly hard, so it's not "all that". But, use it if it makes sense. Know your tools and use the right tool for the job.
Service/backend programmers often extol TDD because it is easy when working in a single language where your only IO is strings (i.e. Undergrad CS)
Front-end programmers may use TDD in certain established contexts, but pair may be more important when there are numerous integrations across unsupported toolchains. For example, when was the last time you used TDD with CSS? Oh? Too hard to verify that the CSS for a page makes it so that you can't click a button or print a page? Oh? Market bug isn't your responsibility?
Yeah, I see a lot of defensiveness when TDD is impossibly hard, so it's not "all that". But, use it if it makes sense. Know your tools and use the right tool for the job.