Lonely Coding
Sponsored By
It's official. I'm a better programmer when I'm pairing with someone. Pair Programming (two people, one keyboard) has been around for at least 20+ years, if not much longer. Usually one person types while another person (paces around and) thinks. It is kind of a "driver and navigator" model.
Everyone is different, to be clear, so it's very possible that you are the kind of person who can disappear into a closet for 8 hours and emerge with code, triumphant. I've done this before. Some of my best projects have involved me coding alone and that's fine.
However, just has we know that "diverse teams make for better projects," the same is true in my experience when coding on specific problems. Diversity isn't just color and gender, etc, it's as much background, age, personal history, work experience, expertise, programming language of choice, heck, it's even google-ability, and more!
How many times have you banged your head against a wall while coding only to have a friend or co-worker find the answer on their first web search?
Good pair programming is like that. Those ah-ha moments happen more often and you'll feel more than twice as productive in a pair.
In fact, I'm trying to pair for an hour every week remotely. Mark Downie and I have been pairing on DasBlog on and off for a year or so now in fits and starts. It's great. Just last week he and I were trying to crack one problem using regular expressions (yes, then we had two problems) and because there were two of us looking at the code it was solved!
Why is pair programming better?
Here's a few reasons why I think Pair Programming is very often better.
- Focus and Discipline - We set aside specific times and we sprint. We don't chat, we don't delete email, we code. And we also code with a specific goal or endpoint in mind.
- Collective ownership - I feel like we own the code together. I feel less ego about the code. Our hacks are our hacks, and our successes are shared.
- Personal growth - We mentor each other. We learn and we watch how the other moves around the code. I've learned new techniques, new hotkeys, and new algorithms.
Let's talk about the remote aspect of things. I'm remote. I also like to poke around on non-work-related tech on the side, as do many of us. Can I pair program remotely as well? Absolutely. I start with Skype, but I also use Google Hangouts, Join.me, TeamViewer, whatever works that day.
If you're a remote person on a larger team, consider remote pair programming. If you're an consultant or perhaps you've left a big corporate job to strike off on your own, you might be lonely. Seriously, ask yourself that hard question. It's no fun to realize or have to declare you're a lonely coder, but I am and I will. I love my job and I love my team but if I go a day or two without seeing another human or spending some serious time on Skype I get really tense. Remote pair programming can really reduce that feeling of lonely coding.
I was at a small tech get together in Atlanta a few days ago and I knew that one person there was a singular coder at their small business while another at the table was an emerging college student with an emerging talent. I made a gentle suggestion that maybe they consider pairing up on some side projects and they both lit up.
Consider your networks. Are there people you've met at conferences or at local user groups or meetups that might be good remote pairing partners? This might be the missing link for you. It was for me!
Do you pair? Do you pair remotely? Let us all know in the comments.
* Stock photo purchased from ColorStock - Your customers are diverse, why aren't your stock photos?
Sponsor: Big thanks to Telerik for sponsoring the feed this week. Try Kendo UI by Progress: The most complete set of HTML5 UI widgets and JavaScript app tools helping you cut development time.
About Scott
Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.
About Newsletter
Hosting By
October 01, 2016 2:34
Had 8 to 10 year olds pair programming in my Code Club this week using dual screens (instructions on one, code on another). Took 15 mins for them to get used to it but worked really well in the end with *much* better cooperation (and less questions for me!).
Paul F
I think there's a huge difference between being the only person in your work environment who codes (team of one, or a remote worker) and coding by yourself, in a team of coders.
Personally i find the pair programming to be challenging beyond belief, given my introverted nature. It feels like an invasion of my personal space, and I feel not as though I'm contributing to anything, so much as being analysed critically.
I prefer to code alone, and I have no problem at all with focus even I do. When I pair, I feel LESS focused in fact as I'm constantly worried about what the other person is going to think of my code, and my coding habits.
These are just a couple of reasons why I don't pair. I've got others, but they tend to be, I guess, personality effects. I'm not built to code in a pair, but I'll happily declare that I can write great code solo, and I work very well as part of a team.
I guess my point is that it's not for everyone, and while it's a real benefit to some, you should absolutely NEVER assume that it's going to work for everyone.
Personally i find the pair programming to be challenging beyond belief, given my introverted nature. It feels like an invasion of my personal space, and I feel not as though I'm contributing to anything, so much as being analysed critically.
I prefer to code alone, and I have no problem at all with focus even I do. When I pair, I feel LESS focused in fact as I'm constantly worried about what the other person is going to think of my code, and my coding habits.
These are just a couple of reasons why I don't pair. I've got others, but they tend to be, I guess, personality effects. I'm not built to code in a pair, but I'll happily declare that I can write great code solo, and I work very well as part of a team.
I guess my point is that it's not for everyone, and while it's a real benefit to some, you should absolutely NEVER assume that it's going to work for everyone.
I haven't done pair programming, but in my previous job we would share screens via Skype or GoToMeeting on calls pretty often, which was pretty helpful to see how others would work and we could share ideas and help each other, all while getting our own work done on a second monitor at the same time. It was quite efficient. I can imagine that a pair programming experience with shared monitors would also be nice.
@Scott Not only did our eyes light up, we've actually met and plan to collaborate on some things. I can't express the invigoration felt having that other mind to just bounce ideas off of. It almost as if they were those missing pairs of socks that were found at the bottom of the hamper (if that's a good analogy) :)
Never found pair programming helpful in any way, done it multiple times with multiple teams. Now peer reviews, are extremely useful on the other hand!
I've pair programmed before, and although I admit my partner and I may get more done together than I would have by myself, I'm not convinced we were *twice* as productive. That is, I don't know that we accomplished more together than the total productivity of two people each working alone.
I also find it frustrating sometimes, as I have a hard time both listening to someone talk and also reading code at the same time. And I can never really get into a good flow state when I'm interacting with another person so much. When I'm in "flow", I feel invigorated and energized at the end of the day. When I can't get into "flow", I often feel exhausted by the time I go home.
I do think pair programming has value for sharing knowledge. I'd recommend pair programming for an experienced programmer mentoring a junior, a new employee who needs to learn the system, or for anyone who's just plain stuck and needs a second pair of eyes on their design. In the latter case, pair programming can be like a sort of corroborative code review. However, assuming I and my prospective partner are both familiar with the system, have similar experience and skills, and don't have any roadblocks, I feel I'm better off working on my own.
I also find it frustrating sometimes, as I have a hard time both listening to someone talk and also reading code at the same time. And I can never really get into a good flow state when I'm interacting with another person so much. When I'm in "flow", I feel invigorated and energized at the end of the day. When I can't get into "flow", I often feel exhausted by the time I go home.
I do think pair programming has value for sharing knowledge. I'd recommend pair programming for an experienced programmer mentoring a junior, a new employee who needs to learn the system, or for anyone who's just plain stuck and needs a second pair of eyes on their design. In the latter case, pair programming can be like a sort of corroborative code review. However, assuming I and my prospective partner are both familiar with the system, have similar experience and skills, and don't have any roadblocks, I feel I'm better off working on my own.
A side effect people not think about is that pair programming is "active learning" it mean you remember better and there by learn more also, so it must be very good for Schools.
Personally I think all smart ideas and solutions come when you relaxed home and have all good ideas for next day.
So if pair programming is something good can be if you feel relaxed and feel if it free up the load for brain by being two.
Personally I think all smart ideas and solutions come when you relaxed home and have all good ideas for next day.
So if pair programming is something good can be if you feel relaxed and feel if it free up the load for brain by being two.
@Joshua Carmody - I think pair programming shouldn't be thought of as being twice as productive in the near term or quantifiable quite that way.
The goal is information sharing, democratizing ownership of code as Scott mentioned in the post, but also improving maintainability and reducing chances of bugs, handling edge cases, etc. It's more man hours invested up front to save potential totally many more, critical bugs oremergencies, data loss, revenue loss, angry customers etc.
I pair extensively on a legacy, convoluted, spaghetti, brittle code base. We're constantly catching things for each other that would have very real consequences. Code reviews are great, but you're head just isn't quite as deep in it.
The goal is information sharing, democratizing ownership of code as Scott mentioned in the post, but also improving maintainability and reducing chances of bugs, handling edge cases, etc. It's more man hours invested up front to save potential totally many more, critical bugs oremergencies, data loss, revenue loss, angry customers etc.
I pair extensively on a legacy, convoluted, spaghetti, brittle code base. We're constantly catching things for each other that would have very real consequences. Code reviews are great, but you're head just isn't quite as deep in it.
Did a course on Pair Programming Fundamentals on Pluralsight earlier this year. It's a great practice and I have several clients that have implemented it with good results.
I can't stand programming alone anymore. Once you really learn to pair well, anything else is slow, ineffective, and boring.
I even paired on the creation of a Pair Programming Fundamentals course on Pluralsight with Steve.
I even paired on the creation of a Pair Programming Fundamentals course on Pluralsight with Steve.
if there were 2 of me (don't worry, there are not AFAIK)
i would NOT want to pair program with myself.
perhaps it's because i'm in my 70th year...
more likely it's because of the way that i think...
or perhaps it's OCD...
or perhaps it's because i'm a control freak...
most likely, it's because i'm a typical Taurus.
i do my best to practice schizophrenic programming...
one me personality codes an application facing (a.k.a. programmer a.k.a unit) test
against some non-existent black box...
the other me personality codes the stuff for inside that black box.
what would be interesting would be if we could corral 3n sets of twins...
one third would pair program together,
one third would program as individuals, and
the last third would pair program with someone who is not their twin.
the results of such an experiment could contribute harder evidence
regarding the efficacy or lack thereof of pair programming.
i would NOT want to pair program with myself.
perhaps it's because i'm in my 70th year...
more likely it's because of the way that i think...
or perhaps it's OCD...
or perhaps it's because i'm a control freak...
most likely, it's because i'm a typical Taurus.
i do my best to practice schizophrenic programming...
one me personality codes an application facing (a.k.a. programmer a.k.a unit) test
against some non-existent black box...
the other me personality codes the stuff for inside that black box.
what would be interesting would be if we could corral 3n sets of twins...
one third would pair program together,
one third would program as individuals, and
the last third would pair program with someone who is not their twin.
the results of such an experiment could contribute harder evidence
regarding the efficacy or lack thereof of pair programming.
followup: was the commenting capability of this blog create by paired programmers?
if not, perhaps it should have been ... it was written SINGLE SPACED but is rendered DOUBLE SPACE.
test:
SINGLE SPACE line 1
SINGLE SPACE line 2
SINGLE SPACE line 3
if not, perhaps it should have been ... it was written SINGLE SPACED but is rendered DOUBLE SPACE.
test:
SINGLE SPACE line 1
SINGLE SPACE line 2
SINGLE SPACE line 3
Scott, have you seen Atlassian's tutorial on Pair Programming?
https://www.youtube.com/watch?v=dYBjVTMUQY0
https://www.youtube.com/watch?v=dYBjVTMUQY0
I used to apply eXP practices (including pair programming of course) a lot in the past, in the onsite office part of my career. And now, working for many years remotely, never tried it. I really like the idea. Thank you, Scott!
Yes I pair, whenever I can. Best way to learn and rethink your solution. Currently introducing some new tech on a project, while introducing a new dev to the project. Pairing works really great. If we have something we need to solve, we might double up on google :) and then try different solutions, but best of all, we celebrate together whenever we reach a goal, can be anything small, but it really feels great when pairing.
Pairing also makes your own brain work even more. After a day of pairing you can feel positively wasted, but good at the same time.
Pair whenever you get the chance to do so. it's a great way to learn find a good solution.
Pairing also makes your own brain work even more. After a day of pairing you can feel positively wasted, but good at the same time.
Pair whenever you get the chance to do so. it's a great way to learn find a good solution.
Alistair Cockburn released a paper proving that Pair Programming is highly beneficial!
http://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF
http://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF
I work at a company where developers pair all the time and I've been doing this for over two years now. I am also a full time remote worker in a team that has both office based workers and remote workers. I love coding solo (especially if spiking something), but I see that pairing has huge benefits for the developers and the company.
Pairing helps us find potential issues with our code earlier than if we were solo (in software, it's much cheaper to fix early than later).
Pairing means more than one person has deep knowledge of the code _before_ it's checked in.
Pairing means I can learn from my co-workers as I go along, often finding that human knowledge sharing is faster/better than researching.
Pairing remotely using a screen sharing is a fantastic experience - you can both be sitting/standing at your own desks and looking straight at the code in question. If you need to have another view onto the code - say when one pair is researching something - then you can do that without disturbing the flow of your pair partner.
Slightly off topic, but we also regularly bring our testers in for a review _before_ we check in. Getting tester input at this early stage is valuable for the dev pair and often highlights areas for improvement. It also helps us be sure that the tests we've written are correctly targeted and adjust if needed.
Pairing helps us find potential issues with our code earlier than if we were solo (in software, it's much cheaper to fix early than later).
Pairing means more than one person has deep knowledge of the code _before_ it's checked in.
Pairing means I can learn from my co-workers as I go along, often finding that human knowledge sharing is faster/better than researching.
Pairing remotely using a screen sharing is a fantastic experience - you can both be sitting/standing at your own desks and looking straight at the code in question. If you need to have another view onto the code - say when one pair is researching something - then you can do that without disturbing the flow of your pair partner.
Slightly off topic, but we also regularly bring our testers in for a review _before_ we check in. Getting tester input at this early stage is valuable for the dev pair and often highlights areas for improvement. It also helps us be sure that the tests we've written are correctly targeted and adjust if needed.
Hi,
I would love to find a person who enjoys pair programming. I have been doing development only for 2 years and when you are new to programming there are so many unknowns. Because I truly care about code and see it as a craft often times I wish I had a person who would check the code and give me advice on best practices and explain the whys and since I had pair programming couple of times in meetup events I noticed I learned so much more and so much faster. All I want is to write a quality code and if someone has a passion for teaching and guiding because it is beneficial to them as well, please leave a comment and we can start any project or contribute together to any open source.
I would love to find a person who enjoys pair programming. I have been doing development only for 2 years and when you are new to programming there are so many unknowns. Because I truly care about code and see it as a craft often times I wish I had a person who would check the code and give me advice on best practices and explain the whys and since I had pair programming couple of times in meetup events I noticed I learned so much more and so much faster. All I want is to write a quality code and if someone has a passion for teaching and guiding because it is beneficial to them as well, please leave a comment and we can start any project or contribute together to any open source.
i used to pair programming in my previous job and i find really all the things that make 2 people better than 1.
I think pairing and as one other person mentioned code reviews, both help make better quality software. I heard recently in a speech by one of my new overlords that it "works best" between "seniors" and "juniors". I call BS on that. I think it works best for any two people, because every person views these challenges in different ways. I had been on a team that did a lot of both pairing and code reviewing and it helps more than most managers would possibly know, but they frequently think two people on one task is a waste. Most people who have had success with this technique know that two minds are better than one. The result of this is usually way better than either one person would have output on their own, also code reviews, or what might be thought of as "distributed pairing" can be just as valuable or even more so again, regardless of the skill level of either party. Great article!
Whilst I've not done pairing much I have always bounced ideas and issues off of others.
In my current job the dev team is exactly me and I feel like it's the least productive I've been in years. Any issues are stuck with me banging my head against a wall to figure them out, no help, no one to explain the issue to and suddenlt realise the fix mid sentence.
Worse is the fact I'm a lone programmer in a room of IT people. The atmosphere is all wrong and I feel alone in a room full of people, and I seem to be making the gap wider. It must only be a matter of time before something gives.
In my current job the dev team is exactly me and I feel like it's the least productive I've been in years. Any issues are stuck with me banging my head against a wall to figure them out, no help, no one to explain the issue to and suddenlt realise the fix mid sentence.
Worse is the fact I'm a lone programmer in a room of IT people. The atmosphere is all wrong and I feel alone in a room full of people, and I seem to be making the gap wider. It must only be a matter of time before something gives.
My personal view on pairing is to keep it up to the bare minimum.
I believe that pull-requests with "peer reviewing" provides more code quality (as more people will be able to look at the changes you are trying to check in) than just having two people (the pair) review their own changes and check that in directly into the codebase.
A specific recent project I worked on enforced "religious pairing”, but I was the only senior amongst a small group of developers that were technically of beginner/junior level. As one would expect, the resulting code quality was quite low given the lack of knowledge of the platform, tools, patterns and practices.
If on the other hand you have a team of seasoned, experience developers who know what they are doing, what will pairing accomplish there? Tech discussion are quite useful and can be had without the need to pair with another person.
Then you have personality differences, different setups, different schedules, etc. How do you handle all of those? I personally like to use my own machine, set up with my own tools and settings, and going to work on someone’s else machine just feels like an impediment as I have to learn how that person works and try do adapt.
One thing is for sure: pairing has to be something that EVERYONE on the team wants to do, and not something you can enforce on others just because that’s a decision by the majority. That’s just asking for problems, as you’ll always find yourself with a bunch of unhappy devs!
I believe that pull-requests with "peer reviewing" provides more code quality (as more people will be able to look at the changes you are trying to check in) than just having two people (the pair) review their own changes and check that in directly into the codebase.
A specific recent project I worked on enforced "religious pairing”, but I was the only senior amongst a small group of developers that were technically of beginner/junior level. As one would expect, the resulting code quality was quite low given the lack of knowledge of the platform, tools, patterns and practices.
If on the other hand you have a team of seasoned, experience developers who know what they are doing, what will pairing accomplish there? Tech discussion are quite useful and can be had without the need to pair with another person.
Then you have personality differences, different setups, different schedules, etc. How do you handle all of those? I personally like to use my own machine, set up with my own tools and settings, and going to work on someone’s else machine just feels like an impediment as I have to learn how that person works and try do adapt.
One thing is for sure: pairing has to be something that EVERYONE on the team wants to do, and not something you can enforce on others just because that’s a decision by the majority. That’s just asking for problems, as you’ll always find yourself with a bunch of unhappy devs!
Admittedly, I've only tried pair programming a few times and it was many years ago. I definitely see the value of sitting down together with another developer when looking at a specific problem and working together. And I've definitely picked up tricks and shortcuts. But I never quite bought into the practice of pair programming for its own sake. Part of its probably ego and introversion, but it also just seems inefficient and frankly boring watching someone else type.
The fact that we don't see other disciplines with a similar practice makes me suspicious. I don't see pair accounting, or pair plumbing, pair architecture, or pair sculpting. What's the unique character of programming that requires pair programming?
The fact that we don't see other disciplines with a similar practice makes me suspicious. I don't see pair accounting, or pair plumbing, pair architecture, or pair sculpting. What's the unique character of programming that requires pair programming?
Nothing beets pairing as a nut-cracker.
In my team we got a dedicated machine with dual keyboards and screens.
I have problems understanding that people see nothing positive in pairing. I will not go into that discussion because I think it will be a discussion about people not pairing. :p
On the other hand solo-diving is often extremely satisfying. :)
Happy coding.
In my team we got a dedicated machine with dual keyboards and screens.
I have problems understanding that people see nothing positive in pairing. I will not go into that discussion because I think it will be a discussion about people not pairing. :p
On the other hand solo-diving is often extremely satisfying. :)
Happy coding.
@Jason Nappi
Perhaps there should be pair accounting, pair plumbing, etc. I don't even want to count the number of times my accountant has screwed something up only for me to have to find it, or the plumber doing a crappy job. Two heads are always better than one.
Perhaps there should be pair accounting, pair plumbing, etc. I don't even want to count the number of times my accountant has screwed something up only for me to have to find it, or the plumber doing a crappy job. Two heads are always better than one.
I've been working as solo developer/consultant for 27 years. I'm lucky to have only rarely suffered from loneliness but when it does hit it hits hard. During those times, and others, I yearned for a service to connect remote people together in a virtual presence together via Skype, hangouts, etc. Is there such a service?
I do a fair amount of pair programming both at work and with my spouse on side projects and I have found that even if I am in the same room with my partner using a remote tool (Zoom is my current preferred) for screen-share is more natural than the two of us looking at the same screen.
My team at work also does an hour a day of Mob-Programming where all work on a piece of code together. This helps us stay on the same page and learn from each other.
My team at work also does an hour a day of Mob-Programming where all work on a piece of code together. This helps us stay on the same page and learn from each other.
I really like Screenhero for pair programming remotely, mostly because it has support for dual mouse cursors as well as built-in audio chat. Unfortunately, it's closed to new signups unless you are a paid Slack user.
Dude! "at a small tech gathering in Atlanta" ... how can I register for your location beacon?
I'd love to see you at a tech gathering in Atlanta the next time you're in town.
-D
I'd love to see you at a tech gathering in Atlanta the next time you're in town.
-D
Nothing worse than pair programming. Being shackled to some lazy person with lots of good ideas for what other people should do. A good way to slow productivity to a crawl.
I agree pair programming is good & has advantages to take 360 degree view of a problem. Couple of things I struggle in this model is:
- How to convince business guys that two folks work on a single story?
- Your pair shall be good programmer & frequency shall match ..
I liked reading this article. Thanks for sharing
- How to convince business guys that two folks work on a single story?
- Your pair shall be good programmer & frequency shall match ..
I liked reading this article. Thanks for sharing
Pair programming, along with GitHub-style PR workflow, command-line source control and unit testing are what separates the kids table from the grownups table. I was muscled into making the transition by a very good manager. I was anxious and exhausted at first. I'm not accustomed to having anyone watch me work.
The benefits have been tremendous and in a lot of varied ways. I am now better at job interviews where I am expected to code in front of people. That was unexpected, but makes sense when you think about it.
It's a bummer when you have a personality conflict, though. You really dread that 4 hours spent hip-to-hip with someone that has a weird verbal affect or whose desk is gross.
The benefits have been tremendous and in a lot of varied ways. I am now better at job interviews where I am expected to code in front of people. That was unexpected, but makes sense when you think about it.
It's a bummer when you have a personality conflict, though. You really dread that 4 hours spent hip-to-hip with someone that has a weird verbal affect or whose desk is gross.
Comments are closed.