Pair Programming: Why does the Red Airship team work in Pairs

By | Uncategorized | No Comments

What is Pair Programming - Red Airship

Pair Programming Pros & Cons

In mid-2015, we began experimenting with pair programming at Red Airship. We’ve heard many differing opinions, and we went ahead anyway. [P.S. we do agile development]

After 12 months – we built better products, client satisfaction significantly improved, and all our developers (and designers) wanted to continue working in pairs. We have since adopted Pair Programming in our work at Red Airship.

What is Pair Programming (aka “pairing”)

Pairing means having two developers working on the same task at the same time. It’s not the same as splitting the to-do list into sub-tasks and having the individuals tackle them in parallel.

When developers pair at Red Airship, they use two sets of keyboard and mouse connected to the same computer, so they don’t have to pass keyboards around. They also have two or three screens so they can work with more real estate.

The developer who is actively programming, the “driver”, focuses mainly on writing code. At the same time, the “navigator” helps to spot tactical and any upcoming strategic issues. The navigator – as the extra pair of eyes – looks ahead and help spot tactical and strategic issues in what the driver is doing on the keyboard.

Tactical issues like syntax errors, typos, not following conventions, are caught in real time as the navigator covers the driver’s blind spots. Strategic issues like wrong patterns, approach, design are worked out during discussions and again while execution as the navigator looks much further ahead. The pair takes turns and switch roles frequently.

What is Pair Programming - Red Airship

Photo credit:


Why should two people do the work of one?

Besides improved design quality, reduced defects, reduced staffing risk, enhanced technical skills, improved team communications; working together is also quite fun 🙂 Two is just right; any more and you may start to border on groupthink.

While this may seem like a counterintuitive, lavish use of our most important resources (ahem, developers), here’s our review of the pros and cons of Pair Programming.


Pros of Pair Programming

  • Faster, Better Solutions

Every developer has their unique background and experience. When two developers are tasked to solve a challenge together, magic happens! The number of potential solutions to one problem more than doubles. We can come up with better-designed solutions without impacting time to deliver.

Talented programmers are also able to come up with great solutions alone. It’s just much faster with two brains 🙂

  • Bad habits, Begone!

The bad habits that developers indulge in when they work alone? They don’t do that in pairs because someone else is watching.  

Sometimes developers feel compelled to over-deliver and end up skimping on good development habits. Automated tests? Those can wait after Deanna’s Friday campaign!

Although it appears that value is delivered to the clients quicker, poor habits reduce deployment confidence in the next release and increase the chances of regression and integration bugs. Future developments might be delayed or slowed down.

Bad habits can seem harmless enough now, but issues usually crop up down the line. The domino effect of technical debt will likely offset any revenue brought in by the business initiatives they were so eager to support.

Also tied into the next point: the seniors feel obligated to be role models, and juniors emulate what they see, thus picking up good development habits on-the-job.

  • Leveling Up Developers

When developers work together, they learn from each other consciously and subconsciously. This transfer of knowledge includes coding practices, design patterns, new technologies, tools, domain knowledge, hacks and tricks, and even some aspects of personal development.

This transferring of knowledge also applies to experienced developers too. I have been programming for the last 20 years, but I am still learning new things all the time.

Experienced developers have their way of dealing with code, so it can be refreshing to see different approaches from junior developers. I once worked with a developer who just started picking up CSS, and was pleasantly surprised by observing her method of solving issues.

When you teach someone, your understanding of the subject deepens. This collective growth is valuable to both our clients and the company as a whole. Also, the project is now less dependent on any one developer – the team shares the know-how and experience, which leads us to our next point.

  • Breaking Down Silos and Heroes

In some companies, when the lead developer of a project takes a break, the project goes into hibernation or maintenance mode until he returns. Have issues with component Y? Let’s wait till Don comes back!

In worst case scenarios, the lead developer holds the project hostage and leaves everyone hanging. All these can happen when individual developers stay within their boundaries and own specific components.

Conversely, a common complaint of developers is that they get burnt out as they cannot take proper vacations. Working in pairs allows someone to go on leave while the other holds the fort. Add rotating pairs on top of this, and the whole team benefits from the flexible allocation of tasks and resources because anyone can work on any story.  

