|
Personally think people get a bit silly with “please approve” vs “please review.” But that’s developers for you.
|
# ? Oct 5, 2023 16:34 |
|
|
# ? May 13, 2024 14:35 |
|
i avoid this whole mess by committing straight to main
|
# ? Oct 5, 2023 18:57 |
|
Aramoro posted:Start killing people. It's the only way they'll learn. quote:Cole: I see deprecated people.
|
# ? Oct 5, 2023 19:05 |
|
downout posted:One of our teams has a bunch of engineers that always ask “please approve this PR!” I have never been on a team with opt-in (ie: no tech lead with sole responsibility for) code reviews where you didn't have to assign, notify and otherwise bug people into actually doing them.
|
# ? Oct 5, 2023 19:23 |
|
smackfu posted:Personally think people get a bit silly with “please approve” vs “please review.” But that’s developers for you. Fair enough, this team has been driving me nuts because they have been rubberstamping questionable quality commits for a long time. In that context, I think the asking for approval vs asking for code review is emblematic of issues.
|
# ? Oct 5, 2023 19:30 |
|
Agree there. We’ve definitely had people who considered rubber stamping a PR to count as their work for that hour, without even doing any actual review. Makes a mockery of the process, it does.
|
# ? Oct 5, 2023 22:41 |
|
Steve French posted:There’s an epidemic among my coworkers where they use “deprecated” to mean “removed/deleted” and I can’t handle it. I've started to see 'demised' used more and more, eurgh.
|
# ? Oct 5, 2023 23:41 |
|
This feature has been taken out back and shot.
|
# ? Oct 6, 2023 00:51 |
|
I just unalived that feature 🫣🫣
|
# ? Oct 6, 2023 01:26 |
|
This module has been sent to a nice farm upstate.
|
# ? Oct 6, 2023 01:59 |
|
ThePopeOfFun posted:This feature has been taken out back and shot. I committed premeditated murder in the first degree on Feature XYZ $ticketlink
|
# ? Oct 6, 2023 02:19 |
|
I heard "operationalize" once so I nominate "deoperationalize"
|
# ? Oct 6, 2023 02:23 |
|
We have a project with a train metaphor in it and part of the discussion led to talk about left over child processes people were getting annoyed with murder and killing the children, so someone suggested decouple, and it became 'decouple with prejudice'
|
# ? Oct 6, 2023 03:25 |
|
I'd go with "terminate" if "kill" isn't acceptable.
|
# ? Oct 6, 2023 03:37 |
|
Yeys hallo I vood lyke to liqvidate seferal chillldren pleas und zank yu.
|
# ? Oct 6, 2023 04:54 |
|
Bongo Bill posted:I'd go with "terminate" if "kill" isn't acceptable. just have to put it in monotype: code:
|
# ? Oct 6, 2023 13:17 |
|
fatal error: attempted to decouple child before execution
|
# ? Oct 6, 2023 14:26 |
|
Bongo Bill posted:I'd go with "terminate" if "kill" isn't acceptable. that term is actually more strongly associated with "kill" than "kill" for me. if only there weren't a popular movie series featuring a robot that goes around terminating people by that name.
|
# ? Oct 6, 2023 17:38 |
|
Bruegels Fuckbooks posted:that term is actually more strongly associated with "kill" than "kill" for me. if only there weren't a popular movie series featuring a robot that goes around terminating people by that name. Now I'm imagining an alternative world where the series is just called KILLER and it's pretty amusing.
|
# ? Oct 6, 2023 18:47 |
|
Bruegels Fuckbooks posted:that term is actually more strongly associated with "kill" than "kill" for me. if only there weren't a popular movie series featuring a robot that goes around terminating people by that name. That's why I suggest EXTERMINATE
|
# ? Oct 6, 2023 20:07 |
|
Hughlander posted:That's why I suggest EXTERMINATE Sorry, that one has been done
|
# ? Oct 6, 2023 21:19 |
|
Work has all SWE staff going through a three hour long training program that commits the ultimate training program sin of unskippable video tutorials. The entirety of it amounts to "review the OWASP top 10." We now have to do this same training every quarter.
|
# ? Oct 6, 2023 22:07 |
|
MadFriarAvelyn posted:Work has all SWE staff going through a three hour long training program that commits the ultimate training program sin of unskippable video tutorials. I hope you can place it in another window and mute it.
|
# ? Oct 6, 2023 22:22 |
|
Does it have little quizzes after each section? I hate that. But I did learn that with some of the videos I could just see a full transcript and quickly read that.
|
# ? Oct 6, 2023 22:30 |
|
lifg posted:Does it have little quizzes after each section? I hate that. But I did learn that with some of the videos I could just see a full transcript and quickly read that. I have a note in obsidian with the answers to each of those quizzes from previous times since they don't randomize questions or answers.
|
# ? Oct 7, 2023 01:33 |
|
The worst is when you have to get all the questions correct in the pre-quiz to skip the training and one of them is like “how many days do you have to respond to a reported security incident?” And the options are completely arbitrary.
|
# ? Oct 7, 2023 01:40 |
|
Ask if they have a transcript version available for the hearing-impaired, and if you can read that instead of watching the video. If the answer is yes, you've saved yourself some time - if the answer is no, things might get even more entertaining!
|
# ? Oct 7, 2023 01:47 |
|
In Connecticut, you have to do two hours of anti discrimination / harassment training, which works fine if it’s a class. We have online training so if you finish before two hours, it just shows a screen with a countdown timer and a disabled Continue button. Great job.
|
# ? Oct 7, 2023 01:54 |
|
thotsky posted:I have never been on a team with opt-in (ie: no tech lead with sole responsibility for) code reviews where you didn't have to assign, notify and otherwise bug people into actually doing them. Tech lead with sole responsibility for reviews sounds ghastly. And assigning/notifying people is normal, do you expect everyone to just look at all open PRs at all times to write notes? How do they know that the PR is ready? How do they know the PR should interest them?
|
# ? Oct 7, 2023 19:18 |
|
Agree that assigning people to PRs is good, one of my bookmarks is the "assigned to me" list on Github. Bugging people to actually do the reviews is so annoying though, I feel like an overbearing parent reminding people of their own work
|
# ? Oct 7, 2023 20:18 |
|
There was a tool at my last job that would auto assign review requests to people in the team (round robin or something). You could always kick it to someone else if you needed to, but it was a great way to prevent people's changes from languishing, or from the same people reviewing over and over.
|
# ? Oct 7, 2023 20:32 |
|
One I kind of liked was based on the area of the code people were assigned as required automatically, when there were no required people that didn't sign off you submitted. Culturally if someone didn't engage in a certain amount of time they were moved from required to optional.
|
# ? Oct 7, 2023 20:49 |
|
Am I the odd one out for enjoying PRs? I find they're one of the best places to spend time if your goal is increasing code quality. downout posted:One of our teams has a bunch of engineers that always ask “please approve this PR!” Culture is a hard thing to change. They misunderstand the point of a PR. The question the reviewer is answering is not "does this do the thing?" - the author asserted that it does the thing when they opened the PR. The question is "can this be made better?" which can almost always be answered with "yes." From there the conversation can be about the relative effort and value of any proposed changes, and by that collaboration you will nearly always walk away with an improved solution. And who knows, somebody might learn something
|
# ? Oct 7, 2023 21:02 |
|
Xarn posted:Tech lead with sole responsibility for reviews sounds ghastly. And assigning/notifying people is normal, do you expect everyone to just look at all open PRs at all times to write notes? How do they know that the PR is ready? How do they know the PR should interest them? I vastly prefer having a tech lead with the sole, or at least primary responsibility for performing code reviews. Otherwise it just takes too long to get them done. Developers who have tickets of their own are not going to drop whatever they're doing to review mine, and ideally I want to have several PRs go through in a single workday. I have worked at places where code reviews were meant to be handled communally by people checking the open PR page whenever they were not working on something, which resulted in them never getting done. I agree that bugging people about PRs is the norm; downout is the dude who seems to think that's weird. Also, you don't post PRs before they're ready. If you absolutely have to (horrible, means it's a branch that's definitely living too long or that what you really want to do is a bit of pair programming) you mark them with WIP. thotsky fucked around with this message at 22:23 on Oct 7, 2023 |
# ? Oct 7, 2023 22:12 |
|
Clanpot Shake posted:Am I the odd one out for enjoying PRs? I find they're one of the best places to spend time if your goal is increasing code quality. More succinctly, the purpose of the code review is to be the author, six months later, asking "what stupid rear end in a top hat wrote this," except that you can gently point things out before they get committed to the indelible ledger of shame that is your source control repository.
|
# ? Oct 7, 2023 22:37 |
|
Clanpot Shake posted:Am I the odd one out for enjoying PRs? I find they're one of the best places to spend time if your goal is increasing code quality. Depends on who the PR is from. Reviewing PRs from people who actually want to have their code reviewed and are eager for feedback can be both productive and satisfying. Reviewing PRs from people who get offended if you suggest that their code is not absolutely perfect is incredibly frustrating. Many developers just plain don't like to read code and reviewing PRs is nothing but reading code. Xarn posted:Tech lead with sole responsibility for reviews sounds ghastly. And assigning/notifying people is normal, do you expect everyone to just look at all open PRs at all times to write notes? How do they know that the PR is ready? How do they know the PR should interest them? You check for PRs at the start of the day and then later when you have a gap. You know that a PR is ready because it exists and isn't marked as a draft. In a small team every PR is relevant to you because you shouldn't be siloed off with like four people. Obviously in a larger team you need more structure, but it's really not very complicated.
|
# ? Oct 7, 2023 22:57 |
|
quote:Many developers just plain don't like to read code and reviewing PRs is nothing but reading code. It's actually very nice, because you can say "please add tests" and you do not have to write the tests yourself
|
# ? Oct 7, 2023 23:19 |
|
thotsky posted:I vastly prefer having a tech lead with the sole, or at least primary responsibility for performing code reviews. Otherwise it just takes too long to get them done. Developers who have tickets of their own are not going to drop whatever they're doing to review mine, and ideally I want to have several PRs go through in a single workday. I don't think it's weird, I think it's a problem when it's treated as a check box and no review is happening. "approval" vs "review" edit: the bugging people is fine, gotta let people know somehow that there is a task for them to do. downout fucked around with this message at 00:18 on Oct 8, 2023 |
# ? Oct 8, 2023 00:15 |
|
In general, if you ask a room of people to something that is more complex or time consuming than to water a plant, you will not get a response. It does not matter how many people are in the room.
|
# ? Oct 8, 2023 00:47 |
|
|
# ? May 13, 2024 14:35 |
|
Pretty much. You need to have a system that asks a specific person to do the review, and a team culture that expects them to do their assigned reviews in a somewhat timely fashion.
|
# ? Oct 8, 2023 00:54 |