681

GOD DAMMIT STEVEN! NOT AGAIN! (lemmy.world)

submitted 7 months ago by Maven@lemmy.world to c/programmer_humor@programming.dev

72 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

[-] xmunk@sh.itjust.works 139 points 7 months ago

You already stopped Steven in a prior commit.

Also, if this is an organization setting, I'm extremely disappointed in your PR review process. If someone is committing vendor code to the repo someone else should reject the pull.

[-] Cqrd@lemmy.dbzer0.com 106 points 7 months ago

What if I told you a lot of companies don't have solid review requirement processes? Some barely use version control at all

[-] xmunk@sh.itjust.works 32 points 7 months ago

Sure, I understand... but if you're at one of those companies you should introduce it.

[-] FizzyOrange@programming.dev 27 points 7 months ago

Yeah... Usually if you join a company with bad practices it's because the people who already work there don't want to do things properly. They tend to not react well to the new guy telling them what they're doing wrong.

Only really feasible if you're the boss, or you have an unreasonable amount of patience.

[-] frezik@midwest.social 3 points 7 months ago

Usually, the boss (or people above the boss) are the one's stopping it. Engineers know what the solution is. They may still resent the new guy saying it, though, because they've been through this fight already and are tired.

[-] Ephera@lemmy.ml 9 points 7 months ago

Eh, if everyone knows what they're doing, it can be much better to not have it and rather do more pairing.

But yes, obviously Steven does not know what they're doing.

[-] firelizzard@programming.dev 8 points 7 months ago

Better to not have version control!? Dear god I hope I never work on anything with you.

[-] docAvid@midwest.social 16 points 7 months ago* (last edited 7 months ago)

Pretty sure they meant to not have review. Dropping peer review in favor of pair programming is a trendy idea these days. Heh, you might call it "pairs over peers". I don't agree with it, though. Pair programming is great, but two people, heads together, can easily get on a wavelength and miss the same things. It's always valuable to have people who have never seen the new changes take a look. Also, peer review helps keep the whole team up to date on their knowledge of the code base, a seriously underrated benefit. But I will concede that trading peer review for pair programming is less wrong than giving up version control. Still wrong, but a lot less wrong.

[-] firelizzard@programming.dev 2 points 7 months ago

Agreed. Even self-reviewing a few days after I wrote the code helps me see mistakes.

[-] Ephera@lemmy.ml 1 points 7 months ago

Well, to share my perspective – sorry, I mean, to explain to you why you're wrong and differing opinions are unacceptable:

I find that pairing works best for small teams, where everyone is in the loop what everyone else is working on, and which don't have a bottleneck in terms of a minority having much more skill or knowledge in the project.

In particular, pairing is far more efficient at exchanging information. Not only is it a matter of actively talking to one another just being quicker at bringing information across, there is also a ton of information about code, which will not make it into the actual code.

While coding, you've tried two or three approaches, you couldn't write it as you expected or whatever. The final snippet of code looks as if you wrote it, starting in the top-left and finishing bottom-right, with maybe one or two comments explaining a particularly weird workaround, but I'd wager more than 90% of the creation process is lost.

This means that if someone needs to touch your code, they will know practically none of how it came to be and they will be scared of changing more about it than at all necessary. As a result, all code that gets checked in, needs to be as perfect as possible, right from the start.

Sharing all the information from the creation process by pairing, that empowers a team to write half-baked code. Because enough people know how to finish baking it, or how to restructure it, if a larger problem arises.

Pairing is fickle, though. A bad management decision can easily torpedo it. I'm currently in a project, where we practically cannot pair, because it's 4 juniors that are new to the project vs. 2 seniors that built up the project.
Not only would we need to pair in groups of three to make that work at all, it also means we need to use the time of the seniors as efficiently as possible and rather waste the time of the juniors, which is where a review process excels at.

[-] Ephera@lemmy.ml 2 points 7 months ago

Ah, no, I meant a review process. Version control is always a good idea.

[-] firelizzard@programming.dev 2 points 7 months ago

Ah, yeah that makes a lot more sense

[-] wewbull@feddit.uk 1 points 7 months ago

That's a big fucking "if"

[-] dylanTheDeveloper@lemmy.world 12 points 7 months ago* (last edited 7 months ago)

I've seen people trade zip archives like Yo-Ge-oh cards useing excel as a source control manager so it could be much MUCH worse

[-] littlewonder@lemmy.world 10 points 7 months ago* (last edited 7 months ago)

Dude, put content warnings on this. I have trauma from shared drives and fucking Jared leaving the Important File open on his locked computer while he takes off for a week, locking out access to anyone else.