Adam Pohorecki

Test first, ask questions later

More Ruby than Ruby talk at KRUG

| Comments

A few days ago a tweet reminded me about a talk I gave on the 6th of August on KRUG:

One trend I'm observing is a lot of rubyists being fed up with messy ruby ecosystem are getting excited or even switch to clojure.

— Piotr Solnica (@_solnic_) October 15, 2013

I ❤ Ruby

I have been programming in Ruby professionally for over four years now. When I was starting out, there were probably mere dozens of Ruby programmers in Kraków. Compared being one of the thousands of Java developers, programming Ruby felt almost exotic.

Not that long ago, being a Ruby programmer meant being on the bleeding edge of web development. You had to deal with immature and unstable libraries, crappy deployment options and IDEs that didn’t offer much more than syntax highlighting. On the other hand, it also meant working with smarter than average people, who were drawn to this technology not just because it was new, but also because it was in many ways superior to the other options out there. I loved it.

A couple of years have passed and I still love Ruby. I actually love it so much, that I called my dog Ruby. However, the times have changed. Rubyland is no longer the domain of adventurous and industrious early adopters. Ruby is now mature, stable and “enterprise-ready”. Somewhere along the way Ruby has become the responsible choice of a language for building web apps.

Let’s face it: Ruby is a good language to know right now. The jobs are plentiful and well-payed, and the technology is still relatively modern, but progressively more safe and boring. The days of exciting and unpredictable Ruby are almost over, and soon I’ll only be able to like it as a friend.

I ❤ Clojure

I have come across this LISP on the JVM quite a while ago, but having had pretty bad experiences with Common LISP at my university, I never had much interest in it until in May of 2012 I came across a presentation given at RailsConf by Clojure’s creator, Rich Hickey.

I am a huge believer in Single Responsibility Principle. Most of my classes have one public method. I tend to avoid inheritance and heavily favor composition and delegation. Unfortunately, a language like Ruby punishes you for coding in this style - your small classes end up being split amongst hundreds of files and often wrapping a function in a class seems like an overhead.

Watching that video made me realize that maybe I should look into functional programming languages. After all, functions are smaller units of composition, and they are easier to combine. I watched a bunch of other Hickey’s presentations and I got hooked on Clojure.

Compared to other functional languages like Scala or Haskell, Clojure, as a dynamically typed language, was much more up my alley (in the dispute between static typing vs TDD, I stand strongly behind TDD). It also appealed to me more than Erlang, since I mostly work on web apps, and Clojure seems to do better with those.

Clojure > Ruby

I read a couple of books about Clojure, started playing with the language and I fell in love with it.

Let’s start with the fact, that Clojure is perfectly capable of expressing pretty much everything that Ruby can, most of the time just as concisely. This in itself is not much of an achievement, but factor into that the syntax of both languages. Even I could write a parser for Clojure. Do you know anyone who could write a parser for Ruby? Clojure’s syntax is the perfect marriage of power and simplicity.

Clojure has real namespaces, where Ruby only has modules. Clojure’s keywords can be namespaced as well. It avoids Ruby’s method naming problems (like when two libraries adding a method with the same name to a class like String of Array). Clojure has ClojureScript. Clojure is well suited for multithreaded programming. Clojure has macros. Clojure is faster…

I believe that this is a great time to get into Clojure programming. The ecosystem is mature enough that you can find libraries to do pretty much everything you need (even if they are not overly polished). The people in the community are above the average, because they have learned Clojure, not because Clojure programmers are in demand, but because they wanted to. There are also plenty of books, screencasts and other resources to learn Clojure from.

Uncle Bob called Clojure “The Last Programming Language”. I would settle for “The Next Big Thing”. Dig in while it’s hot:)


Unfortunately the presentation was not recorded, so all I have are these slides:

PPPPP talk at KRUG

| Comments

On the 9th of July this year I gave a talk about Ping-Pong Pomodoro Pair Programming on KRUG.

Ping-Pong Pomodoro Pair-Programming

I always wanted to do pair programming, but every time I tried, I failed to get much benefit out of it and I walked away tired and frustrated. I didn’t really know what I was doing wrong. Every time I raised questions at conferences about how to succeed at pair programming I didn’t get any good answers.

