One of the most valuable practices in the today’s software development is pair programming. Briefly, it means that two developers work on the same programming task together. There are uncountable benefits of doing pair programming and a lot of articles on the internet describing this practice.
If you think that pair programming only works with a programmer pair, you are obviously wrong. In the last months, I had the opportunity to pair with several non-programmer guys at Scout24 and made very good experience with it.
Pairing with a visual designer
It started when a designer came to me and asked some questions about the layout implementation of a new screen in our iOS app that he was about to design.
Instead of answering his questions, I suggested that we sit together and implement the task with pair programming. So I opened my Xcode and my colleague opened his Sketch (a designer tool) and we started our pair programming session. During the work I explained to him a little bit about auto layout in iOS and showed him how it looks like in the Interface builder. In turn he explained to me how a designer uses his tools to put a screen together.
It took us about one hour to complete the task and the designer was very happy with it. In addition to finishing the implementation quickly to the designer’s satisfaction, we both learned a bit about each other’s work.
Pairing with an advertising manager
In this case we got the requirement from our advertisement team to migrate the ads in our apps from our own adServer to google adMob. Because the google adMob and their mobile SDKs have totally different behavior as our own one, there were a lot of questions and issues to clarify. There were questions such as: when should an advertisement be requested? When an advertisement impression should be tracked? Should we use smart banner or large banner? How should the advertisement behave in case of device rotation? And many other questions. Of course we had a user story for the migration. But because our ad management was new to adMob and our mobile developers did not have much experience with adMob SDKs yet, the user story was not precise enough to answer all those questions.
So I took my MacBook with me and went to the ad manager who was responsible for that story. The pairing session took 2 hours and was very productive. While my colleague was configuring the advertisement campaign, I was binding and configuring the BannerView in the application. After we tried a couple of things, we finally got a solution that satisfied the ad manager and me.
In this way, we achieved within 2 hours a solution that maybe would have taken one week if we had tried to clarify the whole issues using emails, phone or slack.
Pairing with a data analyst
Again, it was a migration story. Our company decided to switch to a new analytics platform.
Beside the migration, some tracking points had to be changed und some other points had to be removed. On top of that, the tracking documentation of our mobile apps is written using Microsoft Excel. All of these made it hard to implement the migration without a perfect communication with our analytics team. A couple of pair programming sessions with a data analyst from the analytics team were enough to complete the mission and get the migration done in time.
Pair programming works fine with non-programmers. It gives you interesting insights into the work of other non-programmer teams in your company and let you see the things from their perspective. But the biggest benefit of it is that it saves time, stress and cash money. So if you still do not have a notebook at work, you have now very strong arguments for your boss.
Questions or feedback? Get in touch with me on my personal blog.