When pairs rotate, domain knowledge is dispersed to everyone in the team. Everyone understands what everyone does, enabling more efficient team communication. Now Don can go on his vacation freely, knowing that he is not a bottleneck to the project.

  • Developer Morale and Satisfaction

During the initial stages of implementation at Red Airship, each developer in our team tried pairing over a few sprints for starters. Feedback was very promising, with all of our developers reporting improved productivity, confidence, and work satisfaction.

“In an online survey of pair programmers, 96% of them stated that they enjoyed their job more than when they programmed alone.
Additionally, 95% of the surveyed programmers said that they were more confident in their solutions when they pair programmed. A correlation exists between satisfaction among programmers and their confidence in the code; i.e. the pairs enjoy their work more because they are more confident in it.”

Williams, Laurie; Kessler, Robert R.; Cunningham, Ward; Jeffries, Ron (2000). “Strengthening the case for pair programming.”IEEE Software.

As the points of contact between developers increase, we also noticed improved relations between the pairs. In other words, stronger bonds formed as a result of pairing, and the whole development team became more close knit.

We’ve always known that happy people do their best work! All these translated into spending more time on building higher quality software and less time on tracking and fixing bugs.


Cons of Pair Programming

Even with all the stated benefits, Pair Programming is not a silver bullet without any cons. Pairing is a social skill that has to be learned – and human interactions can be unpredictable. And with other people in the equation, personalities, feelings, beliefs and egos will surface; things that add complexity to a situation.

  • Only Fast As…

This bottleneck effect is mostly observed in a senior-junior pairing, especially when the junior takes on the role of the driver. The pair ends up going only as fast as the slower team member.

The day-to-day pacing does feel slower, but the problem does not take more time to solve. Overall, time is shaved off the project because higher quality code has fewer bugs (fixing bugs take up a lot of a developer’s precious time)!

This effect is understood, weighed, and embraced at Red Airship because we emphasize quality over speed. We are also very fortunate to have buy-in from senior developers who care about team development

  • More Talk, Less Coding

A lot more time is spent explaining concepts and decisions to the junior developer. Programming feels inefficient with so much talking going on. Plus, all the thoughts in your mind will now need to be translated into words and communicated to another person. The urge to do things instead of pausing to explain can be present in more experienced developers.

Good communication is a sign of clear and coherent thinking, and people only get better when practicing this repeatedly. It is an overall benefit to the individual as well as the team.

Furthermore, verbal rationalizing evolves through debates and results in better, simpler explanations. Great comments in the code are a result of a good thinking process. And anyone can & will appreciate simple succinct comments!

  • Scheduling Issues

We do not enforce strict working hours at Red Airship, and our team members work at whatever time of the day in which they are the most productive. It may cause some issues when individuals in a pair work best at radically different periods of the day.

We quickly learned that this isn’t so much of an issue as we thought it would be.

We found that pairs always adapt to each other’s schedules within a week. Even with different individual work timings, they can find a sweet spot of compromise. These adjustments happen organically without any management’s intervention, and we’d like to think of it as a result of our cohesiveness and culture of team accountability.

Also, our developers don’t spend all their time coding – they also engage in other equally important activities such as reviewing work with the UX team, research on new technologies, doing code cleanup and maintenance, and writing documentation. Remember, pairing does not need to occur 100% of the time!

  • Code Ownership

Developers take pride in owning a piece of code. It improves code quality when an author feels responsible for its bugs. So, who owns the code when two people produce it?  

There is a lot of value of collective ownership of code. We foster a joyful, cooperative work environment conducive to collective growth. The team understands that owning a piece of code feels good, but building great products together feels better.

How to do Pair Programming - Red Airship

Our final thoughts on Pairing

This article highlights our experience and successes in implementing Pair Programming in Red Airship. We believe that it worked for us because we are very fortunate to have:   

1) Senior developers who are passionate not just about honing their skills, but also about growth of the team

2) Clients who were open to exploring and experimenting with different ways of working

There is no one right or wrong way to Pair Program, and most importantly – not every company can or should implement pairing. At Red Airship, we view this as a task of matching problem complexity and pairing types, and this is a topic we’d like to share more in future articles.


Pair Programming Best Practices

What can you do to help cultivate an environment in which pairing works?

