Pair Programming
Вставка
- Опубліковано 15 жов 2024
- Recorded live on twitch, GET IN
/ theprimeagen
Become a backend engineer. Its my favorite site
boot.dev?promo=PRIMEYT
This is also the best way to support me is to support yourself becoming a better backend engineer.
MY MAIN YT CHANNEL: Has well edited engineering videos
/ theprimeagen
Discord
/ discord
Have something for me to read or react to?: / theprimeagenreact
Kinesis Advantage 360: bit.ly/Prime-K...
Hey I am sponsored by Turso, an edge database. I think they are pretty neet. Give them a try for free and if you want you can get a decent amount off (the free tier is the best (better than planetscale or any other))
turso.tech/dee...
i love how instead of showing a subway surfers clip, he's showing us coding in neovim.
That's very distracting
I think pairing is a great onboarding tool for new hires. It's also a great way to work out a tricky bug or prevent knowledge silos. But teams that require 100% pair programming are just asking to destroy their team's morale.
Good, that validates that I've been doing it right. I feel bad sometimes when I work on my machine. The times you do have to control their machine though is if they need help with Git to even push the code to share with you
currently on a bootcamp and the amount of people that try and show screenshots of code to get help is unreal.
Git is so easy to learn and understand. I just don't get how programmers can be so smart to solve really tough problems but throw a Git problem at them and they are destroyed. I would apply the same smarts to solve the Git problem too.
@@adtcI don't think it's that they can't understand it, I think it's 2 things. 1, most people don't use Git commands at all or extremely rarely, they have some point-and-click intuitive Git integration in their IDE. 2, because they don't use it directly that much and don't understand it that well, they're scared of messing something up and deleting the codebase or messing up the main branch or some other unexpected behavior like that. So they just rather defer to someone who knows what they're doing. If they don't have some visual representation of exactly what's happening, they get uncomfortable. That's why I avoid anything but the simplest things in Git. I'm sure I could learn it but I'd rather learn it in a controlled consequence-free environment than on some production code, but I just haven't gotten around to doing that yet.
I’m loving the shorts. However, the out of context programming on the bottom is super distracting for my tiny brain 😖
shame it’s always the same clip
It's a necessary evil to keep the zoomers
It's a copycat account. They do it so they can steal content.
@@happy_thinkingthis is his main account
@@pythagoranzoomers who code don't need to see that distracting crap in the background - a zoomer
I think the big benefit from pair programming and mob programming is having to speak your train of thought to the operator that will actually change the code. That way you get the "rubber duck" effect and you eliminate code reviews, daily meetings and a lot of other stuff. The drawback is that you can no longer work give each individual a task , but in my experience that leads to better priorization. There is a tool called mob, that is a wrapper around git that allows for this type of coding philosophy even for remote teams.
I remember back when pair programming was all the rage and people said two keyboards and two mice and playing ping pong where one writes a test and another writes a piece of code to validate it or whatever. That was all a bit mental. In a remote working world I think VSCode with the sharing plugin is awesome. Makes navigating through things slightly easier than a regular screen share.
You can't delegate every task to two people. The best type of pair programming is for parallel tasks, aka tasks which don't rely on the other's work.
For instance in a pipeline that goes a to b to c, you can't do a pair programming by giving a to one guy, and b to another. It doesn't work. The guy who does a has the context and idea for what would work for b and c. Now, if b has alternative routes, then you can give each route to one, who are now using a, and working in parallel.
Working in a sequence at the same time is inefficient and frankly stupid. You can't code for sth you don't have the prerequisite for. Let one guy who has the best intuition for the work do the main development, and then you implement the additional updates in parallel to what he has made, so that it doesn't change the plan or structure. One sets the plan, the other follows in the parallel parts.
I think all this remote work has made pair programing easier. I preferred it even when I was in-office with my co-worker.
@@a.c.e7407 OK, but there are still studies being done to this day on pair programming so there seems to be value in it somewhere.
I think its quite a subjective topic that a few too many people either flat out say "No" to or "Yes," while designing code itself is quite subjective too and and sometimes subject to rewrite if done poorly.
Pair programming has worked excellently for me when I get good personality matches with people and people that don't have a big ego regardless of actual knowledge.
I do however agree in that the Venn diagram for all programmable tasks and pair programmable tasks does not overlap completely, but this is not very black-and-white or well defined either.
God forbid you work on an agreed upon environment.
That... Isn't pair programming. That's just collaborating on a change.
Collaborating on a change is _real work._ "Pair programming" is just a time waster.
@@adtc pair programming, done properly (i.e. none of what is being described here), can be very effective for some people. Y'all just sound like you suck at it.
@@adtc Well the way it was described the code review takes place after the person finishes coding. This sounds more like an interview exercise rather than actual collaboration.
Yeah. I love Prime but it seems like he hasn't had to collaborate on his job in years, as a solo internal tooling developer, so of course he doesn't care about having a setup friendly to other engineers.
@@nullptr. why would it matter if his setup isn’t friendly to other people? The code is no different than if it was on their setup and Prime would be the one interacting with it?
I’m currently the only programmer where I work but we will be hiring 2 more people in the next few months so I’m trying to make it so when they start the process of how I’ve been doing things is easy to understand.
I use vscode with the vim plugin so my setup isn’t anything crazy but is there a reason for other people to be able to use my setup?
So you mean more like normal collaboration with code review?
I did paired programming for a few years. I'd walk into work each day not knowing what machine I was going to use, or who I would be paired with. We sat face to face with two monitors mirroring each other and we both had a keyboard and mouse. After awhile, it got to be pretty draining.
Pair programming is, by definition, two developers on one machine. You do it this way in order to have someone check your work and contribute guidance as it's being written. Usually, differences in machine setups is a non-issue because most corporate shops standardize on an IDE and configuration. Learn to use Visual Studio Code; most of your coworkers will be using it and it will make pair programming that much easier.
That's... Onboarding and code review.
You can argue that "two keyboards, one screen" is ridiculous, and I tend to agree, but pair programming at least needs you both to be looking at the code as it is being written.
Giga-Chad JetBrains users: let me introduce you to Code With Me
"me show change. Then me eat change, because change taste like cookie" 😂
🍪
Strict pair programming treats us like Bynars from Star Trek. We're not Bynars. We're not Siamese twins.
My place of work did pair programming a bit, like 20 years ago.
It was always working on the typers machine.
The value was just in having a pair of eyes , and a brain not occupied with the immediate, in catching any issues before they enter the code base.
It wasn't an always thing, it and it was a bit of a luxury.
Belatedly occurred to me that in today's lingo we'd call it Continuous Review. 😆*hides*
Continuous Criticism@@blaedd
This split screen decision feels like a defeat of every principle.. but somehow it works. WHY BRAIN
The coding instead of subway surfers is truly great.
Artifical problem finding....
In pair programming specific day one only touches keyboard so you can gather at his machine...
We shouldn't have to compromise our own dev env just to let someone else edit text on our machines. This is a solvable problem.
I like this idea. Like docker but for editing code 😂😂
it's solved by using a proper IDE
Couldn’t even edge to this
Firefox is better 👀
😂❤ that's the reason why we do this only remote via the mob(-programming) git abstraction (written in go)... Otherwise, my colleagues would not be able to exit the project that is open in vim
The three "paths" shouldn't really be taken in that order necessarily. You don't want to remove somebody's code that they wrote just because they're less familiar with it. It should involve a common goal rather than two people outdoing each other.
Pair programming isn't about using the same machine though. Lol. It's about removing the overhead of a code review and the overhead of taking turns. It's a REAL-TIME code review. See, the problem of not doing something like test-driven development in this context is that you can immediately disagree with somebody's implementation simply because you do not agree with the use-case or test-case for the scenario. If you started with a test first, then it sort of communicates the beginning and end portions of writing the code together. Everything else in the middle is implementation.
Worst thing ever is someone asking you to look at something on his machine and he is using windows
AGREE! Pair programming is misunderstood and ridiculously misused. It's often a way to waste the time of two people simultaneously when each of them could be separately more productive. The term itself should be abolished and replaced with actual collaborative work.
This is so true. If you're a developer, the way most developers have their machine setup or how they code is stupid. We have a lead developer on our team who tells us "Absolutely no commented code. Any commented code will be rejected in a pull request." He goes ahead and commits some code and has a line of code commented out. I reject his code and he says I need to approve it because it's a valid case where commented code is okay. I hate him so much... my code is not acceptable, but his code is divine I guess. He even nit-picks my formatting, but his formatting is okay and shouldn't be nit-picked it seems... For example, I used to code CSS having brackets on their own line like C#, he forced me to change it to have the open bracket on the same line as the selector and only the closing bracket on it's own line. Yes, he literally blocked my pull request for days because he wouldn't accept it being anything other than how he wanted it to look. Meanwhile I find his formatting dumb, but because he is the lead he gets the say... BUT if he does anything against what he told you to do, it's okay because he has a perfectly valid reason for it. Ugh... if you don't think your co-worker's code is stupid, you are either not a developer doing pull requests or you haven't been a developer long enough. When I review a pull request, I just make sure the code looks like it functions properly. When he does it, he does that and forces his views on others. I don't care if you named a variable ID or id, SSN or Ssn or ssn, etc. as long as you're consistent. He is like no it must be Ssn on C# and SQL, ssn in JavaScript and CSS. I'm like who the F CARES stop being an asshole.
A consistent codebase with enforced conventions is actually a good thing.
Just that it'd be way more efficient to set up and configure a linter than doing it through PR reviews.
@@NeunEinser - It's not a good thing when they keep changing what is approved and rejected based on how they feel and only things they do are exceptions because it is convenient to them. I was completely okay with making things consistent, but that isn't what is happening.
@@TakaianaStormreaver I see. Well, some people just need this kind of egoic staisfaction, I suppose 🤷🏼♂
Seems like some retros to vent and come to terms are in order.
Not a big fan on pair programming tbh
he's coding without his hands!
Oh yea, I never realized you'd have to tell people your shortcuts for pair programming if you tried to actually pair outside of my generic intellij setting where we all used the same tools effectively the same way
vScODe live share 🙃
Is there a nvim plugin for doing something like this? Sshx maybe?
My take: honestly it makes the whole thing feel like work. However, whenever I pair programmed I never did any coding past 5PM.
It is down to you whether or not the benefits outweigh the negatives
my only dream is to pair program, but only with FL ❤
The larger orgs I've worked for had lots of spare conference rooms, some of which were usually empty. When we needed to get a second set of eyes on our work, we'd book a room and work from the projector. Each conference room had a dedicated laptop in it driving the projector. They were "neutral" machines w/ vanilla setups. That was all before the cv insanity and everybody indefinitely working from home. Everything is different now.
In the end we are all stupid
This is the first time I've watched a video on Rust, and my only other programming experience is over three years with Python. Everything resonated from the start! I'm wondering if this is due to the video creator's teaching skills, Rust's clear syntax (and its slight resemblance to lifetimes in Rust and generic type annotations in Python), or both. I can't wait to dive into this amazing-looking language and become a "functional bro"😅
This. Being dogmatic about dev envs is a terrible practice
I thought the video was supposed to be about pair programming. lol
@@retagainez it is 😅 he drives on his machine and his pair will drive on theirs. In a remote setting that works a lot easier. 🙌
in other words: "start working, that's what you are paid for"
use docker containers