Week 1, Day 3 of bootcamp.
To get us used to working in industry standard practices this afternoon we coded a form (yes, it was basic but the conte...
For further actions, you may consider blocking this person and/or reporting abuse
Do you pair sometimes, on certain projects, or more frequently?
I do it occasionally, especially whenever I do not understand something that someone else wrote.
Do you always pair with the same person?
For the most part yes.
Do you CHOOSE the person you pair with?
Yes, I choose based on who I know has had something to do with what I am working on.
Have you paired with someone who was lazy - or a smartass?
Yes, normally they are the best people to pair with to be completely honest.
Does it ever stop being fundamentally awkward sitting very close to a colleague and reading over their shoulder?
I work from home so it is not really ever awkward.
In your opinion, is it a good practice and one you'd seek out in a new job?
It is a good practice and having someone else watching and trying to understand how your code will work helps you find some of those really annoying bugs you would have spent hours trying to find out.
Yeah, the dev business requires social skills like any other branch, sometimes even more, since you most likely must explain what you did or why some things do not work for a non-programmer.
Do you pair sometimes, on certain projects, or more frequently?
Whenever a problem occurs in the project that requires more planning or thought.
Do you CHOOSE the person you pair with?
Yes, I choose them for their problem-solving skills and the expertise they bring.
Have you paired with someone who was lazy - or a smartass?
Yeah, the it-business is filled with large egos, you have to alpha the shit out of them so they know you won't take their crap.
Does it ever stop being fundamentally awkward sitting very close to a colleague and reading over their shoulder?
No, hopefully, you end up in a tight team where people care for each other and goes out of their way to help their colleagues. Pairing is usually a very fun and productive experience for me. :)
In your opinion, is it a good practice and one you'd seek out in a new job?
It is indeed! Pair programming gives insights you otherwise would never get. And very few people are actually good problem solvers, we tend to "know" what the problem is before we solved it, locking us into a single thought process. Another point of view is kinda refreshing.
I'm still laughing at "alpha the shit out of them"
Having a team partner can be really good or really bad.
To make it good egos must be checked in at the door. It's usually better to throw away titles and rank opting just for progress. Ticketing systems keep you safely away from each other's code. Finally commit often, branch often and merge with squash often.
My only experience with pair programming is from a couple of high school programming competitions. It wasn't enjoyable, and we didn't do well, which soured me on the idea. It's definitely something I would avoid in the future.
Do you work in companies where it's a part of the culture now? Or tend to freelance?
Neither, actually. I'm currently looking for work as a programmer.
Due to my personality, pair programming drains my energy. The longer I'm in pair programming mode the bigger the break I'll need once it's done. I've been in few minutes pp, a whole day or even several days in a row. However I still like it and I see many advantages like:
However, as I said, I like doing it but no regularly.
To your questions:
I think the key is everyone is different.
I've paired with people who are amazing, sparking thoughtful discussions throughout, from variable names to architecture design. This tends to cause fewer rewrites, quicker code reviews and overall better code.
However I have also paired with know it alls who try to score one ups on you by correcting your typos, extremely argumentative people, and people who just have no clue what's going on. These experiences are considerable unproductive, and incredibly frustrating.
In my opinion there are a few times where pairing is truly worth the pain of having to explain your every move to someone else.
If the other person is more junior than you, making it more of a coaching session (also applies if you're the more junior person)
If you are covering a particularly difficult problem domain that has lots of pitfalls and potential places to mess up. A second pair of eyes can help you spot issues quicker. (I also put running update or delete sql clauses on a production database with this one)
If you are working on something new with fuzzy requirements where there will be lots of design choices and fundamental descicions to be made, having another person there to bounce ideas off can help you avoid overcomplicating things or getting the wrong abstraction.
But I think past those 3, I tend to not lean on extended pair programming, however will always advocate for calls and discussions at any time, even a quick 30 min pairing session to go over a problem can be helpful.
On separate note regarding pairing though perspex (sounds horrendous btw) I'd recommend doing a call over Teams or Zoom and sharing your screen if you can. Much better than shouting at plastic :)
And yes it does get easier and less awkward the more you know the code and the more you know the person.
Thank you for the reply - I do think that by general consensus today we're going to do Zoom pairing - the added advantage then is that as we progress through the weeks we can pair with people we're not sitting directly next to. (Can't switch desks : Covid.)
I wrote about the practicalities in this article "Does Pair Programming Work?" - medium.com/better-programming/does...
Hi Lynn - I've just read through and you've framed beautifully the concerns I had around the "humanity" of individual people on different days and in different moods, and how that fits with working as a seamless team. I'm glad there's a dialogue around it and your way of approaching working together seems really sensible. Thank you!
Thanks for this - I'll have a read now!