Course: TDD for Embedded C

Date entered: 2021-10-18 07:56:06 UTC

Course rating: Excellent

Most useful learnings: I already have extensive experience in TDD, and this course still helped me refine and reflect on some of the things I do to gain better understanding. More specifically for C, how to do "interfaces"-like decoupling for C at linking level instead of actual interfaces, as is done in higher level languages. Also, how to leverage TDD to help with the hair-pulling problem of linker errors which you don't know how you caused exactly.

Concepts v exercises: Good balance

Presentation v discussion: Too much presentation

Course improvements: Overall, I think you did a great job, especially with the excercices, which lead to unexpected autonomous conclusions. Since I was an educator myself (and perhaps will be again), I am obligated to point out that concepts like flip the classroom are incredibly important. It may be good to see if you can introduce more interactivity with playful ways of getting people to interact with the problems they have. Can you e.g. without requiring code use a 'game' of some sort to switch up the story that would otherwise be a long presentation? It may be worthwhile to see if to a small degree you can grab on to real-world examples in the same way as in Burkhard Stubert's workshop and bring that into a context to test with. It's very tricky to do this though, but very worthwhile if it can help break up what would otherwise be long lectures. (Anyone who's ever done comp-sci expects lectures though.. and this expectation also applies to courses such as these I guess, so it may not be good! )

Exercise rating: Excellent

Exercise improvements: I think the excercises already balance cognitive load and complexity very well. Still, it is vital to keep complexity to a very low level. Unfortunately us developers expect 'challenges' that intellectually challenge us.. this is in conflict with the requirement of introducing new concepts; people may be overburdened. By choosing the most relevant 'complex' examples that are widely understood by almost every participant, this should be achievable. The circularbuffer example does a pretty good job at this. It is worth exploring if 'simpler in terms of cognitive load' examples exist which can help increase the amount of focus participants can expend on applying TDD properly. Small improvements in the "behind the curtains" checks to make sure people employ TDD properly are possible. It would also be good to have clear instructions on how to use the cyber-dojo, to maximize the performance people have and minimize confusion.

Instructor comments: You look older in real life than in the profile pictures I saw :D.. But that is a good thing; getting older is far preferable to the only other alternative. You make good usage of your hands when explaining things, you use clear language and have a good cadence and speed. There were sometimes occasions where you were in a long story and I noticed that some of my colleagues were drifting off; this can be avoided by adding in tiny snippets of interaction, even if it's just a question. (The question should be very simple though, trivial even) the act of placing people on the spot even for a relatively simple thing, having them think along just slightly, can help keep them on board with a story where otherwise attention may falter. Virtually every educator I have worked with, including myself, sometimes simply just talks for too long and we should always think of how to keep people on board :) - Your didactic skills are good, but can be improved even further.

Better prepared: Bring it on!

Start tomorrow: No, tomorrow is a Saturday. Also, we already started in other places and made a start in the workshop already, which is comitted to GIT already. I will ask with the author of the branch to see when/if we should merge it to master and how to make sure that we get CI set up :)

Challenges to applying: We'll need to keep on our toes and make a practical balance between the ideals of TDD and the practicality and pragmatism of developing with legacy code. While James correctly states that we should probably start scratching our head if we always make excuses for not making a test immediately.. it does raise the question: should we have rules? Do we need them? What if we end up being too lazy? Maybe we just need to give someone a TDD cap and ask them to keep an eye on things and reprimand those who sin against uncle Bob's laws? Also, as any developers knows, we tend to start to get cocky and try to take too big/too many steps at a time. We're going to end up writing tests that skip steps and end up tripping.

Other comments: It might be good to communicate the exact goals/expectations and what the students can accomplish afterward. Crystalizing these things not just for the entire course but the day should be good. E.g. telling people on the start of Day 1; after this course you will/should be able to autonomously perform TDD, or, if in combination with the workshop, it is *almost certain* that by the end of the week you guys will be able to start using TDD on a daily basis. Furthermore, every time there is a day the goals and competencies the participants acquire should be clearly communicated, so that it is 'obvious' what we're working toward. (Now, I am not saying it wasn't obvious.. but people as we devs well know, have limited memory capacity, by keeping our goals clearly in mind, it's easier to be in the proper mindset, and it takes away 'worry' which frees up for better performance). On the topic of worry; having a 'safe' learning environment is CRITICAL, make sure people feel safe :D

Legacy code workshop: Yes

Recommend to others: Yes

Quote permission: Yes