How to Avoid Long Discussions in Pull Requests

#softwaredevelopment #webdevelopment #programming #softwareengineer
📽️ Live Stream - / programmer_network
👽 Github - github.com/agjs
📡 Programmer Network - programmer.net...
ℹ️ LinkedIn - / aleksandar-grbic-74670263
💬 Discord - / discord
🏫 Bootcamp - • Web Developer Bootcamp

[@Basil-the-Frog]

I agree with your comments about focusing on getting to a solution instead of arguing.

[@bladekiller2766]

is the background song from WoW? LOOOL BTW I had your perspective when there are a lot of comments, but some experienced dev suggested me that some teams want to work async and document the discussion for other people. But there is a catch here, which I thought about, and it seems to me that even if you go with the pair-programming approach, you can document the decision that you had from the session.

[@programmer-network]

Your Team/Tech Lead, or a CTO has responsibility to make your team productive. PR's should not be a place of frustration, ego-battles, etc. They are a place where 2 things happen: 1. We PROPOSE, NOT enforce opinions because they are our own 2. We share the knowledge and ask for knowledge If there is a fundamental disagreement, or especially, constant disagreements in the PR's, that means that the team doesn't have team guidelines, and that some part of the process has failed. If PR's are a source of frustration, and if they are making anyone feel bad, again, really bad. E.g. if you are constantly discussing code style, that means that your tooling is not properly setup. If your team mate is e.g. constantly pushing print statements as part of the PR's, that means that you never had a serious discussion about why it's important to review your own code first, before you push it to others. It's about respecting other people's time. There are a lot of these examples. So in simple words, PR's should be focused on BUSINESS LOGIC and if the feature works as it should or not. As much as possible, other things such is style, etc. should be handled by your tooling, and the rules you applied to your tools. You can of course suggest your colleague a better variable name, or a more efficient algorithm, but if your comment is directed to e.g. `why are you writing a function declaration and not a function expression`, that again means, you have a missing brick in your process, and this should have never ended up in the PR at the first place. E.g. an example would be, what I did for my team, you can create your own custom plugin tools for prettier, so if you as a team agree on a very specific thing, you can create your own custom tool that prettier will enforce across your project(s). Cheers :)

[@bladekiller2766]

@programmer-network yeah, completely agree, Usually, the source of disagreement in PRs is: - bad architecture - not properly configured style analysis tool, linter - miscommunication - bad docs about style, architecture, or something else But I think docs should be the most important component for resolving conflicts.

[@programmer-network]

​@@bladekiller2766 One could argue that documentation is fundamental part of every software engineering process, so I'm absolutely with you. Whatsoever, this is a huge danger zone, because again, PR's should be smooth, quick, etc. This of course relates to a different point, which is how your team is breaking tasks down, how are you releasing your code, etc. So the cause of bad PR's lays usually completely elsewhere. I just realized that I recorded a video: kzbin.info/www/bejne/maSolpicmauEl6M "How to do effective PR's" and I'm pretty much sharing my experience about this very subject. But what my experience as a software developer, and a leader as well, has thought me all these years is one, and the most fundamental thing when it comes to PR's: Don't make them a pain. Don't make your developers feel stressed when they have to push code. Make it smooth, going, etc. You have CD/CI.

[@alexandrebonfim8372]

Such coincidence!!! That was my week and KZbin suggested this video - creepy 😮

[@programmer-network]

Haha, well, I'm happy that at least for once, KZbin suggested a video to the right person :). I hope it helped. Cheers, Alex!

[@alexandrebonfim8372]

@@programmer-network, cheers it did! I created o notion with your points plus added “the hell week” and the value of a simple call. Feels like it “click” other heads . So, far work is going smoother this week 🎉

[@programmer-network]

That sounds awesome man, very happy to hear it. Let me know how it goes :).

[@05xpeter]

Learnt this the hard way

[@programmer-network]

Yep, I'd say, it's similar for most of us. One would go home and wonder "Why the hell did I need that?" I know, been there, too :8). Thanks a bunch for commenting, by the way!

[@Renan-g9n]

Audio is low

[@xExekut3x]

then turn it up?

[@Renan-g9n]

@@xExekut3x His voice is as loud as the background music itself, there is not turning it up that will fix that

[@xExekut3x]

@@Renan-g9n i understood him just fine. but yeah, maybe the bg music was a bit high compared to his volume.

[@programmer-network]

For sure, sorry for that. Maybe something has happened during recording of this video, e.g. in OBS or the software that made the volume messed up. Anyway, I hope you managed to increase the volume and hear it. Cheers