Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×
Programming

Code Reviews vs. Pair Programming (mavenhive.in) 186

An anonymous reader writes: I've spent nine years working in teams which religiously follow pair programming. I'm used to working that way and appreciate the benefits it brings. We didn't have the luxury of pair programming all the time in my last project. This required us to do code reviews to ensure the quality of the code we delivered. This post is an attempt to consolidate the upsides and downsides of doing code reviews instead of pair programming in my three months of experience.
This discussion has been archived. No new comments can be posted.

Code Reviews vs. Pair Programming

Comments Filter:
  • by 110010001000 ( 697113 ) on Thursday January 21, 2016 @01:53PM (#51344885) Homepage Journal
    You have gone through nine years of pair programming and haven't shot yourself? The idea of pair programming itself is insane. I didn't know anyone actually did it.
    • by Anonymous Coward on Thursday January 21, 2016 @02:04PM (#51344981)

      (Going anonymous)

      You are likely running this through a cultural filter.

      The Indian teams that I have worked with are a lot more about huddling around a computer working things out, than the typical US approach of developer with headphones collaborating a couple of times a day. Different cultures do things differently.

      Looking at *real* salary information between two geos (Bangalore and Silicon Valley) comes out roughly as follows.

            Architect level 2:1.
            Junior level 5:1

      You can have pair programming for junior staff and still have a very strong cost advantage in India. That cost advantage plus a cultural tendency would make pair programming fairly easy to apply.

      Not making any comment about the quality of code or quality of engineers on either side of the pacific...

      • I think you are right after reading the article it seems like it is a typical outsourced development environment (which sounds hellish). Carry on!
      • by plopez ( 54068 )

        Does having 5 people huddled around a computer increase productivity or increase slippage?

        • by 110010001000 ( 697113 ) on Thursday January 21, 2016 @02:21PM (#51345113) Homepage Journal
          It definitely saves on heating costs if they all share a blanket.
        • by alvinrod ( 889928 ) on Thursday January 21, 2016 @02:38PM (#51345253)
          Even the early [ncsu.edu] academic studies [researchgate.net] (PDF warning) of the effectiveness of pair programming found that you didn't quite get as much out of a pair team as two individuals working independently. However the code quality is generally a lot better in terms of correctness or readability.

          If you have a few individuals who are new to an organization or becoming acclimated to a new project they've not worked on previously, pairing can make some sense. On the other hand if you've got a rock-star developer that's head-and-shoulders above the rest, it's probably not worthwhile to pair them with another person.
          • by eulernet ( 1132389 ) on Thursday January 21, 2016 @05:22PM (#51346535)

            This is nothing new.

            The effort of every individual in a group of people has been measured by Ringelmann in 1914, for army's purposes.
            Here is the original article: http://gallica.bnf.fr/ark:/121... [gallica.bnf.fr]

            And the results are (number of people => measured effort)
            1 => 100%
            2 => 93%
            3 => 85%
            4 => 77%
            5 => 70%
            6 => 63%
            7 => 56%
            8 => 49%

            This is called "Ringelmann effect" or more recently "social loafing".
            As you can see, 8 people produce the same amount of effort than 4 individuals.

          • Actually I have learned quite a bit about efficiently running IDEs, debuggers and troubleshooting techniques from pair programming. Coding, not so much- I can pick that up just looking at someone else's code.
            • Actually I have learned quite a bit about efficiently running IDEs, debuggers and troubleshooting techniques from pair programming.

              The amount of time devoted to efficiently learn *those things* should be very minimal compared to the total activity time.

              Coding, not so much- I can pick that up just looking at someone else's code.

              Or by doing, or reading, or applying general principles. Coding is such a basal thing. A good student right out of school should already know how to code well. What we get with work experience is the knowledge needed to work in projects, in organizations, in seeing troubleshooting patterns, in foreseeing issues, etc.

              • Never had formal pair programming- just anecdotes on when it was productive to bother another programmer and visit their cube.
          • by JoeMerchant ( 803320 ) on Thursday January 21, 2016 @05:50PM (#51346715)

            If you've got a "RockStar" - odds are that noone else can follow his work, so there's benefit in pairing there to get extended life and maintainability out of his productivity, enabling others to better maintain his(/her) code and freeing up your superstar to continue breaking new ground instead of getting bogged down in maintenance of the old stuff.

            If your "RockStar" does produce code that is readable and maintainable by mere mortals, then you definitely want to pair them up with the plebes so they learn how to do that, because most programmers can't.

            If spending 4 to 8 hours a week "paired up" with colleagues is too much for your precious flower to handle, watch out for exploding egos and horrible personality clashes.

            • Code review before the "RockStar" can merge his code in, should give the same result. Your new feature is not done until someone else can use it & maintain it. Otherwise the business is screwed if you get hit by a bus.

              Starting a policy of reviewing all code may seem like a waste of time. But as a team works together more, code reviews should get faster.

              To cover some of TFA's "Downsides";

              Working on stories which have dependencies is hard

              Yes. If you find you need to reuse some common code between two feature branches, first refactor & rebase that c

        • How do you measure productivity?

          Delivered code per engineer, or delivered code per dollar (rouble, rupee, etc). Depends on your measure. As AC says above, the costs for junior engineers are disproportionally lower.

          • by Entrope ( 68843 )

            Functionality delivered per engineer is a reasonable, although obviously incomplete, measure for managers to appraise individual engineers or teams.

            Functionality delivered per dollar is a useful measure for customers to appraise projects, where a "customer" might be another business unit or an executive who authorizes funding for an internal project just as easily as a traditional (external) customer.

            Both measures can, and often should, be used -- but obviously by different audiences, and for the different

        • Does having 5 people huddled around a computer increase productivity or increase slippage?

          I think you misunderstand the meaning of the word "pair". Unless you're thinking two pairs and a hot-spare.

          • Does having 5 people huddled around a computer increase productivity or increase slippage?

            I think you misunderstand the meaning of the word "pair". Unless you're thinking two pairs and a hot-spare.

            Depends on the problem set - back in 8 bit days (when I was about 13) my school entered a "programming competition" where the code for competition had to be typed by hand into a single machine (per team). You could have other computers for parallel development, but the competing code was restricted to the single keyboard and screen interface. Teams were limited to 5 programmers each.

            About half the teams "huddled around a single screen" and the other half (including us ;( ) split up onto 5 machines and the

        • I use lubricant to increase slippage myself, but you do whatever works for you...
        • by gweihir ( 88907 )

          From experience, I would say it ensures no good solution gets a chance.

      • by cob666 ( 656740 )
        I was a long term contractor at a rather large international company that recently outsourced all their IT, which included application development, to an India based company.

        I've had to deal with the client and the new support company several times over the last year and I agree that the mindset is completely different. They tend to work in teams of 2 or 3 with only one person doing any actual work at any given time. I'd love to say that the this results in either increased productivity or a better code
      • Retarded Array of Indiotic Doersoftheneedful.

      • In University in the 1980s, we called them "lab partners" - back then, a decent PC cost 2 month's gross salary of a starting BS degreed engineer, so there weren't that many machines to go around. It can work, it can work well, and it can go poorly - all depends on whether or not you've got a good working relationship with your "lab partner."

        At University, it was a challenge to hang on to good lab partners with the courses shuffling two or three times a year - in a professional situation, if management and

    • by gstoddart ( 321705 ) on Thursday January 21, 2016 @02:10PM (#51345031) Homepage

      Nine freakin' years, the mind boggles.

      On occasion I've sat with someone as we've worked through a complex thing and a second set of eyes was useful, and it wasn't terrible. I've definitely done code reviews, and it can contribute to better code.

      But 9 years doing pair programming? Good lord, my first though is "you're doing it wrong".

      If I wanted to spend 9 damned years helping a junior anybody build their confidence and skillset in anything ... I'd have gone into teaching.

      This just seems like you get half productivity all of the time, instead of two people pushing out code on different things, and then reviewing/debugging it later.

      Do we ever see "pair accounting" or "pair plumbing"? To do this all the time seems wasteful, and ridiculous. Nine years of it seems like madness.

      • Pair plumbing is actually quite common - though one half of the team (generally the "master plumber") is mostly engaged in sales and customer interfacing, while the junior is the one pulling toilets and sweating joints.

    • by UnknownSoldier ( 67820 ) on Thursday January 21, 2016 @03:00PM (#51345449)

      1. Find a better teammate then. Tossing the baby out with the bathwater just because it didn't work for you is irrational.

      2. When both of you are "in mental sync" it works great ! When not, it is a waste of time, for both of you. :-/

      3. Did you forget Brook's Law? There is no silver bullet Why? Because it depends on _context_.

    • by gweihir ( 88907 )

      Well, given that morons amplify each other, I expect that the business model here is really not dependent on code-quality. Hence I expect the OP can just continue as they did so far. Defense contracts?

    • FFS just include the various coding standards in your "Definition of Done" and provide white boxing tools for verification. To police it grab some sample checkins and run the whitebox tool against them. Kick arse if any fail. Why waste time Pair Programming unless you're mentoring someone and reviews generally turn into a pissing contest about shit that's just not important.
  • by creimer ( 824291 ) on Thursday January 21, 2016 @02:00PM (#51344951) Homepage
    Is that the new name for doubling up in the cubes to squeeze the most performance by square feet?
    • Yeah but there is a definite downside - half the time your partner will be coding...
      • by creimer ( 824291 )
        That's better than snoring....
      • Yeah but there is a definite downside - half the time your partner will be coding...

        If you read TFA, pair programming typically got skewed so one person was using the computer, typically them ore senior. So...not really half and not sure which person, but one of you will be sitting around while the other does the work.

  • by Anonymous Coward on Thursday January 21, 2016 @02:02PM (#51344963)

    ...and it is rather simple.

    Design > Discuss > Refine > Implement > Run code analysis

    This can be done in any workflow and in pairs. You don't gobble up the time of two team members but you still get to discuss the most important part of the implementation. You can even do a light-weight review afterwards with a check list of practices to focus on.

    • +1

      A common issue with code reviews is that the engineer making the change presents the completed implementation and the design *at the same time*. The collaboration early on to ensure a good design or theory of operation really helps cut down on the pain of code reviews.

      • +1

        A common issue with code reviews is that the engineer making the change presents the completed implementation and the design *at the same time*. The collaboration early on to ensure a good design or theory of operation really helps cut down on the pain of code reviews.

        Then that's not a code review. Anywhere I worked as a developer, we had separate design reviews that took place prior to the code being written.

  • by sanosuke001 ( 640243 ) on Thursday January 21, 2016 @02:09PM (#51345015)
    Watching someone else code is the most maddening thing. They always seem to take the long way of doing something; use the mouse and doing eight clicks where a keyboard shortcut would do, etc. I do my best to not watch people code when I'm trying to help them. I would have killed someone years ago if I did that full time.
    • by gstoddart ( 321705 ) on Thursday January 21, 2016 @02:17PM (#51345079) Homepage

      There's no way in hell I could function in that close proximity to ANYBODY for 9 years. Not even my wife, and I kinda mostly like her.

      I don't wish to spend my day with someone right up along side me.

      My experience with it is 1-2 hours is the absolute upper bound, and then it's going to turn into two kids in the back seat of a car on a long ride.

      What idiot thinks doing this all day every day would increase productivity?? That isn't a team mate, it's a fucking cell mate.

      • Most projects the last year, where I was involved in coding and not architect, scrum master or dev ops, we did in pair programming. Not 100% of the time, but certainly around 75%
        I doubt there was any way to be faster in those projects. The productivity boost of 'good pairings' os far beyond factor two. If you split the pair, both do individually less than 50% of the work they would do together.

        No idea where this pair programming hate comes from yelled out by people who clearly never ever really tried it.

        Jus

        • >

          No idea where this pair programming hate comes from yelled out by people who clearly never ever really tried it.

          Easy, if you're not the sort of person that easily spends extended time with other people then it's going to be something close to hell. Introverted people have to put effort into social interactions, and so will never ever want to spend 8 hours a day interacting with someone else, even someone they really like.

          You don't actually need to try it to know that, it's down to how people are wired interpersonally. I can understand how it might work for some but I'm sure as anything it won't work for me as a defau

      • There's no way in hell I could function in that close proximity to ANYBODY for 9 years.

        Somehow, based on your post history, I believe that lol

      • So, I'd say, if you're "coding" a full 8 hours a day, you're probably doing it wrong.

        Some time needs to be devoted to defining the problem (this usually involves talking to people), some time needs to be devoted to research, review of existing code, tools selection, etc.

        Some time needs to be devoted to keeping in sync with other aspects of the project, whether it's other software modules, hardware, whatever.

        Heads down coding, 40 hours per week, will probably result in 20 hours of wasted effort due to insuff

        • by Xest ( 935314 )

          I'd say if you're doing architectural stuff every day that you're doing it wrong. There's no way you should be pratting around with tools selection on a daily basis, and even your customers are unlikely to need to be pestered daily.

          I suspect the problem is you've assumed everyone is working on the type of project you are, you're probably doing some customer facing UI type application like a web page. Not everyone is, some people work on libraries, others on compilers, others on large back end systems. These

          • You might be amazed how much "code" that is not web-pages still interfaces with people. If libraries and compilers aren't used by at least 100x as many programmers as the ones required to write and maintain them, I'd call "you're doing it wrong" on the libraries and compilers. I'll grant that "large back end systems" require a lot of effort, and maintenance, but in this case your "customers" are the programmers that interface to the system - and, in a way, the specifications of those interfaces.

            If a codin

    • by Kjella ( 173770 )

      Watching someone else code is the most maddening thing. They always seem to take the long way of doing something; use the mouse and doing eight clicks where a keyboard shortcut would do, etc. I do my best to not watch people code when I'm trying to help them. I would have killed someone years ago if I did that full time.

      Same here, it's one thing to discuss structure, interfaces and workflow but pair programming is two people painting a house with one brush. Even a training session with me typically starts with show and tell then handing off simple assignments to work on your own pace. You have the documentation, compiler, you can run it on some test data and I'm often going to outline a solution in the beginning. Even if we're two experienced developers working on it I'd rather play tag team or good developer/bad developer

  • This required us to do code reviews to ensure the quality of the code we delivered.

    Ensure quality - that's adorable.

    • I am highly annoyed with code reviews, because people really aren't doing them. I find all sorts of bugs that should be caught by any cursory code review but they sneak past. I think most people just say "yup, looks ok, does the job, pass" without spending any meaningful time scrutinizing the code. Then I end up seeing the code and feel like an ass if I ask people to change it after it's already been done. Especiallly with things that work, aren't bugs, but just violate a lot of other common sense thing

      • I have found code reviews to be more about conformity and coding to the lowest common denominator than code "quality" (whatever that actually means). When there's complex and/or sophisticated code involved, even with in-line commentary, unless the reviewers are near, at or (preferably) above the skill/experience level of the coder, the exercise turns into either (a) a coding lesson or (b) directives to dumb it down -- and this doesn't usually help if you're the most experienced one. I don't mind the ment

        • coding to the lowest common denominator than code "quality" (whatever that actually means). When there's complex and/or sophisticated code involved, even with in-line commentary, unless the reviewers are near, at or (preferably) above the skill/experience level of the coder...

          Reminded of the various quotes along the lines of: "I write a long letter because I don't have time to write a short letter"
          "Anyone can write complex code, it takes a good coder to write simple code to complex problems"

          Your job is to do what your company employed you to do. So your attitude could be correct, depending on your job.
          Are you paid to develop code that will never be maintained? (eg R&D where you work only on prototypes?)
          Or does your company pay you to develop code that can be maintained and i

  • by i_ate_god ( 899684 ) on Thursday January 21, 2016 @02:11PM (#51345041) Homepage

    A proper peer review process is far superior. Review your plan with your teammates. If you're working with components that others work on, make sure they are part of the plan review. Once all questions are answered, put your headphones on and go forth and code. Rely on unit tests to catch the obvious problems, rely on integration tests to catch less than obvious problems, rely on QA to catch what your integration tests miss. Use linting, static code analysis, and other tools like Sonarqube to identify potential problems within your code that may not manifest themselves under day to day usage. Voila...

    Is it perfect? Of course not. Will your software be 100% bug free? Of course not. It also doesn't solve problems related to lack of intelligence or experience amongst your teammates, and it doesn't solve problems related to lack of foresight from management who impose impossible deadlines or who close deals with customers that include features which don't exist. But the team will still be more productive than if they had to share computers and work in pairs. Programmers need focus and pair programming will ruin any focus you could have.

  • >> I've spent nine years working in teams which religiously follow pair programming

    I've been in software development for 18 years and pair programming has always sounded like a myth to me - I've never actually met anyone doing it for anything other than learning a new technology.

    >> required us to do code reviews to ensure the quality of the code we delivered

    Hell, at half the places I've worked code reviews were considered an unnecessary luxury. These days I'm just happy to hold the line at TDD

    • Short answer: India. Longer answer: Bangalore, India.
      • by gweihir ( 88907 )

        As no good coders work there (they have all gone to greener pastures), maybe you can bring code quality there up from "complete and utter crap" to "complete crap". Not sure this is worthwhile doing though. (Yes, I have reviewed code produced there. Several times. The sheer level of non-understanding you can find in there is staggering.)

  • by jimbo ( 1370 )

    Any designs and code developed in my projects is going to get peer reviewed, whether pair programmed or not.

  • Collaboration (Score:3, Informative)

    by milgner ( 3983081 ) on Thursday January 21, 2016 @02:30PM (#51345207)

    This happens in pair programming when the entire team is sitting in one place and conversations can be overheard

    I wouldn't know a better way to destroy productivity than having people pair programming in a public space. How is anyone supposed to concentrate on their work or their coding partner while listening to the conversations of everyone else in the room at the same time?

  • by Copid ( 137416 ) on Thursday January 21, 2016 @02:32PM (#51345219)
    ...pair debugging can be great. Two people looking at the same code and same test output at the same time can go back and forth designing tests and interpreting results really effectively, especially if the bug is at the intersection of two modules that you're reach responsible for. Of course, you don't spend all day every day debugging or something has gone very wrong wrong.
  • by Tony Isaac ( 1301187 ) on Thursday January 21, 2016 @02:45PM (#51345319) Homepage

    There might be times when it's nice to have the second person helping pedal up a long hill. But you're certainly not going to double your speed or your stamina with two people on one bicycle.

    Pair programming is like that. There are specific situations where it's useful, especially when you're dealing with a tricky algorithm or intricate business requirements. But much of the time, the second person is just dead weight.

    • What is right for mechanical work is not right for mental work.

      Pairing mental workers usually increases their performance by factors of three to five and often more.

      The key term is: synergy!

      • Pairing mental workers usually increases their performance by factors of three to five and often more.

        We should try quadding[1] them then. Will that make their productivity go up by six to ten, or by nine to twenty-five, or some other number?

        Feel free to pull a figure out of your arse. You should be able to remember where it is.

        [1] it is now.

      • by gweihir ( 88907 )

        Only if their productivity and result quality is exceptionally bad in the first place. In that case, it is still bad when increased 3-5 times and basically the only thing you can do with the results is throw them away. It is the cheapest option.

  • by Ckwop ( 707653 ) <Simon.Johnson@gmail.com> on Thursday January 21, 2016 @03:21PM (#51345609) Homepage

    In our organisation, we have teams of six people that work together on their sprint. QA staff are included in this team.

    On major features, the team code reviews the feature together in a special session. Roles are assigned. The author is present, a reader (who is not the author) reads the code. There is an arbitrator who decides whether a raised issue gets fixed. This arbitrator role is rotated through the team on an inspection by inspection basis. Finally, there is a time keeper role who moves the conversation to a decision if one topic is debated for more than three minutes.

    This process typically finds a humongous number of issues. It takes us about 4 hours of applied effort to discover a bug in pure functional testing. This process discovers bugs at a rate of 1.25 bugs per man hour of applied effort. So if you have five people in a room for one hour, you have applied 5 man hours. You'd expect to find 6-7 bugs. If you include all the stylistic coding standards bugs, this is typically 10-15 bugs per hour.

    So while on the surface it looks expensive to have all those people in a room talking. The net result is that it tends to accelerate delivery because so many issues are removed from the software. Better still, the review occurs before functional testing begins. This means the QA staff on the team can direct their testing at the areas highlighted by the inspection process. This further improves quality

    It's true that about 50% of the ossies are stylistic issues. But usually we get 1 or 2 bugs per session that present a serious malfunction in the program. The rest could be problems under some circumstances or minor faults.

    Team reviews are vastly, vastly superior to pair-programming. There really is no contest.

    • You sound like a bean counter, and your organisation sounds like it is hell to work in. 1.25 bugs per man hour? Christ.
      • by Ckwop ( 707653 ) <Simon.Johnson@gmail.com> on Thursday January 21, 2016 @03:39PM (#51345743) Homepage

        You sound like a bean counter, and your organisation sounds like it is hell to work in. 1.25 bugs per man hour? Christ.

        Well I'm the head of development at our place so I inhabit both worlds. Businesses like to measure return on investment. By being able to speak that language, I can generally frame activities developers naturally want to do in those terms. This leads to developers getting more of what they want.

        You know what developers really, really, really hate? Having to work with technical debt and having no process to remove that technical debt because the program is now "working".

        The best way around technical debt is not to put it in to the program in the first place. This process does a sterling job at that. So our developers are generally a pretty happy bunch.

        • Case in point: I'm maintaining HP printer firmware. Do you have any idea how resistant they are to fixing bad design decisions made long ago by people that no longer work here? The code is the result of decades of band-aid fixes... and it shows.
      • Finding 1.25 bugs per man hour is impressive. If we did that, we could ship a bug-free application every week (just kidding), the code fixes usually take longer the 1.25 hours. But seriously, we have find around 30-40 bugs per release so if we could spend 24-32 man hours to find all the bugs, I would be thrilled.

        Now if Microsoft would lock all their developers in a room for a year, we could get a stable release of Windows.
  • by javabandit ( 464204 ) on Thursday January 21, 2016 @03:43PM (#51345779)

    ... I swear. Lean, SCRUM, XP, Agile, Waterfall, Kanban, Scrumban, TDD, BDD, Pair Programming, Code Review, User Stories... etc... etc... etc.

    How about just be a responsible craftsman, understand the customer's requirements and needs, and implement your solution responsibly and with integrity? Whatever that means. If you need to pull someone in, then do it. If you don't, then don't. Christ, how complicated is this? It's one thing to be a junior developer and having to learn things. Fine. But an experienced software developer should not require constant canoodling to get their job done responsibly, with integrity, and with good quality. Is it really that hard?

    I'm from a pretty old-school programming upbringing -- back when you were a "Programmer" or "Analyst" or "Programmer/Analyst". I'll tell you in those days... if a programmer demanded this kind of ridiculous hand-holding, canoodling, and process-implementation to get their job done... they would be fired. Plain and simple. This industry has become awash with process and tool zealots... while knowing the customer's needs be damned.

    • What a shocking concept! You mean actually, you know, write code? What is your bug finding rate per applied man hour? What? You don't know?
      • I don't get why you are riding on 'bugs found per man hour' since ten posts when the parent only wanted to make an example about 'when grouping up experts into one room for one task' has synergetic effects and the speed increae they solve the problems is higher than linear.
        No one in the industry us measuring 'bugs found per man hour'. If we measure then we measure 'bugs introduced per man hour'. And probably we have to overlapping graphs of bugs discovered per sprint and bugs solved per sprint. And obviousl

        • If that was not clear for you: you should witch business.

          I placed a curse on my employer. I think it worked because they lost a lot of money and fired my entire group.

    • Refactoring is something experienced programmers just naturally do, when they are given a chance. And actually having developers talk to each other occasionally is actually a good idea. Peer review is a pain but does improve software quality. User stories... only useful for writing software tests. The concept of writing the tests first is actually a good idea; too bad I've never seen it done. Most of the eXtreme Programming stuff does strike me as a bullshit waste of time, but Pair Programming is the thing
    • by Yunzil ( 181064 )

      Look man, we can't do anything unless there's a trendy buzzword name for it.

    • by gweihir ( 88907 )

      Naaa, craftsmanship and actual competence is something the MBA bean-counter morons cannot understand (as it involves the real world) and hence it is dead.

      When I look what the younger generation is learning today, I expect that I will have a job writing actual good code far over my retirement-age, because most of them sure as hell cannot do it.

  • Unless you're training a junior programmer, pair programming is stupid. Having two competent programmers work together is wasting valuable time. Peer review is a necessity, but it can be pretty informal, shoving several people in a room together to go over code line by line is probably a waste of time to. Better to sent out emails with a list of files saying "Review these files and fill in a spreadsheet with your feedback", then have a meeting to discuss which feedback to ignore. Unfortunately, projects alw
  • Pair sysadminning is something I have actually done, and that has its uses. The guy who knows most has the keyboard, and the other guy has one finger tracing the manual's instructions, as well as a notebook where he writes down what happens and why, especially including things that won't be in the terminal session script like "I'll correct that later" or "This value should work, let's check".

    But nowadays with Infrastructure as Code and Network as Code and what have you, you check your sysadminning code into

  • I've spent nine years working in teams which religiously follow pair programming.

    That is one clusterfuck of a professional experience. To me this tells me a lot of work in those years constituted code monkeying.

    For starters, we are engineers. We are supposed to use general principles to solve real world non-trivial problems. This implies a need for adapting processes to issues at hand. Professional discretion is required when performing activities. Following something religiously gives me the notion of people going through the emotions by orders given from above. Good way for herding

  • by gfdgfdwrg ( 4424959 ) on Thursday January 21, 2016 @06:34PM (#51347007)
    Pair programming when creating new features: FAIL. Pair programming with the guy who wrote the original code when you find bugs: EPIC WIN
  • by Baki ( 72515 ) on Thursday January 21, 2016 @08:21PM (#51347643)

    Even if you would think pair programming makes sense (I don't, but it might be cultural as some have claimed), they cannot replace code reviews.

    Both "pair programmers" are following the same thought process and may fall in the same trap.

    A fresh look, by someone who wasn't involved in coding is always required.

  • Pair programming requires one to continuously socialize with someone nonstop for entire working day, something that most people, let alone most software engineers, can not do while maintaining concentration, creativity or sanity.

    Code reviews encourage filibusters when someone keeps adding to the comment thread just because they personally want something done differently and others find it rude to approve the change and curtail discussion.

    What works well is running lint and writing good tests. Then if someon

  • by samantha ( 68231 ) *

    Why vs? Neither of them is worth crap for actually improving code. Room and incentives to refactor and simplify plus unit tests (of functionality and not deeply dependent on exact implementation) does a lot more good.

  • The only way I could get pair programming to work was to get in a room with a projector, and give the one developer the control of the keyboard. The other developer gives instructions and directs the flow (while also writing things out on the whiteboard to teach the other). If some changes/fixes take a lot of time, this lets the both developers work on their own laptops.

    This worked irrespective of whether the junior/senior dev was projecting. It is more hands on for the driver, while giving more flexibility

  • It mostly depends on your team.
    Pair-programming is hard, code reviews are pretty easy. Pair-programming increases team cohesion, but it to be properly done or it becomes than useless.
    There is the driver, who writes the code and the observer who review and thinks more about the general design. There should be a frequent alternance, unless there is a vast experience gap between the two people, then the less experimented drives more (to avoid the keyboard domination antipattern).
    Pair-programming should only

Happiness is a hard disk.

Working...