We are by no means an expert in this field, but some of our groundwork and learning paid off. Our hope is that you can learn from our experience too.

  1. Remove the fear of failure from your workplace. Cultivate an environment that encourages experimentation and openness. When people are not bogged down by the fear of failure, they can do better work.
  2. Promote the right values instead of tracking performance via metrics like hours logged and the number of commits. Having the whole team aligned with the same set of values allows them more freedom to do what it takes.
  3. Try pairing outside of the development team too. We also tried pairing within the UI/UX design team with the same great results. Pairing is ultimately a new way of working, not just in agile/development. Stay tuned for more articles!


Want to pair with our developers and work on cool projects?

Find out more and apply to our apprenticeship program at Red Airship.


Working at Red Airship as a Developer Intern

By | Careers, Culture | No Comments
Yong Xue's Developer Internship at Red Airship

Yong Xue is seated in the middle, in light blue

Why did you apply to work at Red Airship?

I applied to Red Airship because I saw that they had cool past clients, like BBC. I am a big fan of BBC… so that was one of the reasons. I wanted to try web development too, as I did my internship at a game studio last year.


Describe your interview experience.

I was asked to block out 2 hours for the interview. That sounded like a long interview, so I assumed that I’ll be tested on my technical knowledge.

When I arrived, it turned out that 7 people were interviewing me alongside another candidate (for a different full-time role)! It was unexpected, but very interesting. It wasn’t scary though, and nope, I wasn’t tested on anything technical in the end! It was meant to get to know me better as a person. I passed the interview and went back for a one-day trial.

P.S. we do extreme interviewing here at Red Airship


How is working at a company different from school?

In school, I mostly did things by myself. For my one day work trial, I was introduced to Pair Programming, where I worked with Yihui (developer). It was quite helpful to learn on the go and have someone spot any mistakes.


What is a typical day or week like?

I code everyday… just coding, coding and more coding. I guess that’s what developers do all day!


What was good about your work experience?

The environment at Red Airship is nice, the location is easy to get to, and there’s a lot of food nearby (haha)! Ryan (co-founder) taught me things from his own experience – how to structure a project and plan what needs to be done. My colleagues were really nice too.


How about the not-so-good parts?

Actually, I’m quite happy overall. I ended up learning more than I expected! I thought that they only did Drupal here, but I also got to try out React.js.


Which projects did you work on?

I got the chance to work on mobile apps for OCBC, Sharetransport (testing of mobile app), BBC (display advertisement) and Aqua Expeditions.

Special note: When Aqua Expeditions put in a special request for a donation drive after an unfortunate accident in the Amazon, Yong Xue worked extremely fast to set up an online donation page in less than a day. He also started the ball rolling by being the first donor.


What are your future plans?

I look forward to graduating. I’ve started a company with some friends, Diceroll Studios. We’ve started work on a mobile game already – an action/puzzle game titled ‘Recolor’. The player has to navigate visually pleasing environments, drawing a path to recolor the world of two protagonists. We’re still working on the final story, and will launch it on iOS in September.


Summarise your overall experience.

I find that the aim of the company to make their employees happy is very commendable. In many ways, they’ve succeeded. I encourage people to join Red Airship as I had a very good experience during my 3 months here.


About the author:

Eu Yong Xue is currently a 4th year computer science student at the National University of Singapore (NUS). His interests are in programming and creating cool interactive experiences. He also started a gaming company (Diceroll Studios) with his friends. Their first puzzle/action mobile game, Recolor, will be launched in September 2016

Yong Xue's Developer Internship at Red Airship

Asked to give an impromptu speech…


Comments from Yong Xue’s Supervisor, Ryan Tan (CTO, Red Airship)

Red Airship values our interns’ motivation and capacity to learn over their technical capabilities, and we measure our success by the growth we observe in every individual we take in. Over the few months he was with us, Yong Xue has consistently met and exceeded the high standards Red Airship has in this area.

Despite not having extensive exposure to web development, he was quick to pick up our web and mobile application frameworks through a few crash courses, and continued to self-learn in his free time. By the last few weeks he was able to contribute confidently to all the projects he was involved in and worked well with the team.

He also became quite close to another Spanish intern, and developed quite a bromance (lol), which the whole team enjoyed .

We are fortunate to have the opportunity to watch his growth and develop his interest in web and mobile development and look forward to working with him in the future.

How to use certbot to obtain a Let’s Encrypt SSL cert for your Drupal site running on CentOS 6.7 / 6.x

By | Drupal | No Comments

