For the most part, programming is usually a one man/woman job. You get your task, and you fire up your IDE and you get to work. You miss a deadline, get yelled at, deadline extends, repeat. That's the usual approach anyhow. But there are alternatives to the traditional method, such as Pair Programming.
Pair programming revolves around the idea that two people work on the same project with just one computer and just one keyboard. And normally only one person gets to code at a time, obviously, while the other person analyses the problems and calls out what to do next. It's a driver and navigator type situation. It isn't common usually in many companies though as it gives off the appearance of wasteful resources. Seeing two people in front of one computer normally puts managers off. I've yet to work for a company that has taken pair programming seriously enough to make it a common work theme. But I have worked for companies that were willing to give it a shot.
Due to a broken computer at my last job, I got to experience pair programming first hand. And it was an eye-opening experience for sure. It didn't start off as a paired task, but when you have two devs and one machine, it just kind of happens. So there I was, staring at a screen telling another developer to query from this table, and join on this table, etc. And as they had no idea about the database schema, they were more than happy to type along. Some hours later, they were tired of typing, so I took over, and just naturally they began to be the brains of the situation. They called out the logic, I came up with the code. But it reduced the amount of brain power that I needed myself to get this done. They weren't worried about the code and I wasn't worried about the logic, at least not as much. And any task that involved complex thinking was split across two different brains.
After about 3 days of non-stop work and typing and shouting and call outs, we completed this project and it was an incredible feeling. The code felt much more mature because of it and much less bug ridden. We had confidence in this code and personally speaking, that's not usually how things go. If you ever have a QA person return back a list of 30 errors and bugs and you sit there wondering how you let those "slip" by, it's kind of a real-time version of that.
Pair programming offers many advantages
There are many advantages to the pair programming model, but I'll only talk about the ones that I've experienced first hand. Some people have different feelings on the issue though, and I'll talk more about that down below.
1. It's more fun and less stressful
It's surprisingly fun to program with a coworker on a single machine. For one, you're talking the entire time that you're working. That's definitely almost never true at a traditional software development shop. Usually, I put my headphones on, crank it to 11, and won't stop until someone taps me on the shoulder. Some hours later, I appear at home. But its incredibly fun to be able to share ideas and solutions to problems. It's something that's normally taught in school, but that normally dies off by the time you get to the working world.
2. Shared Responsibility
This one sounds a little weird. But sometimes working on a project by yourself, with a looming deadline can be stressful and can ruin an otherwise perfectly normal day. Having another person share in that stress reduces yours. Also, it's harder for management to blame two people than it is to blame one. So you're not alone when you end missing that deadline. You had two people on it, so if you missed it, must have been pretty tough.
3. It Keeps You Alert
I don't know about other programmers, but on a normal day, I will fall asleep in front of my computer several times. Which is why my caffeine intake is so dangerously high. But sometimes this job is pretty boring, particularly when most of your day consists of looking at other peoples cryptic code with comments like:
if (tmp1 > (0.4 - tmp2 / 8)
{
// then run this very important part
}
I could literally spend an entire day trying to figure out what this means, and I have. Which is boring and results in my head banging on my keyboard to a look of shock from my peers. And talking it out by yourself is just weird and might warrant in a suspension perhaps. So having another pair of eyes there sharing ideas and possible solutions is a huge plus. You only get 8 hours of work time, so instead of spending 30% nodding off, you can spend it cranking out logic.
Faster results
Sometimes I spend way too much time on the simplest of problems at work. Sometimes it will take me 3 hours to realize that the problem is an incorrectly spelled DOM element.
<select id="stateReqiured" ...
That's mainly due to boredom, lack of interest, or a combination of both. With a partner, however, you bypass those feelings, because it isn't just your project anymore. You type and you talk and that's all that happens. And if anything else, you can complain about how boring that piece of the code is.
A few disadvantages to pair programming
But all is not so green in this field. There are a few downsides that I've noticed while trying pair programming. Not many though, but these do linger on from time to time.
1. People are people
A very important one being that sometimes, many times, people will tend to disagree on things, and that can cost more time than it's worth. It's happened to me several times, and while the projects came out early and relatively well developed, it does have a stressful component to it. One person wants to use the latest frameworks and JavaScript libraries, and the other person, i.e. Me, just wants to get the project done. Everyone has their own programming style, but if you can put that aside for just a bit, the benefits are definitely well worth it.
2. One Resource Short
But perhaps the most notable disadvantage, and probably the reason why you're not working like this yourself, is because to the outside world i.e. your manageres, you are one dev short. Not just short though, sitting there in front of you, but not working on their own projects short. And that's the worst kind of short. And sometimes this is a very valid point. If you're a small shop with very few employees and you've promised the world in 24hrs to every single client that calls you on the phone, then you're probably going to have some issues with this approach.
It's Not For Every Situation
There are a few caveats that go with sharing a computer and a keyboard. For the most part, Pair Programming doesn't make any sense for small tasks and projects. If a programmer can get the job done by himself in an hour, then they should. The other person will just be bored sitting there waiting for complexity to loom its ugly head.
It's a methodology better suited for large projects with many moving parts that require complicated thinking. If you've ever been stuck on a problem and have asked a friend eventually for a suggestion, and they come up with an answer within 5 seconds, it's just like that. It's definitely what this field has been lacking in a work environment and one that I would gladly implement for my employees if I had any. Managers shouldn't be afraid to lose a dev to a taken project, they should be more afraid to lose a dev period because they didn't try something that's a definite benefit to them.