It's amazing what you can get accomplished with a team size of one.
For me it boils down to being able to fit the entire codebase into your head, or at the very least have it all written in your own voice. Reading code and packing it into your brain is the hardest part of programming, so having it all written in your own familiar style makes it really easy to get back up to speed on any bit of the project, even if you haven't visited it in a while.
Having even one other developer in there making changes can throw you out of speed-reading mode and make you stop and figure out what the other guy was thinking. That slows you down, and slowing down opens the door to distraction, which leads to bad things.
It gets really good when you're working by yourself on a project for which you're providing the direction. That removes the last roadblock from productivity, the "boss requested change".
As long as you document your style, I totally agree.
Nothing like it, if you're lucky enough to be blazing the trail.
The problem is for engineers who come in after you've left for greener pastures. If you don't document your style, design decisions, and over-all development process you're leaving behind a legacy... of miserable programmers who will make up stories about how awful you must have been.
As with most things, being exposed to different influences tends to make you a better programmer. So does fairly routinely getting a grasp of a big or otherwise alien codebase.
It might not work for everyone, of course, but it is probably beneficial for 90% of working programmers. So do not use this as an excuse to not try pairing (or working in larger teams, others' code etc.) with an open mind.
I would agree that different influences make you a better programmer, but perhaps not in the way that you meant. Almost every code base I've worked on in industry has been - and I think that most of my co-workers would agree with me - a steaming pile of code that barely functions well enough to do the desired task and is a nightmare to maintain. I've seen this at small shops and big corporations alike. Most of the really nice stuff that I've seen has been from OSS projects and books, and occasionally some project that a lone developer hacked out from scratch with little oversight and few constraints. Dealing with the ugly stuff has given me a good feel for anti-patterns and things to avoid from the get-go, but it has not exactly been a positive influence.
My main argument against pair programming is that you never feel that you have done anything significant. You can never be proud of a single line of code since it's always made by someone else together with you. You can't take credit for an invention/algorithm, and thusly never get the kick of true craftsmanship.
You are always expendable and can be shoved around like an animal, especially if you are a true team player that always nods and smile are "the best" to pair up with.
In fact, the cowboy programmers still rule the programming session when you pair up with them and they can easily take up most part of the day arguing small uninteristing details until they get it their way making the software theirs - not the team.
Your second and third paragraphs have nothing to do with pair programming. They indicate crappy management (shoving people around like animals) and a crappy team (nitpicky argumentation) respectively.
Your first paragraph is more interesting. How does the fact that someone else also contributed diminish pride in craftsmanship? Presumably it's the program you're proud of, so if the program comes out better, isn't that reason to be prouder? (If the program comes out worse, that's a problem.) Personally, it would drive me crazy to work with people who were constantly worrying about who contributed what. Software development is hard enough as it is. We can't afford to waste valuable cycles on that kind of thing.
My experience has been that the solitary-genius fantasy is the calling card of an immature programmer and is purely something to get over. (Just so it's clear, I'm not drawing this conclusion about you, nor about the OP.)
It may be true that co-programming makes crappy teams worse, but it also makes great teams better. As far as I'm concerned there's nothing better than a small team of smart people hammering on a hard problem together. But there's no question that it forces team dynamics into the open.
I prefer solo programming, but to me it means something different from programming without input from other people. I will ask as many questions as I can in order to get the job done. I will describe my design to key team members so it gets criticized and improved. I will ask people to review my code. But when I actually sit down to write code, I don't want anyone looking over my shoulder (with a few exceptions, such as bug hunting or prototyping).
I think there is plenty of bad programmers and bad managers. I don't think either profession is a lot better than the other. (I am a coder and manager)
Except that it's easy for just about anyone to spot a bad manager. A manager who doesn't actually know how to code couldn't spot a bad programmer if they fell into them.
From experience I know only two pair programming roles: the do-er and the yes-man. Which one you are largely depends on the mood of both and the dynamic of the team. So either you're writing code while explaining what you do to your copilot, or you're the copilot who's basically just sitting there, pointing out the occasional syntax error. Now, conventional wisdom says this isn't how it's supposed to be, but I have yet to see a different dynamic in the wild.
One thing where I had good experiences regarding paired work was serious bug hunts. There, the most important part was the discussion and the constant back-and-forth of ideas was actually productive.
I haven't done much pair programming, but when I've been the co-pilot, I watch what is being written and think about what else needs to be done. If some critical thing gets missed, or I think the code isn't going to do what it's supposed to, I speak up. (That includes syntax, but also logic.) I sometimes (rarely) make suggestions about refactoring or tests that need to be done.
I will admit, though, that for a while we jokingly called it 'peer programming' because you were just peering over someone's shoulder. We had a cowboy coder that taught us a LOT of stuff in the short time he was here and 'peer programming' was a large part of that. His time here was disruptive, but I think the whole team is a lot more productive thanks to his short employment. (And his disruptions were mostly him trying to convince everyone to do things a better way.)
The times I've done pair programming, the co-pilot has been a lot more active than what you describe. While the driver types out the details of a couple of lines, the co-pilot will look at the surrounding code, figure out what to do next, and keep a stack of things to be done (while still keeping an eye on the code being written). Once the driver is done, the co-pilot suggest the next little task. This might lead to a little discussion, which is great, because you have two people who are really into the code.
This has been pretty hard algorithmic work, though. No fleshing out hundreds of lines per hour.
Interesting. The one experience I've had with pair programming was also with non-trivial algorithmic stuff, and we had the same positive experience. I wonder if it's a more general phenomenon: "pair programming is for the hard parts" or something like that.
Even if that were all that happened, it would still be a more efficient way of avoiding procrastination and sharing knowledge within the team than email and meetings. In my experience, though, the copilot often suggests simpler or less duplicative ways to do things, finds logic bugs rather than just syntax errors, and maintains state in their head that the driver would otherwise have to keep written down. I'm talking about my personal experience here, not how it's supposed to be.
I've also had good experiences in situations where the two parties bring different skills to the table. If, for example, person A really understands the back end algorithm that you're trying to implement and person B really knows the front end codebase you're trying to add that algorithm to. Or if person A really understands the math and person B really knows the programming language. Basically if the two people have more or less well defined roles within the team.
Pair programming just seems creepy. I can't even read when someone is looking over my shoulder. You might as well be sticking your finger in my face just far enough away so we're not touching. "Two sets of eyes are better than one," may work in the field when you're on stake out looking for the enemy, but in programming I don't really see how that translates. Aren't bugs caught in the code-review process?
Eliminating bugs up front is like asking human beings to be perfect.
I'm unable to pair program. I've tried it, and quit where I was working as a result of their adoption of pair programming.
The best way I can describe it is that my "personal zone" for people not in my immediate family is about arms-length. If you're close enough to touch me, I'm uncomfortable. If we're sitting shoulder to shoulder at a keyboard, I'm so uncomfortable that I can't work.
I don't mean a soulmate either; just somebody who is not way ahead or way behind me. Either way, its wasting somebody's time for no benefit. Worse, the 'ahead' guy is stuck explaining why no, its not a bug, you just don't get the design pattern yet.
Unless the skill level/experience of the two match pretty darn well, its a dead loss in productivity.
"There are a number of reasons: I get to work at a museum where I can go and look at amazing fish, lizards, and butterflies every day"
This gave me goosebumps. If there was a way I could work this into my current office environment, I'd be in heaven. I love looking at fish, reptiles, insects etc...
I guess I could always buy a fish tank and plonk it down beside me.
I really liked what Mark Wilden had to say about Pair Programming. Personally, I don't see how Pair Programming is as valuable as teams. I prefer looking at people working on a project as a cross-functional team. This involves everyone (the team, product owner, agile master and even sales).
From a team perspective, people can work together when they need to, or run off to do research on their own and so on. It is an open experience where the Team figures out on their own how to best work together.
In pair programming, developers are FORCED to work a specific way. And that might not be the best way for that developer. I think Mark would have had a much more enjoyable experience in a team centric environment where each person is able to add to the team in the way they feel most comfortable.
Agile is about self managed cross-functional teams. As soon as upper management forces a team to work in a specific way, that self managed aspect disappears.
I do understand all of the advantages of paired programming but think you can get those and a lot more focusing on teamwork instead of pair work.
Personally, I see pair programming as one of a set of tools that should be deployed when necessary, rather than followed religiously. I've found it useful when I'm trying to solve a difficult problem, or teach a new starter about the company's code base. I also don't see it, as some other posters do, as being about 'code ownership' or bragging rights - that seems absurd to me, but perhaps I would feel differently if forced to program that way full-time.
My problem with pair programming is that it doesn't allow me to get in the mental state of "flow". The most productive state at least for me is when, for a period of time, I'm so focused on the job at hand, that I'm not aware of my surrounding. This is where my most productive work happens. You're completely immersed and focused.
When pairing I never can get into that state because I keep getting interrupted with "name that method x", "move that method before that method", "refactor now". It really breaks my focus.
I find it useful when tracking obscure bugs, where you can bounce ideas off of someone and basically nail the problem faster.
I've found that when I'm in the backseat we can be most productive as a pair if I spend my time trying to keep the driver in flow. When I first tried pairing the programmer control freak in me made this very difficult. I was effectively trying to write code by commanding someone else's hands to do what I was thinking.
By focusing on keeping the driver in flow you begin to appreciate when it's better to shut up and let them get on with writing the code, accepting that people have different coding styles is important here. You can then use your attention to either help out when they get stuck or maybe to tell them what the next test should be.
How does pair-programming mix with the dynamics of software consulting? It seems like it would tend to make project scope (persons/weeks) larger for clients --- something Hashrocket and Pivotal might not have a problem with.
That's what I would think, too. I was surprised to see that it was the one complaint he couldn't make:
> And as far as pairing is concerned, I know for a fact that I'm not as productive as when I pair-programmed at Pivotal. We got some amazing results, just chugging through the feature list.
Programmers who blog about programming --- particularly, programmers who blog well enough about programming to get picked up on HN --- tend to be outliers in lots of other ways too. I'm saying, just because he got good productivity out of pairing doesn't mean that most developers do.
Also, pairing can be both a productivity enhancer and a lever used by project managers and salespeople to increase project scope.
I once took a job that involved picking up the pieces after a team of Thoughtworks programmers were fired for incompetence. They pair-programmed some of the worst code I've ever seen.
That's what I'd say too. If hiring weren't our bottleneck, a story that made us able to add 1-2 people to every project we ran would be... lucrative. That's what set me off here.
(Our typical project scope is 2 people, 2 weeks; small projects 1x1/1x2, bigger projects tend to add weeks and not people).
Do you think you're producing quality software that meets your client's needs now?
Do you think your clients will pay more than they currently are for quality software that meets their needs?
If so, just start charging more. Make up whatever story you want about why you're charging more.
If you don't think you're producing quality software that meets your client's needs, but you think your clients would pay more for such software, then take whatever steps necessary to make better software and then start charging more.
That's how consulting pricing works in a vacuum. It's not how consulting pricing works in the real world. Scope abuse is absolutely an issue in enterprise consulting.
What's scope abuse? Sounds like when you add features to the project and charge more without approval from your clients.
My language was vague, but I didn't mean to imply that you charge current clients more, just charge new clients more.
It struck me as odd that you'd have to tie any price increase to an increase in your costs. If Lexus wants to start charing more for their cars they don't need to think of ways to use more steel. They just charge more and justify it however their marketers think is best.
If you sell developer-hours instead of products why not just charge more per developer-hour?
Here's an example from my field, software security:
"Oh, you want this application tested? Well, first you want a 2-person, 2-week threat modeling project where we give you a report on your attack surface, then you want a 3-person 4-week testing project, and if that turns anything up, you'll absolutely want a 1-person 3-month deep code review."
Here's an example from web design:
"Oh, you want a website for your new product? Well, first you'll want us to study the market for a week. Then you'll want a wireframing project so we can agree on what we're going to build; that's going to take 2 weeks. Then we'll spend 2 weeks on design and get you some comps to look at; if you want changes, we can do another week of that. Oh, you want HTML? Sure, we'll add on 3 weeks of coding."
I'm sure that some witness to software consulting could provide you with a story that fits this thread more directly.
Why not do X or why not do Y? Obviously, you're not a golfer. They do it to make money, without alerting the client to the fact that they're simply ratcheting up the dollar cost of the whole project.
So scope abuse is when you sell each component of a project separately and tell the client that they might not need some components even though every component is required for a complete project?
I can see why it's unethical to deceive the client about what components they will actually end up needing. I can see how you'd make money by luring clients in with cheap prices up-front then once they are locked-in charging more for the things they will inevitably need but didn't pay for already.
How does that relate to how you, as an ethical consultant, could raise your prices without raising your costs.
Are you saying that the only way you could raise your prices without raising your costs would be through scope abuse?
No, the opposite; it's when you break a project into component parts, inflate the effort required for each part, and convince the client they need to buy all of them. "Rustproofing" is another term for it.
Integrating and teaching junior staff is our problem, not our clients'. Maybe they're not charging for the junior pair member? (I'd be surprised; those economics don't work well.)
That may be what they say, however we contracted with Pivotal for several months and the results were not uniformly excellent. And the fact that the Pivotal contractors generally pair with themselves, and not with permanent members of the client team, can lead to a number of bad outcomes including: coding decisions which no one on the client team understands and code written (or changed) without sufficient understanding of the larger context or of the business domain.
If I was a savvy consulting salesperson, I might be thrilled to "pair" with client staff; it's an automatic staffing multiplier. "Oh, your team has 3 people already? Well, we'll need 3 developers right there to pair them with the consultants... and, yeah, you'll definitely want one pair from our team too, so that's 5...".
When the question is about 100% pair programming I'd say there aren't that many. Hashrocket is one of the few companies (I believe Pivotal is, too) where it seems to be true, but most teams that I know are only pairing part of their time.
At Braintree we pair program almost all of the time. There are some small tasks that people will do solo, but 99% of the development on our payment gateway ( http://getbraintree.com ) is done in pairs.
Having inherited code developed by lone wolves a few times, I have come to believe that healthy code is like healthy DNA; it needs a variety of contributors. Yes, it can be difficult at times. It can involve struggles but I have no sympathy for the complaints about them, the struggles make you stronger.
Seems like the comments here on HN are talking about pair programming far more than Mark's OP. The top line of his post was that he prefers to work alone, that the arguments and social overhead of collaborative development have made him unhappy. Pair programming isn't the only way (and often isn't the best way) to collaborate; reading each other's commit messages and talking about them is often sufficient.
And sufficiency is at the core of what makes software development fun and productive: a sufficient number of eyes on the code, a sufficient issue tracking app (and/or other collaborative apps) and sufficient amount of automated test coverage is often all you need.
I went back to read the year-old post he links to at the top, and it seems like his issue wasn't with pair programming, but with pair programming with poor communication skills and a crappy programmer partner.
For me it boils down to being able to fit the entire codebase into your head, or at the very least have it all written in your own voice. Reading code and packing it into your brain is the hardest part of programming, so having it all written in your own familiar style makes it really easy to get back up to speed on any bit of the project, even if you haven't visited it in a while.
Having even one other developer in there making changes can throw you out of speed-reading mode and make you stop and figure out what the other guy was thinking. That slows you down, and slowing down opens the door to distraction, which leads to bad things.
It gets really good when you're working by yourself on a project for which you're providing the direction. That removes the last roadblock from productivity, the "boss requested change".