Quote:
Originally Posted by kbs666
As a project manager I've tried pair programming to bring new/junior devs up to speed and it has always been a dismal failure.
Finding two coders who think/work the same way is just not realistic. The senior also likely knows the system and knows exactly how to fix the problem/add the feature and finds it frustrating to explain everything. The senior dev doesn't get work he should be doing done and the junior doesn't really do anything and likely doesn't learn very much since he didn't do all the tracing of code and exploring that would have been required for him to do the task himself.
|
Well, when I did it, it worked well, on both sides. Yes, paired programming probably works best when they are at similar programming levels, and one is merely teaching the other the code and how things are done there. It can be done.
We followed the rule that one person had the keyboard for an hour while another looked things up or helped. Then we switched. Worked very well. When I was the junior, I might have had the keyboard for two hours to their one, but it did help a lot.
I'm not arguing that you have lost productivity. That will always happen when you onboard someone because it takes time to get them up to speed. When the company I was at did this, though, within a (two week) sprint, I could take stories on my own. I wasn't fast and code reviews were important but I could do something. That helped for my own sense of accomplishment.
I have also found that a lot of places don't implement Agile/Scrum well, usually on the business side. The business treats it like a buzz word to attract people, not realizing they have a big part to play in it.
But that's me and my own experience.
ETA: I would also say that both as the person teaching and being taught, both sides learned a lot. Having to relook at past code or think about things "they know" made them understand it better themselves. It also made them better teachers when they could see it from that new angle and explain pit falls.