How to make workshop conference ? - Warsjawa 2013

If you wonder "How to make workshop conference ?", you know that's could be extremely difficult. There are hundreds of attendees and workshops are usually quite small (at most 30 people). Programming workshops usually needs infrastructure as access to internet, large display, microphone speakers. So you need about 20 rooms with equipment and lot's of organizers to solve "bugs" when they show up. You know Murphy's Law, and you know that "bugs" will appear shortly after conference will start. It sounds like a head ache, doesn't it ? But If you want to know how to do it, and how to turn that conference in success, ask Warsjawa organizers. They have the magic formula. Warsjawa 2013 was spectacular success. Every thing went really smooth!

Creative attendees that was something we were counting on

This year I had a great opportunity to be on the other side (together with Jan Zborowski and Pawel Stawicki). I was trainer on "One day with challenging client" training. That's training made by SoftwareMill which main goal was to create similar to real-life case and get attendees involved. On that case we show up traps that team members could be caught. Many of those traps are not the traps set up by "evil client" but by the team itself.  On the other hand we demonstrate good practices that make communication with client more efficient. We teach attendees a bunch of simple guidelines that could improve their relations with customer and increase project success rate.

Q&A session

Attendees were really great, all tree teams managed to deliver working solution. On Q&A session we had a great opportunity to talk about everyday problems. I hope that this training will help them in their every day work. It's not a silver bullet but some technics should be useful (I was attendee at this training once and I use them often :-) ) Big thanks to one of the organizers , Adam Chudzik was helping us during the training, his was very eager to help and we really appreciate that.

My, speaking with passion

After finishing my workshop I was really tired but event though I took usability training workshop with Mateusz Kaczmarek and Michał Trzaskowski. Workshop was fine and that was nice trip out of my comfort zone. I learned a bit about usability testing. It was nice introduction to the Human-Computer Interaction course that I just started on Coursera.

Having beer with another Łukasz

The conference after party was at "Mam ochotę". I met a lot of Java/Scala geeks there and had a change to talk a bit about Scalar. Scalar is our new baby (SoftwareMill's), it's one-day fee Scala conference, that will take place in Warsaw at 05.04.2014. That was a great day but very exhausting.

PS 1. If you enjoy idea of "One day with challenging client", we (SoftwareMill) may run it at your company or conference.

PS 2. Next chance to attend to that training is on AgileByExample 2013 (on this friday)

PS 3. All photos were made by organizers, used by permission. To see Warsjawa 2013 gallery click here 

Code Review is not about...

In SML we do code reviews. We do them on daily basis. Actually the point that we are now is a result of long journey that we made. We try different strategies and tools until we went to the place that we are now (but it doesn't mean that we are going to end up here).

During this journey we found many risks and traps that are waiting for a newcomer. That's what this post is all about, traps & misconceptions on code review.

Code control: many organizations uses CR for controlling codebase. Most of them are using pre-commit strategy. In many cases its because those projects are open-source with hundred of commiters. In real life this is quite rare scenario, so if you hired someone it means that you trust him enough to let him commit code to repository. I know that in some organizations there will be temptation to make procedure that will force developers to "review" and "approve" every commit, but it will not guarantee the quality. Moreover people will soon treat code review as "stupid" corporate procedure and will try to hack-it (such changing password every month e.g. people are using passwords like: mypass1, mypass2 etc.).

Hall of blame: Don't user CR for finding scape goats or guilty ones. Let's assume that there was a failure and you found a person who "reviewed" the "bad code" and blame him for not pointing it out. I will cause that development in your company will drastically slow down. People will be pointing out every semicolon not at the right place, because they will be afraid of being scape goat. Your team members will start feeling unconfident and the lack of trust.

"Code" of duty: Don't push on your developers to much. If you force them to make review every day for an hour, soon they will hate it and treat as unfunny duty. Code review is about learning, praising others and giving feedback so it's very social activity. CR could be fun, don't spoil it.

I'm not my code: If your code was reviewed by someone and he left some comment (sometimes even not too nice), don't get angry. He isn't saying that you are a poor developer. That wasn't his intention nor code review is about that. All he did, was criticizing some piece of code (not the author). Code review is all about code, not about you. Don't treat code review tool as forum with "trolls" and people fighting each other. When you will be writing comments try not to be rude or too strict. Try to imagine that your are on the other side reading it.

To sum it up, there is plenty of ways to make code review wrong. Those 4 are the one that I experienced or anticipated, so beware. I promise to write post about "what code review is about".

If you wan't to try out code review tool (fruit of our experience & practices) visit codebrag.com

Used photos:
1. "The Puppet Master" by Henk
2. "ready for duty" by Leonard John Matthews
3. "Polar wolf's argument" by Tambako the Jaguar