That sounds useless and is not an environment I would want to be apart of.
Only way I could see it work would be in a junior/senior pairing, where the junior developer is learning the standards and processes of the system from the senior. But both parties would need to be open to the arrangement. The junior would need to respect the experience and the knowledge of the senior, and the senior would need to be willing to share his or her knowledge and experience, and also willing to listen to the junior for opportunities to improve the status quo.
1 Like
That would definitely work if the environment allows it. Typically, the senior developers are already swamped w/ meetings and tasks. I would understand if senior developers are teaching the junior but Iâm not so sure if that is the purpose of pair programming. The only nearest pair programming I have done is âknowledge transferâ when I give my resignation.
Open Office is something I like but it depends on âfriendlinessâ of the co-workers. I used to work in that environment and we would just yell out âHey Steve, when you gonna do ABC?â and I get a reply back immediately. Or say something like âIâm completely lost can someone show me how idiot I am by looking at this code?â. But, if itâs at corporate company where you canât speak openly then I donât think itâll be good.
I would personally love this environment but I could not be productive in it at all. I have too many attention issues for that, and the âswitching costsâ are too high for me. Every single time someone shouted for someone else or poked me or cracked a joke or ran out of the room dripping coffee or⌠whatever. Iâd lose massive amounts of time trying to get back into my zone. Thatâs an unfortunately exacerbated trait in me compared to others Iâve worked with, but I recognize it and so try to avoid that type of situation when I can. Same with working at home - doesnât work unless I can lock myself in a room.
Pair programming⌠no idea if I could really do that well. Haha.
2 Likes
lol I would hate it for almost the exact same reasons. I get distracted very easily. I also like to talk.
Iâd probably have to invest in something like this:
http://michellemalkin.com/wp-content/uploads/2008/04/blogging-blinders.png
6 Likes
I know some people who swear by it. Iâve pair programmed and in some cases, itâs been great. Especially in helping someone get up to speed and doing knowledge transfer. However, for me, a full day of pair programming is mentally exhausting and no where near as productive.
I prefer expert code reviews for the bulk of the work, and keeping pairing to special cases.
I personally did it for 3 years and when it works it works really well. When egos get involved not so much as the whole idea is distributing both domain knowledge and technical experience. Hires to do this were preferred to be over 30 as prima donna streaks wain over time, especially ones that have been instilled by educational systems in the aim of getting best results. This is not to be confused with lack of passion, just that there are so many people in the world it is pretty worthless to feel competetive with a small bunch of people in a room. Plus communication skills and business experience are at a much higher level.
The full xp regiment was strictly in place so tdd etc was in place and the developers had a lot more say due to the greater leverage of domain expertise.
The key here is how important is the spread of domain knowledge and how worrisome the truck number problem is. Pairing allows heavy rotation of employees throughout projects so the natural state is closer to employee churn. When an employee leaves which they will do it is a personal loss over a business loss, most of the time businesses never realise what they will lose until it is gone at a technical level anyway. You get to know people really really well.
Scenarios it has worked well for me
- Working with front end developers on api stuff. They may have little knowledge or want to know back end stuff but appreciate getting to a level of self sufficiency I also learn how they operate so if I have to work on something they manage I do it in a way that they find least distateful.
- The âwhyâ is widely appreciated to be superior to the how. Bad ideas are bad ideas however well implemented. This comes back to a wide spread of domain knowledge. PMs/Consultants/Developers come and go and the code base is a record of everyone involved so stopping crazy at the earliest opportunity is a good thing.
- The systems are long life(5 years+) and millions are involved. 5 years may not sound a long time but if it is around for 5 it is likely to be around for 10, just longer the assumed time period the greater planning goes into gambling. Letting the system get into a state that people quit asap rather than have to work in it is a sensible business fear if a business is built on said software.
Scenarios where it is troublesome.
- The team is too small to have an effective apprentice->journeyman->master routine. Being one of a few who actually practice learning in their own time can mean little reciprocation of knowledge which can be mentally draining.
- Developers who are smart but have very little passion for doing a good job. Development is something they settled on for the money due to they find it easy. That is probably the worst thing you can bring into a pair programming environment. Nothing wrong with doing something for money but working close proximity to them for long periods is passion sucking.
- Reduces experimentation as getting concepts across can be hard and take far longer than the implementation leaving approaches rather staid. Quite often easier to do stuff so others can see it in action and can weigh up thje pros and cons more accurately. Building things in the brain is a skill that some people are just more adept at than others.
- Pretty much detroys the whole notion of developers hate working with other peoples code. Good personal habits can transfer across people due to the pair rotation so things can normalise to a point where the code is very similar to your own a lot of the time. Donât think that is such a major issue nowadays anyway with composer/sbt/maven etc as the majority of code developers consume was never written by them so it is a fact of life.
What it taught me.
- Effort causes misplaced idealism. Remove/automate effort some idealism disappears. Actually it is surprising the multiple of effort put into not doing something can far outway doing something. For example the sprout class move can be time consming in tdd due to the setting up mocks etc for the new class if it has dependencies etc. This can all the automated with reflection. Sprout class is then used more.
- Good tooling/equipment stops fights. This links to number 1.
- Doing/not doing anything due to personal need is not really a reason for sloppy work. Very few things in life are really needed. Need is a personal thing, not a tool for argument against having pride in work.
- Yagni and Kiss are a state of mind, not a mantra. As mantras they work really badly. Goes back to the need thing. Donât really need solid from a personal perspective. Donât need OO. Donât need functional. The only need is âsimpleâ procedural brain splurge as that is the minumum intellectual requirement to get paid until a required rewrite. Personally I find the use of simple in the previos statement quite a common misuse.
All those points can be learnt outside pair programming, but pair programming allows greater observation of personality traits due to the greater externalisation it requires.
Would I do it permanently again. Probably in the right environment with the right personalities. It can be very fun then, more like a game of pool. Meet interesting people, helps with introversion etc. Can build a lot of collective strength which can be targetted at opposition in competetive markets. But yeah it can be exausting, the weak are bolstered by the strong in the hope they become strong so people really really have to like each other so good hiring which is hard is now much harder. Knowing the codes is not enough.
1 Like
This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.