This article details some of the hoops I had to jump through before I could authorize my Let’s Encrypt cert via Certbot, hope it helps the next guy.


Certbot used to only support python 2.7 and above, but recently began supporting again. That’s good news as CentOS is still on Python 2.6.

Danger: CentOS requires the particular python version it comes with, so do not attempt to upgrade 2.6 to 2.7!

There are some guides on how to install python 2.7 side by side 2.6, but as of the time of writing, it is unnecessary to do so. Certbot can detect if python 2.6 is used and support it accordingly. If you did install python 2.7 as well, it may confuse the auto-detect script in certbot and cause it to attempt to install unneeded packages which will lead to conflicts.  Read More

Visual studio on Macbook Pro: Setting up your Macbook for .Net development work – Part 1

By | .NET, General | No Comments

Want to develop for .NET on a Mac?

There are generally 3 ways to get visual studio on Macbook Pro:

  1. Install windows via Bootcamp,
  2. Run windows via a virtual machine,
  3. Install windows via Bootcamp then run the image as a VM with parallel.

In this article I am focusing on the first option to dedicate maximum CPU and ram for visual studio, MSSQL and IIS.

Check if your Macbook Pro is supported

Anything 2013 early 15” Retina and later should support 10. If you’re not sure, check Apple’s list at

Getting windows 10 installer image

For those on Bizspark, you can download the enterprise edition iso at
(To reach here from Bizspark website after logging in, click on the small “get tools” link on the top right, and again “MSDN Subscription” in the same area on the new page.)

If you’re wondering why some versions have a “N” suffix, those are versions without media technologies (media player, codecs, etc.) bundled.


Run Bootcamp assistant

Allocating space for windows partition

The windows 10 OS itself took up about 20GB. Office will take up another 1.5~2GB. Visual studio installer alone takes up 6GB, and take up some 15-20GB installed.

If you are not planning on doing anything other than development work in Visual Studio, recommend at least 50~60GB of space for the new partition.

Windows Support Software

If you get the error “The Windows Support Software Could Not Be Saved To The Selected Drive”, try only checking the first option and perform 2nd and 3rd later. In my case, I proceeded with the install without downloading the support drivers first, and only came back to MacOS for it after the first boot into windows.

Installing Windows

If your windows installer complaints that “We couldn’t create a new partition or locate an existing one. For more information, see setup log files”, try resetting your NVRAM:

Reboot your Mac, hold down Control, Option, R and P on the keyboard right after the chime. Keep holding until the Mac reboots and you hear the chime again. After that complete the BCA procedure as normal.

