Endless conversation — with friends, compilers — on art, equivocacy, Symmathesy, methods, absurdism, dialectic, paradigm jumps, serendipity.
We'll do an ensemble/mob programming over a kata, but some of the participants are secretly saboteurs! Like a game of "werewolf".
The idea is that a saboteur does not want to be found? So the saboteur will make their sabotage believable! And hence we end up experiencing the team dynamics that we could have in real life situations. The team tries to solve them, while coding, and fighting the sabotage instead of the saboteur.
Beyond the "test first, then test guiding then Red green refactor" stuff : what is all the fuss about?
In this hands-on we'll cover that. Why do TDD even if you're doing a hackathon and throwing away the code? TDD as Socratic dialogue, TDD as mindfulness, the design goals behind the tool.
To do that I'll start by showing you how I teach TDD to people. (If you are a beginner you are also welcome.) We'll slow down in each part, and we'll use techniques such as lazy-naming, branch reduction, purposeful-bad-faith, ...
Then we shall dive into the why.