Tag Info

Hot answers tagged

72

Should junior programmers be involved as code reviewers in the projects of senior programmers? Yes they should. It is a good learning experience to read other peoples' code. (And that applies both for good code and bad. Though one would hope that a senior developer's code wouldn't be bad ...) Obviously, it is unwise to only have juniors doing the ...


51

The primary purpose of a code review is to find defects or potential problems. The required participants in the review should be the people who are best suited to identify these problems, regardless of their title or seniority. As an example, if an application is being developed in Python and the junior engineer has more experience with the Python language ...


44

You are confusing the issue. Being agile means that you are following a bunch of values and practices from the agile manifesto. Thats it. XP and Scrum are development processes that follows those values. Both are "just as agile". The big difference between Scrum and XP is that Scrum does not contain practices specifically for programming, whereas XP has ...


30

I would add that if a "Junior" programmer can not understand a seniors code then that in itself is a good measure of the code. OK there may be times when it just isn't possible to write code that everyone can understand, but hopefully those are exceptions - if only 1 or 2 people can understand the code then what happens when those people are not available ...


26

Research compiled by Laurie Williams indicates that pair programming works best on industrial teams when Pairs work on specification, design, and complex programming tasks - experiments indicate that no quality improvement is shown when working on simple tasks in a pair but there may be speed improvements. Also note that pair "programming" often includes ...


26

Assuming that the more experienced person in the pair has the temperament to mentor the other person, pairing someone with little experience in the language or the problem domain with an experienced person would facilitate knowledge transfer. The less experienced person would have a mentor to instruct them on the language, the domain, the application, and ...


22

Guess what - nobody likes pair programming at first. When I first tried pair programming I was against the idea and I had tons of objections similar to yours. I don't like to watch someone else coding, I like to listen to music, I feel I'll be quicker working on my own, I don't want to stop and explain myself constantly, etc etc etc. Then I tried it. And ...


19

I've had the same gig for 15 years and we've recently (last 12-18 months) starting adopting Agile techniques. Where pair programming is used, the result story/feature has been implemented on time w/ less defects. I still don't think it's been employed often enough though. Prior to our Agile adoption one other developer and I have shared the keyboard from ...


18

Pair programming is a great tool! It can be way more efficient – two heads are better than one – and a great way to learn new techniques. Of course, there are other benefits too. But, if you are not buying into it, then you won’t get anything out of it. Given your attitude, it sounds like you would not fit into it at all and it would probably be a waste of ...


18

Partly, it depends on how you are doing pair programming. In some instances, the driver of the pair is writing code, while the second member of the pair is observing and discussing the design and implementation details of the system. Another instance of pair programming involves both people writing code simultaneously - one person is writing the implemented ...


17

The purpose of code reviews is to catch problems that testing can't catch, like maintainability problems and corner cases. I would argue that in many ways junior programmers are better suited for that purpose: They have more time available in general. They are more likely to take it slowly, line by line, out of necessity to understand the code. When you ...


16

Agile is the generic term for the methodology. XP and Scrum are the specific names for different implementations of that methodology. The Wikipedia pages are probably good starting points for further reading- check the "References" and "Further Reading" sections at the bottom of each page, but you should look into each and other implementations further ...


15

Edit: Disclaimer - This is how I define "the zone": A state of extreme focus, in which one is able to understand how many intricate details connect together, regardless of whether these do so elegantly (or simply) or not. I try to avoid this state because, while I may produce correct code in the zone, I and other developers will have a hard time ...


15

This is exactly the use case pair programming was made for: sharing experience between old beard and young grasshopper. This is a two-way sharing: agile insects have much to teach to rheumatic brains.


15

The way I understand it, a story-point is an estimate of relative effort, not man-hours. The effort required of a story isn't going to change just because a pair is working on it, so it doesn't make sense for the story points to change... Also, velocity is derived from the history of what got done in the previous sprint(s). If you pair on some stories and ...


15