(Referenced from last page of


Install boot camp support software on windows

Go to your USB drive and look for a bootcamp folder or similar. You should see a setup.exe inside. Run it.
If you get a “The version of Boot Camp is not intended for this computer model”, you may have manually downloaded a version via apple’s website. Those are meant for widows 7 and earlier, so reboot into MacOS and use the boot camp assistant to download the right version.

Stuck at Realtek?

If your set up stucks on “Realtek Audio”, try these to work around:

  1. Keep the installer running (do not force quit)
  2. go to your bootcamp folder, manually install the realtek driver, at the end of the install, do not restart
  3. after manually setting up realtek, open Task Manager, and kill the “RealtekSetup” process
  4. bootcamp will now skip the Realtek step and proceed.

(Referenced from )


In Windows land

Configuring keyboard and trackpad

Access the boot camp control panel from the status area (right most of the task bar), it’s the grey diamond icon. Click on it once then select “Boot Camp Control Panel”

Select the options you need in the “Keyboard” and “Trackpad” tabs in the new window.
Want to use the command key as ctrl? Download sharp keys from

Installing Visual Studio

To mount the iso, select the iso file in explorer, and a new menu “Disc Image Tools” should appear. Clicking on it should give you 2 options “Mount” or “Burn”. Select “Mount” and run the set up application at the root of the disc (mine was “vs_enterprise.exe”).

Select custom installation so you can select the components you need. For me I enabled “SQL Server Data Tools” and some Git tools under “Common Tools”. If you are also doing frontend development, you can install node.js here too.
Enable any mobile-related components and the installation size jumps to 30+ GB as it auto-selects windows SDK and Android Native Development Kit (taking up about 5GB each) among others.

Install IIS

Open the “Programme and features” section of control panel and stay tuned for Part 2!

Making sense of the difference between AMD, CommonJS, RequireJS and Browserify

By | Javascript | No Comments

A colleague starting on javascript frameworks asked me what’s the difference between AMD, CommonJS, RequireJS and Browserify. He was under the impression they are 4 separate technologies so here’s a quick overview for those who might be confused. Take note this article is not meant as an in-depth discussion but more of an overview for people unfamiliar with the terms and not sure where to begin.

For a start, we need to understand they are not from the same category. Asynchronous module definition (AMD) and CommonJS are styles/specifications of writing modular code in javascript, while RequireJS and Browserify are 2 popular implementation/helper for them respectively. RequireJS allows you to work with modules the AMD way in the browser, and Browserify for the CommonJS way.


Asynchronous module definition is designed for the browser from the start. It allows your frontend application to load the starting point of your app, which in turn loads it’s dependencies on the fly. When using the requireJS implementation, it’s syntax looks like: Read More

Drupal 7 troubleshooting checklist

By | Drupal | No Comments

New to Drupal or a little rusty? This checklist is to help speed up your troubleshooting process. The list is currently at version 0 and I hope to improve it by giving more structure along with associating/clustering each item with symptoms. Let me know if you want to help! Read More

Leendy is now part of Singapore Sharing Economy Association

By | General, Leendy | No Comments


The Sharing Economy Association (Singapore) is a business association for companies and organisations involved in the sharing economy, which refers to an emerging economic model of sharing of physical and non-physical resources that is empowered by technology, peer-to-peer and social networks. The Association was officially launched on 11th June 2014 and aims to be the regional hub for companies and organisations involved in the unique space. Read more

Red Airship proudly sponsors DrupalCamp Singapore 2014!

By | Drupal, Events | No Comments


DrupalCamp Singapore is an annual conference that brings together web developers around Southeast Asia to learn, share and explore web development and the Drupal content management system.

Entering its 3rd year in 2014, the conference has attracted over 300 attendees from across Asia to gather in Singapore since 2012. This year, the focus will be on Drupal 8 and how it will impact the web industry greatly, featuring speakers & attendees from Australia, Philippines, Indonesia, Singapore etc.

This year’s DrupalCamp is jointly sponsored by Red Airship, heartcode, Acquia, iMoney, among others.

When: 14 June 2014

Where: Singapore Management University (SMU).

Ngee Ann Kongsi Auditorium,
Lvl 2, School of Accountancy,
60 Stamford Road, Singapore 178900

Drupal Business Day – Singapore

By | Drupal | No Comments

Ryan and I recently presented at the Drupal Business Day, the first time that the global event has been held in Singapore. The guys at Pixel Onion (Kiat & SJ) did a fantastic job putting the event together and thanks to them for extending an invitation for us to speak at the event.

We got to share some of our thoughts about the challenges & tools for managing communities with Drupal and you can find the presentation below.

What is Drupal?
It is a free, mobile friendly, open-source content management system and framework that is used to build many modern websites ranging from blogs to media, enterprise, political and government websites. It is used in at least 2.1% of all websites worldwide. Examples include the White House and The Economist. The platform also scales well to support millions of users.

For a list of websites built on Drupal, check out the Drupal showcase.

Check out this useful list of modules for community building.

Red Airship in WalkaboutSG

By | General | No Comments

Come hang with us on Friday May 17th for WalkaboutSG – a behind-the-scenes look at Singapore’s tech scene.

Leave your business suit at home and lace up those sneakers, we’re throwing open the office doors so you can see what it takes to rock a tech company. Walkabout Singapore is a celebration of technology and entrepreneurial culture in Singapore. On Friday, May 17th, the companies behind your favorite products and services will open their doors for a city-wide open house. Check out their workspaces, see how they work, and meet the people leading the technology charge in Singapore.

We are co-located with Minitheory so you get to visit 2 offices in a trip! While you’re here, do check out our openings at for the kind of people we’re looking for. We value the right attitude over skills and will provide ample training, so interns are more than welcomed as well.

RSVP now at

When: Friday, May 17, 2013

Where: All over Singapore! This is not a scheduled tour, you are free to drop into any office during their open house hours. Check for the most up-to date information.

Who: Entrepreneurs, Hackers, Designers, Students and Tech Enthusiasts – it’s FREE.