Course:
TDD for Embedded C
Date entered:
2018-03-28 17:30:51 UTC
Course rating:
Good
Most useful learnings:
Mock, "code smell" principles, motivation.
Concepts v exercises:
Good balance
Presentation v discussion:
Good balance
Course improvements:
OK Balance on exercises and presentation. But I think the content of both would benefit from some changes.
The main thing I think I liked with the course was the small step approach that you "preached". But the motivation for it came on the last day. That should perhaps have been part of the first day. The idea of mocking based on link error, and then only implementing the absolute basic to pass a test is the way to go I think. Perhaps you can even move the last exercise on day 3 to day 1. That will make your point come across much clearer and louder.
I also think that you could spend a bit more time with the UML diagrams or a "box" equivalent to really drive home the point of what is the "fake" and what is the "spy" etc. and do this on the first day. That will make everything after that fall into place much faster.
Exercise rating:
Good
Exercise improvements:
Day1: Very rough start. lack of substance in the first part of the presentation. confusing and lacking motivation. Very rough transission to first exercise.
Day2: Felt like a continuation of Day1, except by now we have learned how your exercises was structured and what you wanted us to do. From the second day and on we did pair programming and that made a lot of difference/sense. I would suggest merging content from Day2 into Day1. make it harder but more clear and cleaner (simpler to get started). Then move day3 content to day2 and add more content to day3. Perhaps some CI or other tooling and hints how to write clearer code. Perhaps even tech clean code pronciples and coding technices.?
Day3: This was the best exercises. I would not change anything on this one. Except perhaps move it to day 1
Instructor comments:
Day1 first couple of hours felt like you where selling in the course. But the fact that we already where here should make that unnesessary. I would have prefered that you had skipped large parts here and gotten into the "meat" earlier. We where three people here with varying levels of skill but all agreed on this point.
Better prepared:
Bring it on!
Start tomorrow:
already doing TDD, but I do think I can improve a lot in how I use it. And I think you gave some very good point on how in day 3.
So in the end, rather motivational. I'll leave "richer" then when I arrived.
Challenges to applying:
regardless if you are working with old code or new code, I always end up doing lots of refactoring. And having to refactor lots of tests can be daunting. So even if I like TDD I'm usually very selective when I use it.
It's also often very difficult to use TDD when the code rely on infrastructure components like SQL, network stuff etc. (I do a lot of network programming).
Other comments:
The remote delivery was OK. No real issues, only some confusion the first day when there was no link to the web meeting.
Legacy code workshop:
No
Recommend to others:
Yes
Quote permission:
Yes