If it's sincere, I think the author is attacking a rather extreme position.
Sometimes I like to write code by myself. Sometimes I like to pair on stuff. It depends on a lot factors. Is it complicated code? Do I know the language/framework/codebase well? Do I have a peer who knows more than I do about the problem I'm trying to solve? Is it important that multiple people be able to maintain this code? Etc. Like most things, pairing is a trade-off. It can have benefits, but it costs twice as much to write code.
That said, I think most people in our industry could benefit from pairing more, not less. Studies on pair programming show significant advantages in many circumstances [2]. If the author is sincere, I hope he'll keep an open mind about an occasional pairing session in the future.
> I don’t believe that I’m alone in my opinion. All of my colleagues are very similar. In my 20+ year long career, I’ve only known one person that I suspect would be comfortable with pair programming
So I can easily imagine that he was unlucky during his 20+ year career, because it is not easy to find such group of people especially in Age of Everyone Can Become a Programmer.
Add me to the unusually unlucky then. And all the guys I work with, or ever have worked with. At some point it becomes difficult to dismiss this opinion as 'someone who was unlucky'.
> Studies on pair programming show significant advantages in many circumstances
But do these studies take into account employee happiness (and thus potentially losing good developers)? In other words, is it better to have five mediocre engineers pair programming or having five stellar engineers working normally?
All agreed that PP promoted the formation of good team spirit in the beginning of the project. The information radiator and the open workspace were also mentioned as contributors to good team spirit. Two of the developers liked PP more than solo programming and two found no difference.
Please at least skim references before calling them into question.
Thank you, FWIW I had read the abstract...I don't normally read (or skim) the entirety of every study somebody cites. But taking your advice I noticed 7.2 contains:
All the developers were recruited based on their interest in using agile practices including PP
Personally I would prefer not working in a paired programming environment, though I'm not sure it would be a deal-breaker. But I know developers (more introverted than me) who I imagine it might be.
While it probably biases the numbers a bit, I don't fault the study for picking people who were receptive to new practices. Picking people randomly and forcing them to change practices would just cause resentment.
Even though I enjoy pairing, I also doubt I would enjoy working at a place that required people to pair. Rules like that irk me. They're often a symptom of other, bigger problems.
If he was insincere, let me assure you that I could make all the same assertions and be entirely sincere. Pair programming is for mediocre programmers who need a lot of support. As a highly productive programmer with decades of successful projects behind me, I can assure you that pair programming would be disastrously disruptive to me; in fact my entire team would bail if it were pushed upon us.
Sure, you wouldn't respond well if it was forced on you. But what if you tried it sincerely? What if your whole team said, "this week we're going to try an experiment." Don't nitpick or naysay, just try it and see. Your use of the word "would" is very telling that you haven't tried.
Its funny; imagining the folks oppose PP because they've never tried it. Like we've been in some sort of cocoon or glass jar all our lives.
Sure, I've had to endure somebody trying to 'help' when I have a hard problem to find. I spend my time explaining to the other guy, bringing them up to speed. And they spend their time suggesting things that have already been done, or suggesting using some buzzword toolchain like it will solve all the problems.
If I were churning out web logic or designing dialogs or some such it can be useful I suppose - "You forgot a brace. Remember we have to try all these on the proto server first." etc.
But I spend my time on tricky problems in the core IP of our company. I've always had that job, wherever I work. And let me tell you, having someone in the same room is a no-go for the hours of mental model-building it takes to diagnose or design these kind components.
Now, let admit there are different kinds of programming jobs. Maybe the bulk of web design etc is amenable to having two shovels in the same ditch - of course you'd get more done, its obvious! But for other tasks it is absolutely not going to help.
Ouch. It sounds like the skill and/or knowledge discrepancy was too great. I've been in that situation before. If it doesn't get better after about 30 minutes, I say something like, "I don't think this is working out. Let's split up." If possible, I try to suggest something else to work on separately.
When it comes to code complexity, meta-studies argue against your claim. Pairing isn't worthwhile for simple code, but it's great for reducing defects in complex code:
The benefit of pairing is greatest on tasks that the programmers do not fully understand before they begin: that is, challenging tasks that call for creativity and sophistication.[1]
I and most everyone I've paired with have found this to be the case in our own work.
A side note: I'm not sure what your core argument is. Most of your comments in this thread seem to be a combination of self-aggrandizement, personal opinion, and veiled insults towards those who pair. I've tried to keep my own comments civil and evidence-based, but many others in this thread are full of negativity. It makes me sad.
Sorry if I'm being insulting. I get that way when responding in kind.
There does seem to be more emotion than logic expressed here. I've meant to try to counter this with sincere expressions of my experiences. I must have gotten emotional in return. I'm at my wits end, trying to counter the simplistic claims of PP proponents that everyone else is a cowboy or just too inexperienced to 'get it'. I get it, I don't like it, I can see constant refutation of the whole idea of PP in my team.
That sure sounds like a piece of work where a design discussion is necessary. However, I would not call a design discussion, pair programming. Find one or two others to help you hash out a design, but once you understand the problem, there is no need to pair program. Just build it, and call on the same people to do code review after you have built it.
A good professional engineering environment where you start a sprint by having a design discussion with peers, and then come back to your peers on the tail end of the sprint for code review, is likely to provide all the same benefits as pair programming.
After all, this is not supposed to be a software factory. Developing software is engineering work, and designing the work well, with your peers, will do just as much to strengthen the team and it will also improve the work quality.
Working in pairs is useful in bringing junior people up to the next level, and in helping newcomers learn the problem domain or the platform/framework that you use, but it is not a universal good practice that you would use all the time.
> I can assure you that pair programming would be disastrously disruptive to me
And so you refuse to do it even if it would be tremendous help for the other person. You won't pair with a colleague, because you don't like it, because it would "disrupt your work", even though you could cause the other person to become much more productive in much shorter time. You're not only being a jerk by doing so, you're actually undermining your project and putting your "decades of successful projects" at risk.
Yeah, highly rational decision, based on your dislike of (as per OP) interacting with other people. I'm so happy I never met you.
Projecting. I help other programmers routinely; I mentor high school students; I run architecture meetings for the group.
I don't get anything done if I'm made to waste large portions of my day hand-holding other programmers. My work is best done in a silent room with hours uninterrupted.
I'm sure you'd be glad to meet me; I don't dislike interaction at all. Lets just do it at a coffee shop.
As a student, I support pair programming. Last semester, we did a six-man project building an client-server battleships game that offered singleplayer and multiplayer.
We had to create a strategy to manage the quality of the project and chose a task-based pair programming strategy. In those student projects it is often the case, that the better students do a rather big portion of the project while the others try to keep up.
With pair programming this was not the case. Everyone developed on a similar level. Yes, it probably slowed down some of the developers, but for a student project, the main goal is to learn. And pair programming was a way to do that.
Also, our project quality really benefitted from this. After developing the basic server, client and game logic, we switched teams to do the next step. For example, the team that connected the client to the server would now have a person that knows the server side and one that ones the client side. This team changing was done on a regular basis and helped putting the software together. There were less problems with the code of different people working together than in most other projects and I believe, that pair programming was a big factor in that.
So, I can't speak for the work environment, but for learning to be a software developer, it really was a good experience.
This varies by the person. The author wasn't necessarily discounting the performance wins from pairing. The point was that it's not a good solution for the classic introvert programmer. If socialization is something you feel comfortable with, this may not apply to you.
You're arguing a point unrelated to the post. The author is saying that as a highly competent SE, paired programming would be a detriment to him due to his personality etc.
I know you're not agreeing in this statement, but I think part of anyones role as a senior SE is to help raise others to that level, even if it's to the detriment of his own productivity.
Well a cynic would say that in the case of the student assignment it was more about forcing everyone to put in the same number of hours than it was about efficient knowledge transfer.
Yes I too am an introvert. But saying pair programming doesn't work with introverts is not quite right. Introverts are not no-talkers, they like talking about stuff that they love. They don't come out and talk, but are truthful if you ask questions. So as a programmer introvert, I love discussing about programming, new tools and languages, etc.
Its OK if you hate Pair Programming. Its even OK if you hate it without even trying it. But just don't generalize it with being an introvert.
This works when it works. But when it doesn't, it can be challenging. If you tend to be paired with those who are argumentative, it can be a bristling experience. Or if you're a 9 and you're paired with a 4. (whether it's true or in your own head, it's the same effect)
don't confuse being shy with being an introvert. Introversion has nothing to do with enjoying talking to people. it is actually about where you get your energy... for e.g do you feel exhausted after a day of social interactions and need alone time? or do you feel energized and are ready to hit the town? introverts would typically need aone time off to 'recharge'..
Part of writing good software is the ability to interact with people. That requires certain social abilities and the ability to talk confidently to people about code, the same as pair programming.
Truly introverted developers may write elegant and beautiful code, but they generally need an abstraction layer between them and the user/customer, which can cause the most beautiful code to be wrong, because it doesn't fulfil the requirement.
Pairing with people improves code quality by forcing you to explain your decisions, allowing you a better understanding of what you write, sharing knowledge of the codebase across the team, and preventing tangents that aren't what the client wants. It's not just about being more productive -- my personal opinion is it's actually slower than 2 developers working separately -- but that doesn't make it less worthwhile.
I think you're missing the point of the article. The core of it is essentially: "being happy is one of the most important things in my life, and pair programming would make me unhappy; therefore I will not do it."
Yes, he does try to rationalize a little bit here and there, but overall I think that's it.
I don't at all believe that pair programming necessarily gives you a better end product. I think it can, but I think it depends a lot on the project and individuals involved. Personally I'm not a fan. I'm not quite the hater that the OP is, but I, too, would likely look for a new job if my company suddenly required regular pair programming of everyone.
I think I'm pretty damn good at what I do. That's obviously a subjective statement, but I could back it up with some facts that would seem to indicate I know what I'm doing. If I paired with someone on certain projects, would it create a better outcome? I'm not sure. Maybe it would. Maybe it wouldn't. But I really don't care, because I'm certain I wouldn't enjoy the process. Does that potentially limit my greatness as a developer? Maybe. Maybe not. But that's where the happiness thing comes in. If pairing truly could make me a better developer, and there's nothing else that could, then I'm honestly totally fine not being the best developer I could be, because I wouldn't be happy while practicing my craft.
As an aside: I'm talking about two peers of roughly the same skill pairing. I'd be happy to pair with a junior dev for the purposes of mentorship or knowledge transfer. Actually, I think pairing with anyone for the purpose of knowledge transfer is probably a good thing. I just wouldn't enjoy pairing as a fundamental part of working on a project.
You are falling right into the trap of dismissing all non-agile PP people as 'cowboys'. Its unfair to go from 'don't want to spend the day explaining myself to a newbie and disrupting my train of though' to 'total introvert loose cannon'
At work we have a consultant in at the moment doing technical mentoring. He's gone right back to basics on a lot of stuff, unit testing, TDD, refactoring, pair programming etc. For a while it felt like a waste of time, I didn't need to be doing this etc. But a realisation is growing on me.
Shared understanding is vital, even more so in a team of "left brain" introverts. Whether it is establishing what everyone thinks TDD to be and the metrics to be extracted. Or whether it is making sure that at least one other person knows what your code does, that it is the best way of doing it, that you're not taking shortcuts or making "clever solutions" that aren't needed and sacrifice maintainability.
Being a professional isn't about being dismissive of 9 to 5 paycheck developers and their skills whilst slamming out loads of code. If your experience is all of introverts who want to be left alone I dread to think what your code review practices are like...
> At work we have a consultant in at the moment doing technical mentoring. He's gone right back to basics on a lot of stuff
How did you go around to finding him? I feel we really need that where I work, go back to basics and take up some "good habits"[0], but without a consultant/trainer to suggest it feels like whining without contributing. Attempting cultural changes internally on a suggestion basis doesn't really work, people (me included) just go back to their previous stable state.
[0] both small scale, the testing and refactoring stuff, and larger-scale with system architecture.
If you're going to shop around for a change agent, I recommend reading Jerry Weinberg's "Secrets of Consulting"; although this is targeted at consultants rather than their clients, it can provide useful insight into how to create an effective working partnership with one.
Technical know-how doesn't by itself qualify someone to help you implement changes towards becoming more effective. It can be detrimental, in fact.
But someone with a solid grasp of the fundamentals AND a productive attitude to coaching/mentoring/consulting can be a great asset. One I recommend wholeheartedly is JB: http://blog.thecodewhisperer.com/ (and if you can't get him, try to find someone like him).
I understand your frustration with trying to do this "internally", but stay positive and keep with it. If you (and like minded supporters) keep talking about "best practices", your peers _will_ notice and _will_ start playing with them in their work.
At our workplace, we have a monthly hour-long "Lunch and Learn" where we all meet to do three things: listen to someone share some interesting code they worked on that month (which helps to generate some enthusiasm and spread some knowledge around); talk together about a specific best-practice; collectively review some code with a focus on using that best-practice to improve the code. It is a very simple, low-cost, low-time-cost way to formalize the fact that you want everyone to pay attention to these things, and (in our case) has really stimulated a desire among the developers to improve their code practice.
To implement this, put someone in charge (or take charge yourself :) and just start asking people to contribute. You will probably find there is a lot more interest in this than you think.
Also, be sure to go easy on yourself and your peers as you try to change habits. If you look back at code you wrote, say, three years ago, you will probably say to yourself, "What was I thinking? I could write that so much better now." In the same way, three years from now you will be able to say, "What was I thinking? I could [test|commit|organize|pair-program|etc] that so much better now."
Cheers - I actually had a really good conversation in the pub on Friday with some other relatively junior staff, and we all came to a much better understanding of our goals and motivations, and how closely aligned they are.
It really drives the point - the social connections are what makes or breaks you in an organisation. Any meaningful change needs allies, needs to persuade people, and needs to deal with ego and politics. The people responsible for what you want to change are probably those currently in management roles! It's probably one of the harder transitions from academic/training when there are absolute truths, to business where things become much more complex.
Sadly it's a bit of a crapshoot. The two consultants we have in at the moment are both brilliant, but we've had a shocking one from the same firm previously, who is probably responsible for a lot of our previous problems.
The best advice I can give is to find someone/a firm who hires people who switch between doing and consulting. It's a bit like the old "those who can do, those who can't, teach". Having someone with loads of current practical experience convinces the tech types to go along with their proposal. Having someone with "expert" consultant credentials persuades management to go with something. Which is frustrating when an employee has been suggesting the same thing for ages, but a massive bill is convincing...
The other top tip - especially if they are from out of town and thus staying over - invite them to the pub at the end of day one. They want to hear the gripes of those at the coal face.
Why put words in the author's mouth? He's talking about one specific thing he doesn't like. He hasn't given us any indication of his feelings on reviews, so there are no conclusions you can draw.
Even though I agree that pair programming is not necessary (I think it's useful, I sometimes do it and enjoy it, and sometimes I really need to work alone), I do not like how this post sounds. It does not sound like "pair programming is good, but I prefer to work alone and I think it's equally good", it's more like "I work for 20+ years in the industry and I'm highly qualified engineer and I don't want to work with people, so shut up all of you that try to encourage people to try different things". That does not prove any point, it's just a rant.
This whole article is predicated on the absurd straw man argument that there are legion pair programming evangelists ruining the software industry with their philosophy. In reality, even the people I know who practice pair programming only do so less than half the time. It's hardly an epidemic.
As an aside: I am pretty tired of people saying "I'm an introvert," when what they mean is "I'm an asshole." Even if you're introverted, you have the same responsibility as everyone else to communicate in order to get things done.
This whole article is predicated on the absurd straw man argument that there are legion pair programming evangelists ruining the software industry with their philosophy.
Not really. This is a guy who hates pair programming and believes it would make him unhappy. Full stop. Don't mistake his screed about how he'd quit programming if pairing were required with a belief that this is where the industry is going. That's merely language to show how much he really really really hates pair programming.
I am pretty tired of people saying "I'm an introvert," when what they mean is "I'm an asshole."
I think that's a bit harsh. Note that the article starts off with a warning that it's a rant: the author is admitting up-front that he's letting off some steam. Social interaction is a limited commodity for introverts. The author would likely prefer to spend his daily allotment of social interaction on what he'd consider more useful forms of workplace communication.
Well, somewhat. But I read other comments here and in at least three cases the posters were proudly describing themselves as assholes. The problem with all of them was that they never once realized that pairing may be done not for them, but for the other person (or them both). I thought it's common sense to consider all the people involved in the interaction. For those people it's not, it's only about how they feel and how they are influenced by pairing. I was very, very lucky (apparently) that I didn't meet any of them (or they didn't have the chance to manifest their attitude towards me - towards all of us) in my professional life.
This "fuck you all, whatever it may be I'm working" attitude may be tolerated in people who really contribute a lot. Their presence may be beneficial on the whole to the company or even to the team they're on. That doesn't mean they are not assholes - it just means that in our industry being a jerk is not disqualifying feature. I have no idea what they are so proud about, though.
I can say that that's actually somewhat of a real concern. There are companies that only program in pairs (pivotal for example) and others that try to emulate them. I have personally experienced pair programming being pushed as SOP.
Yet the vast majority of companies do not do pair programming as a matter of course. Just don't work for those companies if you don't like it.
I personally would like to try pair programming but none of the companies I have worked for would do it much. (Although the most productive time I had at my last job was a single pair programming session.)
That's not what's going on here. And I apologize for being pithy. My deeper point is that a few (ironically) vocal assholes make introverts look bad by using their supposed introversion as an excuse to be a dick.
"Asshole" is easily defined by someone who puts their interests in front of everything else. Both introverts and extroverts can be assholes .... or not.
> Even if you're introverted, you have the same responsibility as everyone else to communicate in order to get things done.
That goes both ways - if you're dealing with an introvert it might benefit you to communicate in a different style and with a different frequency. Some management books even provide models for quick and dirty social analysis so that people can do so. The model I've found most immediately applicable is:
Extroverted
|
Person focused ----- Task focused
|
Introverted
You can pick up on that sort of thing fairly easily, when people speak how loudly do they speak - do they project their voice? When they talk do they gesture a lot with their hands? When they talk is about things or people? Does their tone of voice alter when they talk about different areas - do the volunteer information as readily about those things, ask the same number of relevant questions?
I totally agree. You need to treat different people differently. However you shouldn't assume that just because you're an introvert or an extrovert that you should be exempt from having to invest your energy in interpersonal communication. It's what makes the world work.
I like to pair. I like to talk about pairing. I have worked with people who don't pair well. I worked with one person whose wife noticed that his entire personality changed for the worse when he tried to pair. He stopped pairing.
You don't like to pair. You don't want people to try to pair with you.
So far, I'm with you.
How do you get from there to "if you ever talk about pairing, you're incompetent and horrible"? I have trouble with that part.
Why such a rant at all? If you can't change your job, change your job. Luckily for you, pairing shops are in the vast minority, I'd guess you'd have to go out of your way to find another one no matter where you live.
It's the same as any software practice: TDD, which form of typing, vim/emacs/IDE, OO, etc. Without solid measurable proof that it's best for your specific job/domain/team (basically impossible) it's all just preference anyway. And someone who hates OO is going to constantly find ways why OO is terrible.
So we gather into jobs and teams that all share the same religious faith on all the above mentioned. Interviews are basically the same as you get in any church: do you believe these core faiths about our doctrine, and are you cool? Great, you're in!
Introverted programmers have always coded with other people, communicating through emails, code reviews, bug hunts, source control comments, phone calls, brainstorming and planning sessions. "Pair programming" seems to be a modern fetish to get wallflowers to dance together in hopes they'll both write better code. It's awkward for the introverted. Brain power that should be going towards code is siphoned off into social interaction. Coding is an inherently creative act, unless you're just stamping out boilerplate code at the software factory, in which case pairing makes sense.
In a good pairing session, you are almost unaware that there's any social interaction going on. You and your pair are both in the zone, applying more than double the brainpower to the problem. The old saying is true, two heads are better than one. The only reason it's not effective with more than two is that the realtime communication breaks down.
People talk a lot about pair programming, but when have you ever read about how to do it. What are the mechanics of it? What should a member of a pair do or not do? I suspect that a lot of the problem with pair programming boils down to people who don't know how to do it that end up creating a bad social interaction and offending their partner.
I think this is the nub of it: "the very small squeaky obnoxiously loud minority".
Most people really don't like being preached at, and the agile community is very preachy. They're also very certain that agile is best practice, while everything else is cowboy.
I'm confident at this point that a sizeable chunk of the agile mantra is pretty poor practice. TDD, for example, definitely seems worse than actually using your human intelligence to plan ahead and design.
I don't necessarily agree with this article. I think most programmers do want and benefit from some degree of collaboration on problems. Mostly at the start when they're figuring out what they should actually build. I certainly sympathise with it though. Sometimes I just wish agilists would shut up and go away.
There's nothing about TDD that prevents you from "using your human intelligence to plan ahead and design". I really don't understand why so many people think that.
The main point of TDD is organically "growing" modular and testable code. Also, after a session, you have unit and function tests for free, instead of having to implement them afterwards. Having a plan from the start, however, is beneficial with TDD as well, as long as you're flexible enough to modify it if necessary.
The problem isn't pair programming, per se. It's the forced nature of it in many locations. Every line of code has to be written/modified in a pair.
The irony? Pair programming has become a dogmatic process over the needs of the individual developer in many locations, yet is still considered a core Agile technique. That just isn't right.
Like the author, I'm more introverted. I prefer to code alone. Forced coding or working with others drains me. However, if assistance is needed--myself or others--I've no issues working in a temporary pair to solve a problem.
Pair programming wasn't intended to be an iron dictate of "you must". It was intended to be a "it's ok to ask for help if you have a problem, because working software is the goal".
You're right, anything's bad if it's forced on a team or applied dogmatically.
(Also I'd edit the last sentence to read proscriptively rather than historically: "Pair programming shouldn't be an iron dictate..." since that's really more interesting.)
I have no issue with four eyes looking at a problem for a bit. But I would never sit next to someone all day long every day. I have no trouble communicating when it's necessary but to me pair programming seems a complete waste of 50% of your bandwidth, with virtually no proof that you make it up in quality of output. If it works for your team fine, but don't expect that it means it works for everyone.
In my experience pairing works best when it forces you to focus. If you have only a two or three hour pairing session with someone, you're going to make sure you use it effectively. You're right, sitting next to someone all day long is a waste.
This is a little silly. As a developer, I love cutting code. I really don't care if I'm pair programming or not. I don't like to write tests nearly as much. If you swap in "write unit tests" in place of "pair programming", the article pretty much works the same, the one difference is the authors social anxiety.
So really, this isn't about pair programming, it's about the fact the the poster has social anxiety, and needs to address that. (And I need to stop posting on HN and write some tests).
You're projecting. I completely understand the OPs position; I concur 100%. You can dismiss it as some foolish antisocial whine if you like; or you could understand that his position is entirely valid.
If you've never gotten into the zone; if you've never spent an entire afternoon and missed meals and been utterly surprised at the clock when you come up for air; if you've never been productive at the level of a seriously skilled programmer, then I suppose you would dismiss this as a silly rant. But that says more about you than the OP.
If you've never gotten into the zone WITH a pair you're really missing out. It's a far more incredible experience than doing it yourself, just like many things... ;-)
Would it be pair programming if two people sit together and one writes the unit tests while the other one implements the code to make it pass? Red person and Green person?
I guess during the refactor stage you would have some sort of design discussion as well. And it might be useful for one person to be the DRY promoter while the other person promotes the YAGNI point of view, or else refactoring can get out of control.
The OP clearly doesn't believe that he has a responsibility to teach those around him to be better. Imagine that you were the CEO of a company that had one great programmer and four average ones. Don't you think the CEO would want the great one to spread some of his/her knowledge? Now, imagine you were one of the four average developers, wouldn't it seem crazy that you sit three feet away from a great developer but never learn anything from him/her?
Do we want this to be an industry where only the self taught succeed? I don't. I believe there are still some things that I can learn from others. I believe I am obligated to help those around me get better- it should be part of the job description. Pair programming, if it does nothing else, does open up what is normally a solitary activity and gives people a chance to learn from others.
Give it ten years, employers will make their underlings have radio transmitters implanted deep into their heads in order to communicate over great distances.
This is the future of pair programming... Hive programming.
20+ years of experience as a prima donna who refuses to work with others and can't even discuss code with another programmer isn't very impressive. With that attitude, the experience wouldn't be enough to qualify someone for an entry-level junior developer position anywhere that I've worked. In my experience, programmers who don't want anyone else to see their code and aren't willing to discuss it have good reason to hide it.
A team's responsibilities go beyond delivering good software, a team must also ensure it is always improving in its ability to deliver software in future; raising the standards as individuals and as a group and sharing knowledge, patterns and practices. Pairing is an extremely effective way of achieving this, I've yet to see another way that even comes close.
Quite apart from his stubbornness around pairing, his broad-stroke presumptions about people who do pair, people who are introvert and people who are enthusiastic about sharing their patterns and practices smack of the worst kind of smug arrogance.
It's fine if the author isn't interested in the benefits of pairing, everyone's different. However I don't think I'd be particularly interested in working with him or hiring him.
76 comments
[ 3.4 ms ] story [ 186 ms ] threadIf it's sincere, I think the author is attacking a rather extreme position.
Sometimes I like to write code by myself. Sometimes I like to pair on stuff. It depends on a lot factors. Is it complicated code? Do I know the language/framework/codebase well? Do I have a peer who knows more than I do about the problem I'm trying to solve? Is it important that multiple people be able to maintain this code? Etc. Like most things, pairing is a trade-off. It can have benefits, but it costs twice as much to write code.
That said, I think most people in our industry could benefit from pairing more, not less. Studies on pair programming show significant advantages in many circumstances [2]. If the author is sincere, I hope he'll keep an open mind about an occasional pairing session in the future.
1. http://en.wikipedia.org/wiki/Poe's_law
2. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.101...
> I don’t believe that I’m alone in my opinion. All of my colleagues are very similar. In my 20+ year long career, I’ve only known one person that I suspect would be comfortable with pair programming
So I can easily imagine that he was unlucky during his 20+ year career, because it is not easy to find such group of people especially in Age of Everyone Can Become a Programmer.
But do these studies take into account employee happiness (and thus potentially losing good developers)? In other words, is it better to have five mediocre engineers pair programming or having five stellar engineers working normally?
All agreed that PP promoted the formation of good team spirit in the beginning of the project. The information radiator and the open workspace were also mentioned as contributors to good team spirit. Two of the developers liked PP more than solo programming and two found no difference.
Please at least skim references before calling them into question.
All the developers were recruited based on their interest in using agile practices including PP
Personally I would prefer not working in a paired programming environment, though I'm not sure it would be a deal-breaker. But I know developers (more introverted than me) who I imagine it might be.
Even though I enjoy pairing, I also doubt I would enjoy working at a place that required people to pair. Rules like that irk me. They're often a symptom of other, bigger problems.
Sure, I've had to endure somebody trying to 'help' when I have a hard problem to find. I spend my time explaining to the other guy, bringing them up to speed. And they spend their time suggesting things that have already been done, or suggesting using some buzzword toolchain like it will solve all the problems.
If I were churning out web logic or designing dialogs or some such it can be useful I suppose - "You forgot a brace. Remember we have to try all these on the proto server first." etc.
But I spend my time on tricky problems in the core IP of our company. I've always had that job, wherever I work. And let me tell you, having someone in the same room is a no-go for the hours of mental model-building it takes to diagnose or design these kind components.
Now, let admit there are different kinds of programming jobs. Maybe the bulk of web design etc is amenable to having two shovels in the same ditch - of course you'd get more done, its obvious! But for other tasks it is absolutely not going to help.
When it comes to code complexity, meta-studies argue against your claim. Pairing isn't worthwhile for simple code, but it's great for reducing defects in complex code:
The benefit of pairing is greatest on tasks that the programmers do not fully understand before they begin: that is, challenging tasks that call for creativity and sophistication.[1]
I and most everyone I've paired with have found this to be the case in our own work.
A side note: I'm not sure what your core argument is. Most of your comments in this thread seem to be a combination of self-aggrandizement, personal opinion, and veiled insults towards those who pair. I've tried to keep my own comments civil and evidence-based, but many others in this thread are full of negativity. It makes me sad.
1. http://en.wikipedia.org/wiki/Pair_programming#Meta-analyses
There does seem to be more emotion than logic expressed here. I've meant to try to counter this with sincere expressions of my experiences. I must have gotten emotional in return. I'm at my wits end, trying to counter the simplistic claims of PP proponents that everyone else is a cowboy or just too inexperienced to 'get it'. I get it, I don't like it, I can see constant refutation of the whole idea of PP in my team.
"reduce development time somewhat and produces marginal positive effects on code quality"
A good professional engineering environment where you start a sprint by having a design discussion with peers, and then come back to your peers on the tail end of the sprint for code review, is likely to provide all the same benefits as pair programming.
After all, this is not supposed to be a software factory. Developing software is engineering work, and designing the work well, with your peers, will do just as much to strengthen the team and it will also improve the work quality.
Working in pairs is useful in bringing junior people up to the next level, and in helping newcomers learn the problem domain or the platform/framework that you use, but it is not a universal good practice that you would use all the time.
And so you refuse to do it even if it would be tremendous help for the other person. You won't pair with a colleague, because you don't like it, because it would "disrupt your work", even though you could cause the other person to become much more productive in much shorter time. You're not only being a jerk by doing so, you're actually undermining your project and putting your "decades of successful projects" at risk.
Yeah, highly rational decision, based on your dislike of (as per OP) interacting with other people. I'm so happy I never met you.
I don't get anything done if I'm made to waste large portions of my day hand-holding other programmers. My work is best done in a silent room with hours uninterrupted.
I'm sure you'd be glad to meet me; I don't dislike interaction at all. Lets just do it at a coffee shop.
We had to create a strategy to manage the quality of the project and chose a task-based pair programming strategy. In those student projects it is often the case, that the better students do a rather big portion of the project while the others try to keep up. With pair programming this was not the case. Everyone developed on a similar level. Yes, it probably slowed down some of the developers, but for a student project, the main goal is to learn. And pair programming was a way to do that.
Also, our project quality really benefitted from this. After developing the basic server, client and game logic, we switched teams to do the next step. For example, the team that connected the client to the server would now have a person that knows the server side and one that ones the client side. This team changing was done on a regular basis and helped putting the software together. There were less problems with the code of different people working together than in most other projects and I believe, that pair programming was a big factor in that.
So, I can't speak for the work environment, but for learning to be a software developer, it really was a good experience.
Its OK if you hate Pair Programming. Its even OK if you hate it without even trying it. But just don't generalize it with being an introvert.
Part of writing good software is the ability to interact with people. That requires certain social abilities and the ability to talk confidently to people about code, the same as pair programming.
Truly introverted developers may write elegant and beautiful code, but they generally need an abstraction layer between them and the user/customer, which can cause the most beautiful code to be wrong, because it doesn't fulfil the requirement.
Pairing with people improves code quality by forcing you to explain your decisions, allowing you a better understanding of what you write, sharing knowledge of the codebase across the team, and preventing tangents that aren't what the client wants. It's not just about being more productive -- my personal opinion is it's actually slower than 2 developers working separately -- but that doesn't make it less worthwhile.
Yes, he does try to rationalize a little bit here and there, but overall I think that's it.
I don't at all believe that pair programming necessarily gives you a better end product. I think it can, but I think it depends a lot on the project and individuals involved. Personally I'm not a fan. I'm not quite the hater that the OP is, but I, too, would likely look for a new job if my company suddenly required regular pair programming of everyone.
I think I'm pretty damn good at what I do. That's obviously a subjective statement, but I could back it up with some facts that would seem to indicate I know what I'm doing. If I paired with someone on certain projects, would it create a better outcome? I'm not sure. Maybe it would. Maybe it wouldn't. But I really don't care, because I'm certain I wouldn't enjoy the process. Does that potentially limit my greatness as a developer? Maybe. Maybe not. But that's where the happiness thing comes in. If pairing truly could make me a better developer, and there's nothing else that could, then I'm honestly totally fine not being the best developer I could be, because I wouldn't be happy while practicing my craft.
As an aside: I'm talking about two peers of roughly the same skill pairing. I'd be happy to pair with a junior dev for the purposes of mentorship or knowledge transfer. Actually, I think pairing with anyone for the purpose of knowledge transfer is probably a good thing. I just wouldn't enjoy pairing as a fundamental part of working on a project.
Shared understanding is vital, even more so in a team of "left brain" introverts. Whether it is establishing what everyone thinks TDD to be and the metrics to be extracted. Or whether it is making sure that at least one other person knows what your code does, that it is the best way of doing it, that you're not taking shortcuts or making "clever solutions" that aren't needed and sacrifice maintainability.
Being a professional isn't about being dismissive of 9 to 5 paycheck developers and their skills whilst slamming out loads of code. If your experience is all of introverts who want to be left alone I dread to think what your code review practices are like...
How did you go around to finding him? I feel we really need that where I work, go back to basics and take up some "good habits"[0], but without a consultant/trainer to suggest it feels like whining without contributing. Attempting cultural changes internally on a suggestion basis doesn't really work, people (me included) just go back to their previous stable state.
[0] both small scale, the testing and refactoring stuff, and larger-scale with system architecture.
If you're going to shop around for a change agent, I recommend reading Jerry Weinberg's "Secrets of Consulting"; although this is targeted at consultants rather than their clients, it can provide useful insight into how to create an effective working partnership with one.
Technical know-how doesn't by itself qualify someone to help you implement changes towards becoming more effective. It can be detrimental, in fact.
But someone with a solid grasp of the fundamentals AND a productive attitude to coaching/mentoring/consulting can be a great asset. One I recommend wholeheartedly is JB: http://blog.thecodewhisperer.com/ (and if you can't get him, try to find someone like him).
Yeah I'm well-aware of that.
> One I recommend wholeheartedly is JB: http://blog.thecodewhisperer.com/ (and if you can't get him, try to find someone like him).
Thanks for the suggestion.
At our workplace, we have a monthly hour-long "Lunch and Learn" where we all meet to do three things: listen to someone share some interesting code they worked on that month (which helps to generate some enthusiasm and spread some knowledge around); talk together about a specific best-practice; collectively review some code with a focus on using that best-practice to improve the code. It is a very simple, low-cost, low-time-cost way to formalize the fact that you want everyone to pay attention to these things, and (in our case) has really stimulated a desire among the developers to improve their code practice.
To implement this, put someone in charge (or take charge yourself :) and just start asking people to contribute. You will probably find there is a lot more interest in this than you think.
Also, be sure to go easy on yourself and your peers as you try to change habits. If you look back at code you wrote, say, three years ago, you will probably say to yourself, "What was I thinking? I could write that so much better now." In the same way, three years from now you will be able to say, "What was I thinking? I could [test|commit|organize|pair-program|etc] that so much better now."
It really drives the point - the social connections are what makes or breaks you in an organisation. Any meaningful change needs allies, needs to persuade people, and needs to deal with ego and politics. The people responsible for what you want to change are probably those currently in management roles! It's probably one of the harder transitions from academic/training when there are absolute truths, to business where things become much more complex.
The best advice I can give is to find someone/a firm who hires people who switch between doing and consulting. It's a bit like the old "those who can do, those who can't, teach". Having someone with loads of current practical experience convinces the tech types to go along with their proposal. Having someone with "expert" consultant credentials persuades management to go with something. Which is frustrating when an employee has been suggesting the same thing for ages, but a massive bill is convincing...
The other top tip - especially if they are from out of town and thus staying over - invite them to the pub at the end of day one. They want to hear the gripes of those at the coal face.
A specific type of interaction is not for everyone, its clear you are not making any claims about it except for it doesn't work for your personality.
Does this mean Code/Peer Reviews should be given a rest too?
You do realize that the first line of the post is "this is a rant", right?
As an aside: I am pretty tired of people saying "I'm an introvert," when what they mean is "I'm an asshole." Even if you're introverted, you have the same responsibility as everyone else to communicate in order to get things done.
Not really. This is a guy who hates pair programming and believes it would make him unhappy. Full stop. Don't mistake his screed about how he'd quit programming if pairing were required with a belief that this is where the industry is going. That's merely language to show how much he really really really hates pair programming.
I am pretty tired of people saying "I'm an introvert," when what they mean is "I'm an asshole."
I think that's a bit harsh. Note that the article starts off with a warning that it's a rant: the author is admitting up-front that he's letting off some steam. Social interaction is a limited commodity for introverts. The author would likely prefer to spend his daily allotment of social interaction on what he'd consider more useful forms of workplace communication.
Well, somewhat. But I read other comments here and in at least three cases the posters were proudly describing themselves as assholes. The problem with all of them was that they never once realized that pairing may be done not for them, but for the other person (or them both). I thought it's common sense to consider all the people involved in the interaction. For those people it's not, it's only about how they feel and how they are influenced by pairing. I was very, very lucky (apparently) that I didn't meet any of them (or they didn't have the chance to manifest their attitude towards me - towards all of us) in my professional life.
This "fuck you all, whatever it may be I'm working" attitude may be tolerated in people who really contribute a lot. Their presence may be beneficial on the whole to the company or even to the team they're on. That doesn't mean they are not assholes - it just means that in our industry being a jerk is not disqualifying feature. I have no idea what they are so proud about, though.
I personally would like to try pair programming but none of the companies I have worked for would do it much. (Although the most productive time I had at my last job was a single pair programming session.)
And I'm pretty tired of extroverts expecting everyone else to be like them and consider anyone "assholes" when they aren't.
That goes both ways - if you're dealing with an introvert it might benefit you to communicate in a different style and with a different frequency. Some management books even provide models for quick and dirty social analysis so that people can do so. The model I've found most immediately applicable is:
Person focused ----- Task focused You can pick up on that sort of thing fairly easily, when people speak how loudly do they speak - do they project their voice? When they talk do they gesture a lot with their hands? When they talk is about things or people? Does their tone of voice alter when they talk about different areas - do the volunteer information as readily about those things, ask the same number of relevant questions?You don't like to pair. You don't want people to try to pair with you.
So far, I'm with you.
How do you get from there to "if you ever talk about pairing, you're incompetent and horrible"? I have trouble with that part.
It's the same as any software practice: TDD, which form of typing, vim/emacs/IDE, OO, etc. Without solid measurable proof that it's best for your specific job/domain/team (basically impossible) it's all just preference anyway. And someone who hates OO is going to constantly find ways why OO is terrible.
So we gather into jobs and teams that all share the same religious faith on all the above mentioned. Interviews are basically the same as you get in any church: do you believe these core faiths about our doctrine, and are you cool? Great, you're in!
Most people really don't like being preached at, and the agile community is very preachy. They're also very certain that agile is best practice, while everything else is cowboy.
I'm confident at this point that a sizeable chunk of the agile mantra is pretty poor practice. TDD, for example, definitely seems worse than actually using your human intelligence to plan ahead and design.
I don't necessarily agree with this article. I think most programmers do want and benefit from some degree of collaboration on problems. Mostly at the start when they're figuring out what they should actually build. I certainly sympathise with it though. Sometimes I just wish agilists would shut up and go away.
The main point of TDD is organically "growing" modular and testable code. Also, after a session, you have unit and function tests for free, instead of having to implement them afterwards. Having a plan from the start, however, is beneficial with TDD as well, as long as you're flexible enough to modify it if necessary.
The irony? Pair programming has become a dogmatic process over the needs of the individual developer in many locations, yet is still considered a core Agile technique. That just isn't right.
Like the author, I'm more introverted. I prefer to code alone. Forced coding or working with others drains me. However, if assistance is needed--myself or others--I've no issues working in a temporary pair to solve a problem.
Pair programming wasn't intended to be an iron dictate of "you must". It was intended to be a "it's ok to ask for help if you have a problem, because working software is the goal".
(Also I'd edit the last sentence to read proscriptively rather than historically: "Pair programming shouldn't be an iron dictate..." since that's really more interesting.)
So really, this isn't about pair programming, it's about the fact the the poster has social anxiety, and needs to address that. (And I need to stop posting on HN and write some tests).
If you've never gotten into the zone; if you've never spent an entire afternoon and missed meals and been utterly surprised at the clock when you come up for air; if you've never been productive at the level of a seriously skilled programmer, then I suppose you would dismiss this as a silly rant. But that says more about you than the OP.
(And did you think about testing your tests?)
I guess during the refactor stage you would have some sort of design discussion as well. And it might be useful for one person to be the DRY promoter while the other person promotes the YAGNI point of view, or else refactoring can get out of control.
Do we want this to be an industry where only the self taught succeed? I don't. I believe there are still some things that I can learn from others. I believe I am obligated to help those around me get better- it should be part of the job description. Pair programming, if it does nothing else, does open up what is normally a solitary activity and gives people a chance to learn from others.
This is the future of pair programming... Hive programming.
Quite apart from his stubbornness around pairing, his broad-stroke presumptions about people who do pair, people who are introvert and people who are enthusiastic about sharing their patterns and practices smack of the worst kind of smug arrogance.
It's fine if the author isn't interested in the benefits of pairing, everyone's different. However I don't think I'd be particularly interested in working with him or hiring him.