I too attendend this year's GDCR. And I'm glad.
Well, it was a first GDCR to me, so it was a bit timid, sometimes even chaotic. I think next year I'll get more out of it, because I'm trying to make an agreement with myself to practice TDD on day-to-day basis so it would become a real habit, rather than alleged. However, it wasn't bad at all as an event, so everybody needs to start somewhere, myself and my partners, who some of them had little to no experience in programming. But I guess that is not a problem, just need to know how to act so both would benefit.
I was glad that very 1st session we had, was with laptops switched off, so we got bunch of paper to write on, so we did, we sketched out ideas on paper, tried to define some abstractions how the API may look like. Since that moment time flew in a blink of an eye, didn't notice how session to session we arrived to a lunch time.
During the 2nd session we did some pair programming writting unit tests first, and so we tried to test out ideas we sketched out during the first session, except that we didn't know what each other ideas were in the first round as we changed the pairs right after the round one finished

but we managed to get some work done.
3d session was ping-pong, I guess traditional session, where we were not able to talk with my peer except through the test cases. This session left me with very possitive feelings, I liked it a lot. That really brings out the importance of clear naming, clear semantics, expressivenes, production code wasn't the celebrity in this session, the tests were. So really the actual designing happens at tests stage. We agreed with my peer, that if we can't write sensible test(s), naturally we can't implement a good design as presumably we don't have one.
I think we had only 3 sessions in a morning and then were lunch. The time went so quickly that really is hard to remember everything now, even though all happened yesterday.
Then after the lunch we had 4th session which was called "TDD as if you meant it". I peered with lady again (peered with 3 ladies and 3 guys in total during the event), very smart and very bright one. Oh man, I think that was too much for us, it required to steer programming angle significantly. Idea was, that no production code can be written directly, it only can appear through refactoring process. You write all the stuff in test method(s), once you notice you repeat yourself, you extract to a method, but you don't have where to put it, so you keep it in a Test class. Once you notice that you extract some other methods which are kind of related, you extract them to a class, so you now have a type, then move on with other tests - easier said than done!!!. Leader of the session at one moment came to us (due to suspicion that something isn't ok) as we were writting code so quick that we missed the point, even though most of our code resided in the test class first, and when we slowed down after the leader put us back on the track, we felt we started getting an idea, but then time endend up instantly and we haven't got all the details in agreement with compiler, so the code didn't even run and then we were asked to delete the code, oh well, it didn't compile - so we did and both disappeared quickly in the crowd so nobody could notice how bad we were!
5th session was rather interesting. One was playing an evil coder, another had to push coder to the limits so he/she couldn't implement production code in the most dirtiest way. The idea was, I was writting tests, so my goal was to write tests, and the production code writer's the idea was to implement it in the most easiest (dumb) way by simply hardcoding things and returning expected values right away without any rationale behind them. So really I looked at this session as to a way to learn how to write more general tests so you wouldn't write tests also in a same dumb way as an evil coder by hardcoding things. i.e.:
The thing is, that those (4, 4) are pulled from a thin air, where those 4, 4 coming from in the first place? Why not (-4, 7)? Get an idea...
So really a better idea to write was:
Ignore the uselessness of such test, the idea was to train yourself towards thinking how to write higher quality tests, i.e. which cover broader range of inputs.
6th session was again, implement the same game, but taking into account some given constraints we were able to choose from, i.e.:
No conditional constructs (if's else's, loops)No methods longer than 3 lines (loved that one)No primitive typesNo return statementsNo mutable state (loved that one)... (don't remember, but there were more perhaps)
And so it. At the end or close to the end we had some LIVE experiences
exchange with other worldwide GDCR teams including one of which was from Ohio, unfortunatelly they had no video stream (probably due to technical reasons), but I'm 99.9% sure Junilu's voice was on a speaker, am I right? And so one moment our facilitator said if we want to say something to others over LIVE streaming, so I barely holding myself from greeting Junilu

but remember, 0.1% was still left it wasn't Junilu.