The problem is that pair programming is not that easy to get right. If you want to be successful doing it, you need to be at least twice as performant (for some definition of performance) as a single person. You also need to avoid burnout that comes with working harder than you would by yourself.


Thankfully I kept trying and at one point when programming with Rudy we started doing Pomodoro Technique in addition to pair programming.

Pomodoro is a personal productivity technique that says you should concentrate on a single task for 25 minutes and than take a 5 minute break afterwards, with a longer, 20 minute break every 4 pomodoros.

It turned out that by using Pomodoro we not only got all the advantages of that technique (focus, work rythm, daily planning) but also we avoided the burnout that has followed pair programming for me before.


Once we realized that frequent switching during coding keeps us both fully concentrated, we also added Ping-Pong pair switching technique to the mix.

Ping-pong is a natural extension of TDD to pair programming. You switch at the keyboard for every part of the red-green-refactor cycle, with the first person writing a failing test, the second making it pass and the first person refactoring.

In traditional pair programming you switch at the keyboard every couple of minutes, but what I’ve found is that it is very easy for one person to keep typing for much longer than that. What I’ve also found is that after being away from the keyboard for about ten minutes your mind starts to drift away and you lose your focus on the code being written. With ping-pong we make sure that both of us are fully engaged and focused on the code that we are writing.

The Presentation

If you want to learn more about PPPPP, I recommend that you check out the full presentation below:

PPPPP talk at DRUG

| Comments

Along with the presentation about Bogus on DRUG I also gave a lightning talk about the way I work every day with Rudy.

Most people I know don’t pair program at all or only do it occasionally and for a couple of hours or days at a time. We spend pretty much 100% of our time at work pair-programming. Heck, we actually have only one computer between us, so we can’t do it any other way, even if we wanted to.

While pair-programming itself is not really that hard, maintaining that way of working over an extended period of time is not trivial. We use a certain mix of techniques that allows us to do it and we call it PPPPP, which stands for Ping-Pong Pomodoro Pair-Programming.

Pair Programming

Many Extreme Programming techniques have managed to achieve mass adoption, but pair programming is not one of them. Most programmers I know use TDD, do continuous integration and work in iterations, but pair programming somehow does not have the same appeal.

Pair programming promotes shared code ownership, improves code quality and helps in knowledge sharing within a team. It gives you a line-by-line code review as you work, which lets you avoid making mistakes instead of correcting them after the fact. It even simplifies project management, because a team that does pair programming has half as many tasks in progress as a team that doesn’t.

Beneficial as it is, pair programming is also hard work, in a quite literal sense. Things that you take for granted, like taking breaks when you feel like it, checking email and RSS, spending an hour reading documentation, etc. are all gone. Pair programming forces you to concentrate on the task at hand pretty much the whole day, and that can be very tiring.


Pomodoro is a technique where you concentrate for 25 minutes on a single task and nothing else (no checking email, IM, etc.). After every such iteration you get a 5 minute break. After every four iterations you get a longer break. You start each day by planning and estimating the tasks for the day and end with a short retrospective.

We use Pomodoro because of the rhythm it introduces. We no longer have to ask each other to stop working when we feel tired, because we know that in a couple of minutes we will have a few minutes to rest. It helps us maintain concentration during the day, because we only have to keep it for less than half an hour at a time. In short, it keeps us from getting burned out.


Once you start pair programming you will observe that once you spend more than a couple of minutes away from keyboard, you concentration flutters. To combat that we use a pairing technique called Ping-Pong.

When you write your code using TDD, you go through a well-known red-green-refactor cycle. In Ping-Pong, person A writes the failing test, then person B makes it pass and finally person A performs refactoring. Next cycle starts with person B, and so on and so forth.

This technique helps us maintain concentration and improves shared code ownership, because there’s never any code that “you wrote and I just watched”.


I apologize for the quality of the slides, but they were supposed to be more of a discussion starter than means of conveying information. Hopefully the ones from a talk I’m giving this month at KRUG will be more useful.


The slides and video from my PPPPP presentation at KRUG are already available. Check them out if you are interested in learning more about this topic.