Note to Media Temple users

If you host your files with Media Temple, we want you to be aware that we are experiencing some issues with editing files via FTP with that hosting provider. In some (but not all) instances, the process of editing, saving, closing, then reopening a file causes the file size to appear as 0MB. In some (but not all) cases, closing and reopening the file again causes the data to reappear. We are working with Media Temple to identify and fix the issue, but you may want to use SFTP or local editing on Media Temple files in the meantime.

This does not appear to be an issue with any other hosting provider (and we have tested many), so if you are not using Media Temple, everything will work as expected. If you have any questions, please email us at team @ squadedit.com or tweet @squadedit.

Version Control Systems 101

Since Squad recently introduced Git integration, it seems like a good time to take a brief look at how Git—and version control systems in general—work and how you can utilize version control to speed up and organize your development process.

What is a version control system?

A version control system is simply a way of keeping track of different versions of your code. These systems help you organize and store your tried-and-true versions while also working on and eventually incorporating experiments and new ideas. Continue reading

Pair Programming and Side by Side Programming: What they are, who uses them, and why?

Since Squad is particularly well-suited to facilitating strict pair programming, we’ve touched on the subject several times here. A recent Wall Street Journal article also highlighted several different programmers’ experiences with the method. We’ve also mentioned, in rather more nebulous terms, a sort of “collaborative programming” that is also possible, without exactly sticking to the rules of pair programming. While I was doing a semi-regular review of academic literature regarding programming best practices a few weeks ago, I finally stumbled upon some research that gives this nebulous collaborative programming idea a name: side by side programming. If you use either of these techniques, or are considering using one, here’s a quick look on the main points of each.

Pair Programming

The basic setup for pair programming is that there are two roles: the driver and the observer. The driver controls the mouse and keyboard and actively writes code. The observer spends his time watching the driver’s code, points out mistakes, and spends time contemplating possible alternative approaches to the problem at hand.

The pair should switch roles every so often, to keep each team member sharp and focused. The exact optimal interval is a topic of debate and probably varies for each team, so if you are exploring the pair programming technique, start with something you can each agree on, and adjust according to how you feel the time works for your pair and current project.

There are different philosophies regarding how much time a programmer should spend pair programming; some companies ask programmers to work in pairs all day, every day, while others find it to be more effective in smaller doses.

Side by Side Programming

Researchers have used the term side by side programming to describe programmers who work on code simultaneously but don’t adhere to the strict protocol of pair programming. Programmers using the side by side method are more likely to be physically located in different places, and this method more easily allows for a whole team to work on a document while maintaining an awareness of what colleagues are doing.

Because side by side programming does not have the strict protocol of pairing, it is somewhat easier to get used to and use quickly. Typically, a team using side by side programming would all be working on their own tasks until a team member asks for help or just another set of eyes. At that point another colleague joins the first wherever he or she is in the code and they work through the issue together, whether they are in the same room or across the world. Once the issue is resolved, everyone goes back to his own task. This flexibility makes side by side programming easier to integrate into the team’s workflow, but doesn’t have pairing’s advantage of constant error checking and knowledge distribution.

Additional Resources

If you would like to explore these methods of programming, you might want to check out a few of these resources.

Types of Cooperation Episodes in Side-by-Side Programming by Lutz Prechelt, Ulrich Stark, and Stephan Salinger (2010)

Pair Programming vs. Side-by-Side Programming by Jerzy R. Nawrocki, Michał Jasiński, Łukasz Olek, and Barbara Lange (2005)

Distributed side-by-side programming by Prasun Dewan, Puneet Agarwal, Gautam Shroff, and Rajesh Hegde (2009)