Workshop name: TDD Workshop (new code)

Course code: WEB-18

Workshop days: 2.0

Your workshop: This was a 3 day workshop. James, I found that you did an excellent job of presenting your methodologies in a clear and consistent fashion. What's more, the planning of the course combining your view over the course participants development with the pre-designed test sequences, lent itself to a productive experience. Overall, I found the course sequence and planning around the attendee experience, which is to say the tooling availability and usage, to be well considered and fluently applied. Finally, the content of the course was very valuable, and provided a clear communication of TDD methodologies, refactoring, and general productivity management.

Better prepared: Much better

How to improve: I found that some heavily opinionated concepts present a distraction. I'll start by stating that it is clear that the presentation of TDD is very intentional and comes from a lot of experience and thought. Nevertheless, no one size fits all, and an unyielding emphasis just distracts. Here are my thoughts on two specific examples. 1. Optimizing error control through minimization on the period of a single TDD cycle is reasonably controversial. A lot of good developers are going to balk at the implication that they should write incomplete and unsound code. I fully understand the reasoning around the technique, but this style simply won't work long term for some developers. Perhaps is a pedagogical tool to insist on this practice, but I for one will compromise on this technique and still get a lot through TDD. 2. Emphasizing classic C programming, then discounting comments as a code smell, forces the developer to pick at the thread, and it doesn't hold up. Classic C is full of comments

Recommended: Yes

Quote permission: No

Back