|
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.
|
![]() |
|
![]()
|
# ¿ Mar 25, 2023 03:58 |
|
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
|
![]() |
|
its basically a live 2 way code review
|
![]() |
|
anyway i'm not here to say everyone should do it, but when it works well, it works really well.
|
![]() |
|
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"
|
![]() |
|
Shaggar posted:doesnt really work for peers tho it does, you just gotta do it right.
|
![]() |
|
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.
|
![]() |
|
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.
|
![]() |
|
the thing where a senior dev is working the junior dev like a coding puppet sucks, dont do that.
|
![]() |
|
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.
|
![]() |
|
QuantumPotato posted:anyway. pairing is cool and good sometimes.
|
![]() |
|
MrQueasy posted:I’m also adhd, and pair programming made me stay on task more and write higher quality stuff. it was also 3x as exhausting as my normal schedule of “random bursts of productivity from 2-16 hours long”. I'm not adhd and this is also my experience w/ pair programming
|
![]() |
|
rotor posted:I'm not adhd or maybe i am, idk, idgaf i'm too old to get diagnosed with things that arent stuff like "rheumatism" and "lumbago"
|
![]() |
|
dioxazine posted:never done it, but i would imagine i'd need personal rapport with a partner for this to work decently yeah its a very close social activity and even people who get along ok can feel a lot of tension and awkwardness. The first time I did it reminded me of having to slow dance with a stranger.
|
![]() |
|
![]()
|
# ¿ Mar 25, 2023 03:58 |
|
Captain Foo posted:what the gently caress yeah pivotal is pretty wild
|
![]() |