Global Day of Code Retreat - A Day of Perfect Practice

Jeanne,

The goal of GDCR is mindful and intentional practice of programming skills. If you go there with specific goals already in mind, I think it would be prudent to contact the facilitator(s) beforehand and ask them if they could prepare challenges that target your goals specifically. As a facilitator, I would love these kinds of requests and you have actually given me an idea for my next email out to the folks who registered for our local event.

If you can find other people who also want to practice the same thing, all the better. That gives yet another idea!

Good luck and I hope you have a great time at your GDCR event.

Junilu Lacar wrote: If you go there with specific goals already in mind

Well, my main goal is to attend a GDCR event for the first time and see what it is like.

Trying to ask my question better, I found the structure page which suggest this is a bad idea unless I'm pairing with someone who already knows VS Code well.

Well, let me ask you this: What about VS Code would you like to get better at? If there are many things, then what two or three things do you think you can weave into the whole Conway's Game of Life exercise? Just two or three things that you can probably learn/practice for one day and already see an improvement.

I sometimes challenge participants to learn to use keyboard shortcuts more because it makes them much faster coders, especially the ones that help them TDD faster: Delete line, switch between windows, rename refactoring, extract refactoring, moving methods around, moving lines around, running tests, quick fixing problems, etc.  There are quite a few shortcuts in Eclipse and IntelliJ IDEA that many people don't know. The other weekend at Columbus Code Camp, I demonstrated Option+Dn arrow and Option+Up arrow in Eclipse, the shortcut on the Mac for moving highlighted lines up and down. That was simply amazing to some people. And yet, they were able to immediately use that newfound knowledge as they were going through the hands-on exercises I gave them.

There's always something you can do better and even if it's simple little things like learning keyboard shortcuts in a new IDE, they can still make you much more productive when you go back to the real world of coding.

Junilu Lacar wrote:Well, let me ask you this: What about VS Code would you like to get better at?

At the time I wrote this, "basic using it." I spent five hours coding in it today. I wrote up how that went.

Ultimately, I don't want to be using VS Code. Eclipse and IntelliJ are far better IDEs. The only reason I'm using VS Code at all is so I can help high school students who have to use it. Which means I need some hands on experience with it!

I've actually used this as motivation to learn IntelliJ. I've never really gotten into it because I didn't want to take the productivity hit. But if I'm mixing Eclipse and VS Code, I might as well, mix in a third IDE! And IntelliJ does have better refactorings so there's more of an upside professionally.

It sounds like there's a mix of languages at the event. Maybe I'll be paired with someone who does JavaScript professionally and actually uses VS Code ./

Seriously though, I think I'll be happiest if I go in with no agenda.

Jeanne Boyarsky wrote:And IntelliJ does have better refactorings so there's more of an upside professionally.

I find that 80% of the time, I only need Rename and Extract Method refactorings. I have those keyboard shortcuts in my fingers. With others, I have to use the context menu.

Junilu Lacar wrote:

Jeanne Boyarsky wrote:And IntelliJ does have better refactorings so there's more of an upside professionally.

I find that 80% of the time, I only need Rename and Extract Method refactorings. I have those keyboard shortcuts in my fingers. With others, I have to use the context menu.

IntellJ has some advanced ones (like migrating to JUnit 5.)

However, VS Code lacks some entirely. Like renaming a class.

I went today. it was fun! Going in without any goals was a good idea. It let me "happen" upon learning. I wound up doing:

Java/IntelliJ (2)

Ruby/Atom

C#/Visual Studio

JavaScript/IntellIj

Python/VS Code

I learned a bit about VS Code, but a lot about IntelliJ so I'm happy with how it turned out from an IDE perspective. And I'd never touched Ruby before so that was new

We had an awesome time at GDCR'18 in Columbus OH. We had about 70 confirmed RSVPs and had 45 people show up. The energy and enthusiasm was truly awesome and inspiring.

We had some common problems to start off like folks without development environments on their laptops. However, by the second hour, most people were deep into their pairing and test-driving.

Some of the lessons people shared at closing circle:

1. That you can use tests to hash out complex production code first, then extract the code to the actual production classes. That is, you can use a test class as a "staging area" and sandbox for code that should be in a production class. This can make it easier to hash out ideas before

2. It's better to write code down and experiment rather than have extensive "high-level" discussion about design. Coding is design so write down your ideas so you can see what it looks like in code. When it's in code, ideas are easier to evaluate and decide whether it's good enough or if you need to find a different approach.

