▲ 342 ▼ What are your programming hot takes? (lemmy.ml) submitted 2 years ago by 257m@lemmy.ml to c/programming@programming.dev 886 comments fedilink hide all child comments
[–] vvv@programming.dev 8 points 2 years ago (7 children) Mandatory pull requests + approvals within a team are a waste of everyone's time. permalink fedilink source hideshow 14 child comments replies: [+] bob_wiley@lemmy.world 11 points 2 years ago* (last edited 2 years ago) (1 child) [deleted] permalink fedilink source parent hideshow 2 child comments replies: [–] fusio@lemmy.world 11 points 2 years ago sounds like your company sucks. I'm sorry, must be lonely permalink fedilink source parent [–] apd@programming.dev 8 points 2 years ago Big hot take to me; especially in an organization with a large size and code high standard permalink fedilink source parent [–] fusio@lemmy.world 5 points 2 years ago depends on the company/team culture. are other people gonna have to fix or extend code you wrote? are you the sole engineer working on entire modules? do you hate feedback? permalink fedilink source parent [–] uniqueid198x@lemmy.dbzer0.com 5 points 2 years ago (3 children) We'v known this for twenty years and had the data ta back it up for ten. Github flow is one of the most damaging things to ever happen to software teams permalink fedilink source parent hideshow 6 child comments replies: [–] Sigmatics@lemmy.ca 5 points 2 years ago (1 child) Source? permalink fedilink source parent hideshow 2 child comments replies: [–] uniqueid198x@lemmy.dbzer0.com 2 points 2 years ago Got asked about this twice so I'm cut/pasting my answer, but happy to discuss further Check out the dora reports and the data Nicole Forsgren lays out in her book Accelerate. DORA reborts are free to access. She has found clear links between trunk based (no branching) development and a whole host of positive metrics. There is some suggestion that PRs are not too bad if always done at high quality and within the same day, but its weaker. permalink fedilink source parent [–] 10nica@hexbear.net 3 points 2 years ago (2 children) Omfg yes! Have nothing to add, but an upvote was not enough to express my hate for gitflow. So fucking stupid. And you'll show stats from Jez Humble etc about trunk based, and my boss was still "eh not convinced" permalink fedilink source parent hideshow 4 child comments replies: [–] nous@programming.dev 2 points 2 years ago gitflow != github flow Gitflow is far more complex and unnessaray for most places. You do not need a dev, main, and release branches. Github flow is far closer to trunk based dev - create a branch of master, PR back into master when done. If you keep your PRs small it gives you most of the benefits of trunk based dev with a CI check before you merge to the mainline. permalink fedilink source parent [–] TrustingZebra@lemmy.one 1 point 2 years ago* (1 child) Git Flow and GitHub Flow are entirely different branching strategies. permalink fedilink source parent hideshow 2 child comments replies: [–] uniqueid198x@lemmy.dbzer0.com 1 point 2 years ago (1 child) Gitflow is has the same issues permalink fedilink source parent hideshow 2 child comments replies: [–] TrustingZebra@lemmy.one 1 point 2 years ago (1 child) Git Flow is awful I absolutely agree. On the other hand I like GitHub Flow. permalink fedilink source parent hideshow 2 child comments replies: [–] uniqueid198x@lemmy.dbzer0.com 2 points 2 years ago Github flow has the same issues, in practice. Branching is the root cause, not the kind of branching. Even anonymous branches. Its the frequency of integration that matters. permalink fedilink source parent [–] fusio@lemmy.world 3 points 2 years ago (1 child) what data? just curios because there are so many ways to do PRs properly.. like for everything, if it's done badly better not do it. does not mean it is inherently bad permalink fedilink source parent hideshow 2 child comments replies: [–] uniqueid198x@lemmy.dbzer0.com 1 point 2 years ago Check out the dora reports and the data Nicole Forsgren lays out in her book Accelerate. DORA reborts are free to access. She has found clear links between trunk based (no branching) development and a whole host of positive metrics. There is some suggestion that PRs are not too bad if always done at high quality and within the same day, but its weaker. permalink fedilink source parent [–] TehPers@beehaw.org 3 points 2 years ago* (1 child) You must trust your team's abilities more than I trust my own. How often does your team merge bugs into main? We use CI primarily for running the full test suite, including integration tests and e2e tests that would be very difficult to run locally due to them using specific credentials to access testing resources. permalink fedilink source parent hideshow 2 child comments replies: [–] vvv@programming.dev 1 point 2 years ago (1 child) If your team consists of people you don't trust, that's the problem to fix first. permalink fedilink source parent hideshow 2 child comments replies: [–] TehPers@beehaw.org 1 point 2 years ago (1 child) I trust my team. I don't trust my or their ability to write and merge perfect code each time. I'm not sure how we'd fix that problem aside from becoming programming gods. permalink fedilink source parent hideshow 2 child comments replies: [–] vvv@programming.dev 1 point 2 years ago My point is, having PRs desn't result in perfect code either. They might help sometimes, maybe 10% of the time if I'm being generous, but the rest of the time they are a hindrance. The problems people tend to try and solve with them, validation and indoctrination are better solved with a good CD pipeline, and pairing sessions. permalink fedilink source parent [–] Sigmatics@lemmy.ca 2 points 2 years ago Depends how good you are at what you're doing. I'd argue that humans err and it saves a bunch of time to catch bugs before debugging in the wild permalink fedilink source parent [–] Templa@beehaw.org 1 point 2 years ago (1 child) Unless you have people that are known to delivery garbage code. Which is more common than you would imagine, lol. permalink fedilink source parent hideshow 2 child comments replies: [–] vvv@programming.dev 1 point 2 years ago The solution to that is pairing - spending a few hours collaborating with, and teaching this person will get them up to speed much faster than asynchronously nitpicking their code. permalink fedilink source parent
[+] bob_wiley@lemmy.world 11 points 2 years ago* (last edited 2 years ago) (1 child) [deleted] permalink fedilink source parent hideshow 2 child comments replies: [–] fusio@lemmy.world 11 points 2 years ago sounds like your company sucks. I'm sorry, must be lonely permalink fedilink source parent
[–] fusio@lemmy.world 11 points 2 years ago sounds like your company sucks. I'm sorry, must be lonely permalink fedilink source parent
[–] apd@programming.dev 8 points 2 years ago Big hot take to me; especially in an organization with a large size and code high standard permalink fedilink source parent
[–] fusio@lemmy.world 5 points 2 years ago depends on the company/team culture. are other people gonna have to fix or extend code you wrote? are you the sole engineer working on entire modules? do you hate feedback? permalink fedilink source parent
[–] uniqueid198x@lemmy.dbzer0.com 5 points 2 years ago (3 children) We'v known this for twenty years and had the data ta back it up for ten. Github flow is one of the most damaging things to ever happen to software teams permalink fedilink source parent hideshow 6 child comments replies: [–] Sigmatics@lemmy.ca 5 points 2 years ago (1 child) Source? permalink fedilink source parent hideshow 2 child comments replies: [–] uniqueid198x@lemmy.dbzer0.com 2 points 2 years ago Got asked about this twice so I'm cut/pasting my answer, but happy to discuss further Check out the dora reports and the data Nicole Forsgren lays out in her book Accelerate. DORA reborts are free to access. She has found clear links between trunk based (no branching) development and a whole host of positive metrics. There is some suggestion that PRs are not too bad if always done at high quality and within the same day, but its weaker. permalink fedilink source parent [–] 10nica@hexbear.net 3 points 2 years ago (2 children) Omfg yes! Have nothing to add, but an upvote was not enough to express my hate for gitflow. So fucking stupid. And you'll show stats from Jez Humble etc about trunk based, and my boss was still "eh not convinced" permalink fedilink source parent hideshow 4 child comments replies: [–] nous@programming.dev 2 points 2 years ago gitflow != github flow Gitflow is far more complex and unnessaray for most places. You do not need a dev, main, and release branches. Github flow is far closer to trunk based dev - create a branch of master, PR back into master when done. If you keep your PRs small it gives you most of the benefits of trunk based dev with a CI check before you merge to the mainline. permalink fedilink source parent [–] TrustingZebra@lemmy.one 1 point 2 years ago* (1 child) Git Flow and GitHub Flow are entirely different branching strategies. permalink fedilink source parent hideshow 2 child comments replies: [–] uniqueid198x@lemmy.dbzer0.com 1 point 2 years ago (1 child) Gitflow is has the same issues permalink fedilink source parent hideshow 2 child comments replies: [–] TrustingZebra@lemmy.one 1 point 2 years ago (1 child) Git Flow is awful I absolutely agree. On the other hand I like GitHub Flow. permalink fedilink source parent hideshow 2 child comments replies: [–] uniqueid198x@lemmy.dbzer0.com 2 points 2 years ago Github flow has the same issues, in practice. Branching is the root cause, not the kind of branching. Even anonymous branches. Its the frequency of integration that matters. permalink fedilink source parent [–] fusio@lemmy.world 3 points 2 years ago (1 child) what data? just curios because there are so many ways to do PRs properly.. like for everything, if it's done badly better not do it. does not mean it is inherently bad permalink fedilink source parent hideshow 2 child comments replies: [–] uniqueid198x@lemmy.dbzer0.com 1 point 2 years ago Check out the dora reports and the data Nicole Forsgren lays out in her book Accelerate. DORA reborts are free to access. She has found clear links between trunk based (no branching) development and a whole host of positive metrics. There is some suggestion that PRs are not too bad if always done at high quality and within the same day, but its weaker. permalink fedilink source parent
[–] Sigmatics@lemmy.ca 5 points 2 years ago (1 child) Source? permalink fedilink source parent hideshow 2 child comments replies: [–] uniqueid198x@lemmy.dbzer0.com 2 points 2 years ago Got asked about this twice so I'm cut/pasting my answer, but happy to discuss further Check out the dora reports and the data Nicole Forsgren lays out in her book Accelerate. DORA reborts are free to access. She has found clear links between trunk based (no branching) development and a whole host of positive metrics. There is some suggestion that PRs are not too bad if always done at high quality and within the same day, but its weaker. permalink fedilink source parent
[–] uniqueid198x@lemmy.dbzer0.com 2 points 2 years ago Got asked about this twice so I'm cut/pasting my answer, but happy to discuss further Check out the dora reports and the data Nicole Forsgren lays out in her book Accelerate. DORA reborts are free to access. She has found clear links between trunk based (no branching) development and a whole host of positive metrics. There is some suggestion that PRs are not too bad if always done at high quality and within the same day, but its weaker. permalink fedilink source parent
[–] 10nica@hexbear.net 3 points 2 years ago (2 children) Omfg yes! Have nothing to add, but an upvote was not enough to express my hate for gitflow. So fucking stupid. And you'll show stats from Jez Humble etc about trunk based, and my boss was still "eh not convinced" permalink fedilink source parent hideshow 4 child comments replies: [–] nous@programming.dev 2 points 2 years ago gitflow != github flow Gitflow is far more complex and unnessaray for most places. You do not need a dev, main, and release branches. Github flow is far closer to trunk based dev - create a branch of master, PR back into master when done. If you keep your PRs small it gives you most of the benefits of trunk based dev with a CI check before you merge to the mainline. permalink fedilink source parent [–] TrustingZebra@lemmy.one 1 point 2 years ago* (1 child) Git Flow and GitHub Flow are entirely different branching strategies. permalink fedilink source parent hideshow 2 child comments replies: [–] uniqueid198x@lemmy.dbzer0.com 1 point 2 years ago (1 child) Gitflow is has the same issues permalink fedilink source parent hideshow 2 child comments replies: [–] TrustingZebra@lemmy.one 1 point 2 years ago (1 child) Git Flow is awful I absolutely agree. On the other hand I like GitHub Flow. permalink fedilink source parent hideshow 2 child comments replies: [–] uniqueid198x@lemmy.dbzer0.com 2 points 2 years ago Github flow has the same issues, in practice. Branching is the root cause, not the kind of branching. Even anonymous branches. Its the frequency of integration that matters. permalink fedilink source parent
[–] nous@programming.dev 2 points 2 years ago gitflow != github flow Gitflow is far more complex and unnessaray for most places. You do not need a dev, main, and release branches. Github flow is far closer to trunk based dev - create a branch of master, PR back into master when done. If you keep your PRs small it gives you most of the benefits of trunk based dev with a CI check before you merge to the mainline. permalink fedilink source parent
[–] TrustingZebra@lemmy.one 1 point 2 years ago* (1 child) Git Flow and GitHub Flow are entirely different branching strategies. permalink fedilink source parent hideshow 2 child comments replies: [–] uniqueid198x@lemmy.dbzer0.com 1 point 2 years ago (1 child) Gitflow is has the same issues permalink fedilink source parent hideshow 2 child comments replies: [–] TrustingZebra@lemmy.one 1 point 2 years ago (1 child) Git Flow is awful I absolutely agree. On the other hand I like GitHub Flow. permalink fedilink source parent hideshow 2 child comments replies: [–] uniqueid198x@lemmy.dbzer0.com 2 points 2 years ago Github flow has the same issues, in practice. Branching is the root cause, not the kind of branching. Even anonymous branches. Its the frequency of integration that matters. permalink fedilink source parent
[–] uniqueid198x@lemmy.dbzer0.com 1 point 2 years ago (1 child) Gitflow is has the same issues permalink fedilink source parent hideshow 2 child comments replies: [–] TrustingZebra@lemmy.one 1 point 2 years ago (1 child) Git Flow is awful I absolutely agree. On the other hand I like GitHub Flow. permalink fedilink source parent hideshow 2 child comments replies: [–] uniqueid198x@lemmy.dbzer0.com 2 points 2 years ago Github flow has the same issues, in practice. Branching is the root cause, not the kind of branching. Even anonymous branches. Its the frequency of integration that matters. permalink fedilink source parent
[–] TrustingZebra@lemmy.one 1 point 2 years ago (1 child) Git Flow is awful I absolutely agree. On the other hand I like GitHub Flow. permalink fedilink source parent hideshow 2 child comments replies: [–] uniqueid198x@lemmy.dbzer0.com 2 points 2 years ago Github flow has the same issues, in practice. Branching is the root cause, not the kind of branching. Even anonymous branches. Its the frequency of integration that matters. permalink fedilink source parent
[–] uniqueid198x@lemmy.dbzer0.com 2 points 2 years ago Github flow has the same issues, in practice. Branching is the root cause, not the kind of branching. Even anonymous branches. Its the frequency of integration that matters. permalink fedilink source parent
[–] fusio@lemmy.world 3 points 2 years ago (1 child) what data? just curios because there are so many ways to do PRs properly.. like for everything, if it's done badly better not do it. does not mean it is inherently bad permalink fedilink source parent hideshow 2 child comments replies: [–] uniqueid198x@lemmy.dbzer0.com 1 point 2 years ago Check out the dora reports and the data Nicole Forsgren lays out in her book Accelerate. DORA reborts are free to access. She has found clear links between trunk based (no branching) development and a whole host of positive metrics. There is some suggestion that PRs are not too bad if always done at high quality and within the same day, but its weaker. permalink fedilink source parent
[–] uniqueid198x@lemmy.dbzer0.com 1 point 2 years ago Check out the dora reports and the data Nicole Forsgren lays out in her book Accelerate. DORA reborts are free to access. She has found clear links between trunk based (no branching) development and a whole host of positive metrics. There is some suggestion that PRs are not too bad if always done at high quality and within the same day, but its weaker. permalink fedilink source parent
[–] TehPers@beehaw.org 3 points 2 years ago* (1 child) You must trust your team's abilities more than I trust my own. How often does your team merge bugs into main? We use CI primarily for running the full test suite, including integration tests and e2e tests that would be very difficult to run locally due to them using specific credentials to access testing resources. permalink fedilink source parent hideshow 2 child comments replies: [–] vvv@programming.dev 1 point 2 years ago (1 child) If your team consists of people you don't trust, that's the problem to fix first. permalink fedilink source parent hideshow 2 child comments replies: [–] TehPers@beehaw.org 1 point 2 years ago (1 child) I trust my team. I don't trust my or their ability to write and merge perfect code each time. I'm not sure how we'd fix that problem aside from becoming programming gods. permalink fedilink source parent hideshow 2 child comments replies: [–] vvv@programming.dev 1 point 2 years ago My point is, having PRs desn't result in perfect code either. They might help sometimes, maybe 10% of the time if I'm being generous, but the rest of the time they are a hindrance. The problems people tend to try and solve with them, validation and indoctrination are better solved with a good CD pipeline, and pairing sessions. permalink fedilink source parent
[–] vvv@programming.dev 1 point 2 years ago (1 child) If your team consists of people you don't trust, that's the problem to fix first. permalink fedilink source parent hideshow 2 child comments replies: [–] TehPers@beehaw.org 1 point 2 years ago (1 child) I trust my team. I don't trust my or their ability to write and merge perfect code each time. I'm not sure how we'd fix that problem aside from becoming programming gods. permalink fedilink source parent hideshow 2 child comments replies: [–] vvv@programming.dev 1 point 2 years ago My point is, having PRs desn't result in perfect code either. They might help sometimes, maybe 10% of the time if I'm being generous, but the rest of the time they are a hindrance. The problems people tend to try and solve with them, validation and indoctrination are better solved with a good CD pipeline, and pairing sessions. permalink fedilink source parent
[–] TehPers@beehaw.org 1 point 2 years ago (1 child) I trust my team. I don't trust my or their ability to write and merge perfect code each time. I'm not sure how we'd fix that problem aside from becoming programming gods. permalink fedilink source parent hideshow 2 child comments replies: [–] vvv@programming.dev 1 point 2 years ago My point is, having PRs desn't result in perfect code either. They might help sometimes, maybe 10% of the time if I'm being generous, but the rest of the time they are a hindrance. The problems people tend to try and solve with them, validation and indoctrination are better solved with a good CD pipeline, and pairing sessions. permalink fedilink source parent
[–] vvv@programming.dev 1 point 2 years ago My point is, having PRs desn't result in perfect code either. They might help sometimes, maybe 10% of the time if I'm being generous, but the rest of the time they are a hindrance. The problems people tend to try and solve with them, validation and indoctrination are better solved with a good CD pipeline, and pairing sessions. permalink fedilink source parent
[–] Sigmatics@lemmy.ca 2 points 2 years ago Depends how good you are at what you're doing. I'd argue that humans err and it saves a bunch of time to catch bugs before debugging in the wild permalink fedilink source parent
[–] Templa@beehaw.org 1 point 2 years ago (1 child) Unless you have people that are known to delivery garbage code. Which is more common than you would imagine, lol. permalink fedilink source parent hideshow 2 child comments replies: [–] vvv@programming.dev 1 point 2 years ago The solution to that is pairing - spending a few hours collaborating with, and teaching this person will get them up to speed much faster than asynchronously nitpicking their code. permalink fedilink source parent
[–] vvv@programming.dev 1 point 2 years ago The solution to that is pairing - spending a few hours collaborating with, and teaching this person will get them up to speed much faster than asynchronously nitpicking their code. permalink fedilink source parent