|
quote:Pair programming consists of two programmers sharing a single workstation (one screen, keyboard and mouse among the pair). The programmer at the keyboard is usually called the “driver”, the other, also actively involved in the programming task but focusing more on overall direction is the “navigator”; it is expected that the programmers swap roles every few minutes or so. sounds like hell. i don't think i could ever work this way, because a lot of the time i'm figuring out how to approach a problem, or my brain is not working at all, depending on my motivation. what do you think? does anyone do this?
|
#
?
Nov 17, 2021 23:18
|
|
|
|
| # ? Jun 9, 2023 06:08 |
|
|
pair programming is super good imo but it is exhausting and you really have to get along well with your pair. idk about swapping roles every few minutes tho, that seems weird. You kind of just swap when you want to and when it feels right.
|
|
#
?
Nov 17, 2021 23:25
|
|
|
everything on the agile website is wrong and bad. like why would you describe what's valued about left and right sides of "the agile manifesto" in reverse order?
|
|
#
?
Nov 17, 2021 23:26
|
|
|
rotor posted:pair programming is super good imo but it is exhausting and you really have to get along well with your pair. i've done it like 14 years ago working on a backend project that used php and mysql. we definitely never swapped. it was mostly confusing to me, because our thoughts and methods were often different from one another. i think it's better to plan how things should work, and meet periodically
|
|
#
?
Nov 17, 2021 23:29
|
|
|
Good Sphere posted:it was mostly confusing to me, because our thoughts and methods were often different from one another. working through those differences makes better software and the process gradually makes you a better programmer imo
|
|
#
?
Nov 17, 2021 23:45
|
|
|
its basically a live 2 way code review
|
|
#
?
Nov 17, 2021 23:45
|
|
|
anyway i'm not here to say everyone should do it, but when it works well, it works really well.
|
|
#
?
Nov 17, 2021 23:46
|
|
|
Pair programming is great for knowledge transfer. I use it all the time when I'm bringing new team members up to speed on our codebase, or when someone is terminally blocked, or when code review becomes highly involved and it becomes more practical to have a conversation than to pass notes around. We don't swap roles on a timer or anything, usually I hang back and navigate while they type, unless there's something really tedious and not-very-educational we need to get through, in which case I tend to take over and bash the code out at high speed. It's just a tool in the toolbox, though. Definitely worth having as an option, but not a way of life. I also find it really exhausting.
|
|
#
?
Nov 17, 2021 23:51
|
|
|
two programmers talk to each other and somehow useful code gets written. yeah, it never made sense to me either
|
|
#
?
Nov 17, 2021 23:56
|
|
|
exhausting is a really accurate term for it. i do think you get good code out of it and it's really great for teaching/learning. but i absolutely cannot do it for more than like an hour
|
|
#
?
Nov 18, 2021 00:00
|
|
|
rotor posted:its basically a live 2 way code review Truman Peyote posted:exhausting is a really accurate term for it. i do think you get good code out of it and it's really great for teaching/learning. but i absolutely cannot do it for more than like an hour both of these have been my experience. the driver writes the code while the navigator serves as a rubber duck and maybe points out the occasional blind spot. frequently useful, but i wouldn't want it to be the only way i write code never tried swapping roles every few minutes. that just sounds like a great way to gently caress up both people's trains of thought
|
|
#
?
Nov 18, 2021 00:07
|
|
|
paired programming is great for teaching purposes where the person on the keyboard is learning some skill from the other person like a senior dev walking a junior dev through some problem. you can help them work thru it and provide suggestions or questions for them to consider why or how to do something. doesnt really work for peers tho
|
|
#
?
Nov 18, 2021 00:15
|
|
|
DaTroof posted:both of these have been my experience. the driver writes the code while the navigator serves as a rubber duck and maybe points out the occasional blind spot. frequently useful, but i wouldn't want it to be the only way i write code navigator also looks up api docs that the driver will need in a little while so when they get there it's just "its getWidget and it takes a string name and an int id and the property hash we just built"
|
|
#
?
Nov 18, 2021 00:16
|
|
|
Shaggar posted:doesnt really work for peers tho it does, you just gotta do it right.
|
|
#
?
Nov 18, 2021 00:17
|
|
|
rotor posted:navigator also looks up api docs that the driver will need in a little while so when they get there it's just "its getWidget and it takes a string name and an int id and the property hash we just built" oh, yeah. i frequently have docs open in a tab when i'm navigating i should also note that 99% of my pair programming has been over a screen share in a slack call or something similar, not two people sitting at one computer
|
|
#
?
Nov 18, 2021 00:25
|
|
|
okay, maybe i shouldn't have such a strong bias against it. part of it's probably because people i've worked with didn't really work that way, but if the opportunity arises i'll be open to itShaggar posted:paired programming is great for teaching purposes where the person on the keyboard is learning some skill from the other person like a senior dev walking a junior dev through some problem. you can help them work thru it and provide suggestions or questions for them to consider why or how to do something. that's basically what happened when i tried it. i was the junior dev. exhausting definitely described it too
|
|
#
?
Nov 18, 2021 00:33
|
|
|
pair programming where one guy is like "do this, do that, do the other thing" and you're just typing for him isnt really what pair programing is, although it's typically what it degenerates into if you're not careful.
|
|
#
?
Nov 18, 2021 00:49
|
|
|
So here's how I've seen it work: The driver is responsible for localized work, say the current function. They're making sure the syntax is right, that they handle any exceptions, formatting strings correctly, poo poo like that. The navigator is responsible for seeing where that work is heading and smoothing the way by looking up docs and reminding the driver they'll need the fqname of the host for the next call or whatever so he can format it right, and also keeping an eye out for gotchas, bugs and edge conditions the driver misses. Obviously there has to be some agreement on how the code should be written and that has to be hashed out either before or during, so generally there's a lot of talking and a lot of back & forth. The switch between driver & navigator typically happens here. The one thing that's an absolute must is having two keyboards & two mice so you can just type what you mean instead of saying code out loud to someone which is incredibly frustrating for both people.
|
|
#
?
Nov 18, 2021 00:57
|
|
|
the thing where a senior dev is working the junior dev like a coding puppet sucks, dont do that.
|
|
#
?
Nov 18, 2021 00:57
|
|
|
Good Sphere posted:okay, maybe i shouldn't have such a strong bias against it. part of it's probably because people i've worked with didn't really work that way, but if the opportunity arises i'll be open to it its difficult to get right and very dependant on the personalities of all the people involved. As a highly social activity, it can be difficult for a lot of programmers.
|
|
#
?
Nov 18, 2021 00:58
|
|
|
rotor posted:the thing where a senior dev is working the junior dev like a coding puppet sucks, dont do that. > I AM A CODE POPSICLE
|
|
#
?
Nov 18, 2021 01:31
|
|
|
if robert martin has ever promoted a thing just assume that it is a bad idea
|
|
#
?
Nov 18, 2021 02:25
|
|
|
i had a good pair session right when i started my current gig. my boss, the guy who wrote all the code before i joined, was walking me through some profiling and basically rubber ducking each other on how to speed it up. it helped me to see how he wanted things prioritized in the code and to get my bearings in a codebase written by one guy. we hired another dev and i did the same process with him. we walked through some bug he had to work on and saw how we each debugged things and liked to approach problems. these are the only two pair sessions ive had. they were both immensely helpful for the new employee in both cases, and usedul for me in the latter case as the senior. i dont think i could work like this on the reg but it was v productive as a realtime knowledge transfer tool and getting exposure to different approaches man in the eyeball hat fucked around with this message at 03:30 on Nov 18, 2021 |
|
#
?
Nov 18, 2021 03:28
|
|
|
they made us do it in college. the explanation video stressed good etiquette like proper hygiene
|
|
#
?
Nov 18, 2021 04:20
|
|
|
man in the eyeball hat posted:i had a good pair session right when i started my current gig. my boss, the guy who wrote all the code before i joined, was walking me through some profiling and basically rubber ducking each other on how to speed it up. it helped me to see how he wanted things prioritized in the code and to get my bearings in a codebase written by one guy. wtf, i don't remember posting this srsly tho, i can also think of examples where pairing benefited the senior. in one case, the junior innocently posed a question that brought an architectural weakness to the senior's attention. narrator's voice: datroof was the senior
|
|
#
?
Nov 18, 2021 04:30
|
|
|
rotor posted:
i briefly worked on a team where the engineering director was like the mad hatter of software management. whatever hackernews article hoved into his vision was the NEW, MANDATORY PRODUCTIVITY IMPROVER. so for about 3 months, every dev who reported to this dude was required to pair, with an assigned partner, for 6 hours a day, swapping every 20 minutes at maximum. My partner and I played TDD red light, green light (A writes a failing test, B implements the minimum for the test to pass and writes the next failing test, A implements next minimum, writes next test, repeat ad infinitum) for most of that time. for useful pairing, as a senior dev, i've found that you can really build up junior dev confidence if you let them navigate, while only acting as a dictation machine.
|
|
#
?
Nov 18, 2021 05:06
|
|
|
i use my pair for programming
|
|
#
?
Nov 18, 2021 05:11
|
|
|
ayy, i got ya pair programming right here, pal!
|
|
#
?
Nov 18, 2021 05:24
|
|
|
QuantumPotato posted:i briefly worked on a team where the engineering director was like the mad hatter of software management. whatever hackernews article hoved into his vision was the NEW, MANDATORY PRODUCTIVITY IMPROVER. so for about 3 months, every dev who reported to this dude was required to pair, with an assigned partner, for 6 hours a day, swapping every 20 minutes at maximum. My partner and I played TDD red light, green light (A writes a failing test, B implements the minimum for the test to pass and writes the next failing test, A implements next minimum, writes next test, repeat ad infinitum) for most of that time. first impression: that sounds like absolute hell second impression: that might actually work well in certain circumstances, for certain tasks tell me if i'm wrong, but if your team was even kinda functional, i'd guess that process stopped being mandatory after a couple weeks but still happened organically on occasion
|
|
#
?
Nov 18, 2021 05:26
|
|
|
DaTroof posted:first impression: that sounds like absolute hell I think the team kept it up for 2 months. it was the most dysfunctional team i've ever been a part of. It was at a Fortune 50 company, so they had 5 star talent coming in all the time, but anyone who actually cared about their work/sanity either transferred out to another team or left the company. The remaining developers who worked under him were either trapped or just trying to fly under the radar to keep getting their 20% annual merit bonuses. They were a team of 12 that produced the work of 3. While i can appreciate the goldbricking, everybody seemed absolutely miserable. i was only there 6 months, because i was a consultant brought in to integrate some niche hardware with their mobile poo poo. Unfortunately, this dude didn't get the difference between contractor and consultant, so i'd constantly be fighting him on what i was supposed to be doing, having to explain to him that i didn't report to him, but to his boss, and having him try and write me up for weird poo poo (cue confused emails from HR). Eventually it all came to a head when he pulled me aside to have my "180 day performance review" (important context: according his company's rules, this was a HUGE NO-NO for consultants) with a printout of all my git commits from the previous 6 months, and a printout of another dev's commits, because they had "almost twice as many!". i sat through the whole thing, had him follow up with me via email, forwarded that to his boss and the owner of the firm i was at, and then promptly terminated the contract. The super cool, web 3.0 features they were promising at all the trade shows that year turned into vaporware. i heard he eventually got promoted. anyway. pairing is cool and good sometimes.
|
|
#
?
Nov 18, 2021 07:10
|
|
|
QuantumPotato posted:anyway. pairing is cool and good sometimes.
|
|
#
?
Nov 18, 2021 08:57
|
|
|
we have to pair at my new job and I don't hate it as much as I thought I would, it usually ends up as quads or triples though because no-one can hold more than about 5% of the system in their head at once. Tends to be one person drives for the morning, one for the afternoon, or change if the driver wants a break or whatever. mandatory swapping every 20 minutes sounds absolutely insanely distracting though, i wonder how many bugs that's caused
|
|
#
?
Nov 18, 2021 14:41
|
|
|
I'm more interested in pear programming. program them into my mouth
|
|
#
?
Nov 18, 2021 15:06
|
|
|
btw, the red light/green light refactor pairing is a really good way to learn a new language quick. learned that from a guy i worked with who used it as a game to teach people scala. when it's no pressure, it's actually fun.
|
|
#
?
Nov 18, 2021 15:51
|
|
|
I used to work in a job where pair programming was mandatory all day every day, never again. It's useful to teach people or unblock them, but not 100% of the time. At least we never had to do any mob programming.
|
|
#
?
Nov 18, 2021 16:29
|
|
|
the biggest problem is deciding what music to play
|
|
#
?
Nov 18, 2021 18:22
|
|
|
honestly pair programming is good if you have the right partner, and terrible if you don’t. when you’re navigating you have more time to think while the other guy is typing out the code. you have to keep talking through it as you do things. it is exhausting, but it’s also highly productive. decades ago when I was an intern they gave me and the other intern two machines, one a badass high end dual cpu (!) machine and the other some piece of garbage. so we accidentally discovered pair programming because neither of us wanted to work on the garbage machine. of course we were both idiots and didn’t know what we were doing, but we did get a lot further than either of us idiots on our own.
|
|
#
?
Nov 18, 2021 18:31
|
|
|
We almost started swarm programming, where the entire team yells as a single person who is driving, which rotates every 10 minutes or so, but then the lockdown happened and that saved us from that particular nightmare
|
|
#
?
Nov 18, 2021 21:43
|
|
|
Pair programming is almost always some guy asking you to help him find a bug and it's usually a huge relief when he realizes he need to recompile the entire project or pull the latest changes from perforce or whatever because it gives you a reason to excuse yourself until he has everything up and running
|
|
#
?
Nov 18, 2021 22:34
|
|
|
|
| # ? Jun 9, 2023 06:08 |
|
|
quote:Mob programming (informally mobbing) (aka. ensemble programming) is a software development approach where the whole team works on the same thing, at the same time, in the same space, and at the same computer. mob programming is when you and your buds occupy the same relativistic space time as one poor computer and rotate the poor soul who has to sit in front of it while getting yelled at
|
|
#
?
Nov 18, 2021 23:17
|
|