3. One person shared their frustration with themselves for "sucking" and his fear of slowing down his pairing partner. One of facilitators had the best reply: We all were in the same boat at one point or another in our journey as programmers. More experienced people should be patient with less experienced partners and lift them up, help them, and teach them how to get better. Experience people can learn as much from their partners as anybody else, if you just have the right perspective.

4. As facilitators, we experimented with demonstrating mob programming and pair programming. We had some mini-sessions to bring people up to speed on how to have a pair- or mob-programming conversation around the design. My advice was for the navigator(s) to say an idea about the design in plain English, staying from any implementation-specific language, and then the driver would then take that idea and translate it to the programming language. When the driver has translated the navigator's idea, the navigator will read the code out say whether or not the implementation was what he/she expected it to be. That is an instant code review.

5. You can go as fast or as slow as you want to when you are TDD'ing. The bigger the steps you take, the more you'll need to back out if something goes wrong and you need to revert. Smaller increments may feel slower but big increments can also slow you down when there is a problem in it and you can't localize the error to a small chunk of code.

6. I met a few more people who practice martial arts (TKD, BJJ, etc.) today. No fellow Aikido students though, except one who studied mix MA but mostly BJJ. We martial artists-techies share a lot of perspectives about software development, particular around empathy, egoless programming, and being agile and adoptable to changing circumstances.

I'm glad you guys had fun and learned stuff. Sadly I couldn't make it, because last week we got a message that we were selected for an apartment that we were interested in. This weekend I'm in Cologne to move my girlfriend's stuff. I'm really happy about the apartment, but at the same time I was frustrated that I couldn't attend the event. I'm putting everything aside for the next one though.

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.:
@Test public void location_row_index...() {    assertThat(4, is(equalTo(Location.of(4, 4).getRowIndex())); }
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:
@Test public void location_row_index...() {    Random rnd = new Random();    int rowIndex = rnd.nextInt();    int columnIndex = rnd.nextInt();    assertThat(rowIndex, is(equalTo(Location.of(rowIndex, columnIndex).getRowIndex())); }
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 types

No return statements

No 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.

Forgot to say, already waiting next year's GDCR.

Those who are reading all this thread and thinking would be great to attend this event too, but for some reason(s) hesitate - don't! A lot you can get out of it. This year's event I was attending facilitator was JP Morgan, an investment bank, so if you are looking for a job, what can be better, you get a chance to talk to with an engineering team leads, with HR (recruiters) who in turn introduce you with application process for a job, tell about various options, whether you are grad or looking for intern... So you can land even job if you are successful.

We did

just solve the problem

TDD as if you mean it

ping pong pairing

baby steps

object callistencis

evil pair programming

Jeanne Boyarsky wrote:We did

just solve the problem

TDD as if you mean it

ping pong pairing

baby steps

object callistencis

evil pair programming

That's awesome. I'd like to get to a point where we're actually giving those challenges to folks. I haven't been able to get that much rigor in the coderetreats I've facilitated so far though. Seems like we've had many different levels of experience and skill and sometimes, I feel we're kind of stuck in "just solve the problem". We did get people to try out mob programming though.

And I also forgot to mention, that at the end of event, we shared some thoughts: [1] what we learned, [2] what surprised us and [3] what we are going to re-use in our day-to-day life.

1. I kind of understood, that TDD is very difficult thing. Maybe not that difficult, but how much practice it requires to be anywhere close to a moment, that you could call yourself a TDD practitioner. Sounds about years of daily practice...

2. Surprised mostly how different people brains work differently. And to do a pair programming, I don't know what the formulae is, but somehow need to find a good strategy how to go inline with your pair in order to get an agreement on design. So that's something about listening to each other and have a trust.

3. And what I'll try to re-use. Is TDD of course, which I have little to no experience.

That's great to hear, Liu. Yes, TDD is quite difficult to learn. And yes, getting in synch with your pair partner can be tricky. I find that some ground rules / working agreements help to set the stage so that everyone knows what to expect from each other.

Some of the ground rules I like to establish:

1. We will write code instead of talk/discuss/argue about design decisions. The best way to tell if an idea sucks is to write it down as code.
2. We will try ideas out, no matter how much one of us thinks it sucks. The best way to tell if an idea sucks is to write it down as code.
3. We will use our tests to experiment with different ideas. The best way to tell if an idea sucks is to write it down as code and run it.
4. We will try to practice egoless programming. We will treat the code and design as its own thing, something that's its own entity that does not reflect in any way whatsoever on the intelligence and competence of the person who spawned the idea. The best way to tell if an idea sucks is to write it down as code and let it stand or fall on its own merits.