Pair programming should not be used to train inexperienced or less-skilled developers. Studies and meta-studies that support pair programming on a general, conceptual level, almost invariably find that the gains in quality and productivity only outweigh the added cost when both programmers are at roughly the same skill level. In fact, this has pretty much ...


13

Pair programming is a tool. Like any tool, there are times when it's useful and times when it's not. Using the right tools for the job can involve different tools at different times, including a mixture of those tools. Thus, if the situation calls for it, break away when necessary and meet back up when necessary. For instance, if you both are researching ...


13

include the value you added to the pair programming in the performance review - did you help the other programmer learn useful things? (and vice-versa, did you listen to his/her sage advice and cooperate well?) a performance review should not be a competition, it should be a coaching evaluation relative to your personal goals (which are presumably in line ...


13

I would assume the auditors would prefer that developers log in as themselves and not as some "pair" which has a shared password. The risk should be obvious--a developer adds some malicious code as "PairA" and puts someone else's initials in the comment (or doesn't comment it at all). How do you trace back to the malicious developer? I'd recommend that ...


12

Atlassian makes use of a pair-programming exercise as a standard part of their technical interview process. The way they do it, they have a dedicated sample project (or in practice, they probably have a few different sample projects and they pick one at random for each candidate) that the candidate works through with a developer. The project is all ...


12

It actually hasn't been singled out at all. Think about the terminology: driver and navigator. Commercial aviation has long benefitted from this technique with pilots and copilots. Most jobs where detail is extremely important can benefit from working in pairs. You will never see a brain surgeon alone in a surgery room hacking away; the team around him are ...


12

Hour one: you program, the other person watches and helps thinking. Hour two: the other person programs, you watch and help thinking. You can switch editors when the other person starts programming.


12

Since it has already been discussed in other answers why pair programming isn't a solution for you, I will discuss what we have currently experimented with, and are satisfied with the results. In my view what you can do to increase collaboration is to have two people together on each project. Each of them works on a different part of the project, but ...


12

One of the key resources for Extreme Programming is that of Ward's Wiki aka Portland Pattern Repository aka C2.com. This is where a number of people hashed out various methodologies and documented them as they used them. Within this wiki, there is a page: Extreme Programming Code Reviews that has a number of contributors to it, including Ron Jeffries and ...


11

My guess is that there would probably be a lot of resistances from the developers. Do you remember being forced to work with people that were perhaps not the most motivated individuals in the world during college or even high school? Those people still exist. Unless, you have a team composed of all "top-notch" people, this type of setup will cause some ...


10

Let's look at this from another POV: given your predisposition, you're likely doing a disservice to the employer. They certainly don't want to hire someone who "hates" one of their development practices. Have you informed them of your perspective given such a tight-collaborative environment? If not, you're potentially misrepresenting yourself. As an ...


10

Though you are describing this as a shared coding session (I can't call it pair programming, as only one person is "driving" - in pair programming, both parties take the keyboard and write code), I would call it gathering acceptance criteria. That is, you are validating business rules (correct calculations and processes) with the business user (though one ...


10

When I got promoted to my current team I was the newbie in J2EE but I was the expert in the domain. My senior (the new team leader) was skilled in J2EE but not in the platform. I think I learned more about Java2EE in these 4 months with pair programming than reading a book and the team leader learned about the platform as well. The experience gap between ...


10

Juniors will often be asked to maintain the code, it is critical that they can understand it. At times juniors are the only people available to review the code of the senior developers. Should code wait to go to QA (we don't push anything out of dev without a code review and I am assuming this type of code review as well) because the senior's boss is on ...


10

This depends on things like the complexity of the system and how well the organization is prepared to onboard new programmers. It can take anywhere from 30 minutes to multiple weeks. It's not necessarily anything you're doing wrong and you shouldn't feel bad about it. What you should do, however, is be proactive about fixing it for yourself and others. Tell ...



Only top voted, non community-wiki answers of a minimum length are eligible