On the eve of my first journeyman tour stop, I began to question my sanity. What on earth had I gotten myself into? Switching coworkers, problem domain, programming environment, language, and technology stack every week for the foreseeable future. Well, for a couple of months at least. With a summer break in the middle. But really, that's besides the point. I had caught the equivalent of stage fright. Naturally, Kim
called out my sillyness reassured me that all would be well.
This would not only be the case; it would prove to be an understatement.
Originally intending to spend two and a half days with Kundo, circumstances truncated the tour stop to a single day. I showed up in the morning and was greeted by Patrik Stenmark whom I've previously pair programmed with, though it was in Ruby and almost four years ago. This time we got to work on their main product which is written in Python and based on Django. The task at hand was to extend the functionality of discussion threads. Patrik had already done a great deal of work, but had had to backtrack a few times to find the right path forward. This was where we got to work.
A difference between Ruby and Python is that methods in Python are declared with an explicit receiver argument whereas the receiver is implicit in Ruby and available through the
self keyword though it's usually not needed. A Pythonic idiom is to name the explicit receiver argument
self so in practice there's very little difference in everyday use.
# Ruby def some_method(arg1, arg2) some_other_method arg1 yet_another_method arg2 ... end # Python def some_method(self, arg1, arg2): self.some_other_method(arg1) self.yet_other_method(arg2) ...
However, coupled together with the fact that in Python methods are objects this does open up for some interesting ways of making a Python method operate on a different object than the one it's attached to. We used this trick to bring a piece of code under test before extending it. By applying a method to a test object we could eliminate a lot of setup required and test multiple scenarios quickly without touching the database. We added an integration test requiring the full setup and the difference in test execution time was by the order of two magnitudes.
Returning from lunch we briefly considered whether I should pair up with someone else, but soon concluded that continuning with Patrik where we broke for lunch would be most beneficial to all parties. Due to the partially distributed, partially specialised nature of the team I believe pair and mob programming occurs slightly less often than desired, but since Kundo is actively recruiting I think this is something that can easily be overcome with the addition of another developer or two. Given the warm and welcoming environment this will surely happen sooner rather than later.
The afternoon progressed just as pleasantly as the morning had. We finished most of the feature leaving a few minor things for Patrik to fix and some yaks to shave before firing off the pull request. Naturally we also had a mandatory fika break, eagerly devouring delicious buns.
In summary, I had a great time at Kundo, but more importantly, pairing with Patrik completely blew away all my fear and fret that this whole journeyman idea was a mistake. Spending a day at Kundo hacking felt nothing short of invigorating and I hope more will get the chance to try it.
Once again, many thanks for having me Kundo and Patrik!