7 ms·

Why I love solo programming (and why I hated working for Pivotal)

139 points by lladnar 16y ago

staunch 16y ago
Are there really companies that do all pair programming? Does Pivotal?
- tomstuart 16y ago
  There are many. For example: http://blog.obiefernandez.com/content/2008/08/the-hashrocket-way-pair-programming.html http://blog.obiefernandez.com/content/2008/08/the-hashrocket...
  - binbasti 16y ago
    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.
- philfreo 16y ago
  Pivotal definitely does all pair programming
- prateekdayal 16y ago
  http://www.eastagile.com http://www.eastagile.com does 100% pair programming too Disclaimer: I work there as a consultant every now and then
- neeleshs 16y ago
  Thoughtworks does, last I checked
  - duncanj 16y ago
    I'd be surprised if that were true, but things may have changed in 8 years.
- pashields 16y ago
  According to the guys I talked to at clojure-conj, most all work at Relevance is pair work. http://thinkrelevance.com/ http://thinkrelevance.com/
- dan_manges 16y ago
  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 http://getbraintree.com ) is done in pairs.
- getsat 16y ago
  GetSatisfaction uses pair programming exclusively.
defdac 16y ago
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.
- gruseom 16y ago
  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.
  - kayoone 16y ago
    Well since you should change your partner at least once a day, it is about shoving around people ;)
    - gruseom 16y ago
fookyong 16y ago
"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.
ericHosick 16y ago
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. My two cents.
- danparsonson 16y ago
  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. Likewise TDD (famously: http://www.infoq.com/news/2007/05/tdd-sudoku http://www.infoq.com/news/2007/05/tdd-sudoku), Agile, etc. None of these things is a panacea, but they can be very effective if thoughtfully applied.
jasonkester 16y ago
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".
- agentultra 16y ago
  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.
  - zeemonkee 16y ago
    Document, comment appropriately and write tests. The engineer in question might be yourself, six months or a year later, and you will have completely forgotten what you were doing back then.
- rue 16y ago
  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.
tptacek 16y ago
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.
- steveklabnik 16y ago
  It's a quality differentiator. You may pay a bit more, but you're guaranteed to get excellent code. (This is what they'd say, at least. I like pairing, but I don't know if I'd be comfortable making an absolutist statement like that.)
  - tptacek 16y ago
    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).
    - fizx 16y ago
      Other advantages include avoiding knowledge siloing, and integrating/teaching junior devs.
      - tptacek 16y ago
        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.)
    - samd 16y ago
      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.
mcantor 16y ago
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.
agentultra 16y ago
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. In other words, good luck with that.
- rue 16y ago
  Maybe you should try it with someone you get along with well first?
  - JoeAltmaier 16y ago
    You are lucky to find that person once or twice in a career. Its like video gaming - either you can run circles around them, or they around you. Its really rare to find a good match. Now compare with programming - its wellknown that skills in this arena range from 1 to 1,000,000. The chances of a good match nearly disappear.
    - rue 16y ago
      I am not sure I understand your argument. I am not talking about a soulmate here, just someone who does not freak the parent out sitting next to them…
      - JoeAltmaier 16y ago
        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.
- ams6110 16y ago
spidaman 16y ago
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.
- codeglomeration 16y ago
  Multiple contributors does not necessarily mean pair programming.
  - spidaman 16y ago
    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.
codeglomeration 16y ago
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.
- ollysb 16y ago
  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.
rickmode 16y ago
There more to life than money. It's thought provoking and inspiring to see someone putting this into action.

139 points by lladnar 16y ago

staunch 16y ago

Are there really companies that do all pair programming? Does Pivotal?

tomstuart 16y ago
There are many. For example: http://blog.obiefernandez.com/content/2008/08/the-hashrocket-way-pair-programming.html http://blog.obiefernandez.com/content/2008/08/the-hashrocket...
- binbasti 16y ago
  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.
philfreo 16y ago
Pivotal definitely does all pair programming
prateekdayal 16y ago
http://www.eastagile.com http://www.eastagile.com does 100% pair programming too Disclaimer: I work there as a consultant every now and then
neeleshs 16y ago
Thoughtworks does, last I checked
- duncanj 16y ago
  I'd be surprised if that were true, but things may have changed in 8 years.
pashields 16y ago
According to the guys I talked to at clojure-conj, most all work at Relevance is pair work. http://thinkrelevance.com/ http://thinkrelevance.com/
dan_manges 16y ago
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 http://getbraintree.com ) is done in pairs.
getsat 16y ago
GetSatisfaction uses pair programming exclusively.

defdac 16y ago

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.

gruseom 16y ago
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.
- kayoone 16y ago
  Well since you should change your partner at least once a day, it is about shoving around people ;)
  - gruseom 16y ago

fookyong 16y ago

"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.

ericHosick 16y ago

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. My two cents.

danparsonson 16y ago
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. Likewise TDD (famously: http://www.infoq.com/news/2007/05/tdd-sudoku http://www.infoq.com/news/2007/05/tdd-sudoku), Agile, etc. None of these things is a panacea, but they can be very effective if thoughtfully applied.

jasonkester 16y ago

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".

agentultra 16y ago
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.
- zeemonkee 16y ago
  Document, comment appropriately and write tests. The engineer in question might be yourself, six months or a year later, and you will have completely forgotten what you were doing back then.
rue 16y ago
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.

tptacek 16y ago

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.

steveklabnik 16y ago
It's a quality differentiator. You may pay a bit more, but you're guaranteed to get excellent code. (This is what they'd say, at least. I like pairing, but I don't know if I'd be comfortable making an absolutist statement like that.)
- tptacek 16y ago
  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).
  - fizx 16y ago
    Other advantages include avoiding knowledge siloing, and integrating/teaching junior devs.
    - tptacek 16y ago
      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.)
  - samd 16y ago
    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.

mcantor 16y ago

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.

agentultra 16y ago

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. In other words, good luck with that.

rue 16y ago
Maybe you should try it with someone you get along with well first?
- JoeAltmaier 16y ago
  You are lucky to find that person once or twice in a career. Its like video gaming - either you can run circles around them, or they around you. Its really rare to find a good match. Now compare with programming - its wellknown that skills in this arena range from 1 to 1,000,000. The chances of a good match nearly disappear.
  - rue 16y ago
    I am not sure I understand your argument. I am not talking about a soulmate here, just someone who does not freak the parent out sitting next to them…
    - JoeAltmaier 16y ago
      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.
ams6110 16y ago

spidaman 16y ago

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.

codeglomeration 16y ago
Multiple contributors does not necessarily mean pair programming.
- spidaman 16y ago
  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.

codeglomeration 16y ago

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.

ollysb 16y ago
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.

rickmode 16y ago

There more to life than money. It's thought provoking and inspiring to see someone putting this into action.