|
IME the way to get developers to do PRs in a timely fashion is to wait until they complain about it in a retro, and then suggest a new rule that all PRs are reviewed within a day (or something). Since they complained about it, they’ll buy in to the new rule.
|
#
?
Oct 8, 2023 01:20
|
|
|
|
| # ? May 9, 2024 21:56 |
|
|
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 feel like this misses some huge benefits of code review: it doesn’t just make the code better, it’s a knowledge sharing tool. People learn from having their code reviewed, even if it’s not by someone more experienced (“ah I guess this pattern is confusing to less experienced people”), and even if they’re the one reviewing the code (reading code in general is educational and makes you better at writing it, as does asking clarifying questions and getting answers when something doesn’t make sense).
|
|
#
?
Oct 8, 2023 02:52
|
|
|
Team cohesion and shared responsibility. It makes the structure of a team a web of information rather than a hub-and-spoke.
Blinkz0rz fucked around with this message at 04:18 on Oct 8, 2023 |
|
#
?
Oct 8, 2023 03:04
|
|
|
Do you all normally pull the feature branch and run the code to test it manually? We have a react native codebase and it's expected for reviewers to build the app and test the feature manually. If you approve something with a bug and haven't tested it manually it's almost as much your fault as the submitters, no matter how detailed and documented the MR has been. IMO if your code passes the scrutiny of your reviewers reading your MR, passes the build pipeline and you create a bug, it's 100% on you to fix and shame for not having a test setup that isn't garbage. This has led to people being super cautious about issuing approvals and generally pisses me off.
|
|
#
?
Oct 8, 2023 03:31
|
|
|
people being hesitant on approvals can be a bit of a vicious circle, because having approvals be this high-friction involved process means that people pack more into each PR so they have to go through the process less often, which makes PRs more risky and approvers more hesitant, and so on. having a fast and lightweight process for getting small, low-risk prs approved really helps with development velocity. if it's not obvious to me that a pr is correct, i'll ask the author how they tested it, and ask them to write automated tests if appropriate. if it looks like they tested it properly but a bug slips through regardless, that's a team issue where we discuss how to catch this class of bug earlier. the other thing to consider is the consequences of a bug getting through. usually if a bug scenario is rare enough that the original author didn't catch it while making the pr, it's not a big deal if it gets approved, submitted, and then rolled back after the bug is found. assuming you have release qa that would catch it before going to actual production users, that is - if you have some kind of push-on-green setup where you rely 100% on automated tests then you do need to be more cautious.
|
|
#
?
Oct 8, 2023 04:14
|
|
|
Steve French posted:I feel like this misses some huge benefits of code review: it doesn’t just make the code better, it’s a knowledge sharing tool. People learn from having their code reviewed, even if it’s not by someone more experienced (“ah I guess this pattern is confusing to less experienced people”), and even if they’re the one reviewing the code (reading code in general is educational and makes you better at writing it, as does asking clarifying questions and getting answers when something doesn’t make sense). I think all of that still happens to a reasonable degree even when you have a person on the team with the primary responsibility for performing code reviews. It can be a back and forth, and sometimes the tech lead needs stuff reviewed too. That said, I also don't buy into the criticality of involving the entire team in backlog refinement, planning poker and stuff like that so I might just favor more hierarchy in teams than you and Blinkz0rz.
|
|
#
?
Oct 8, 2023 04:42
|
|
|
Guys et girls and everything in between or on the fringe, before we move to another page, I want to take 1/40 of this page to say how impressed I am that this thread got to page  That’s it
|
|
#
?
Oct 8, 2023 18:34
|
|
|
a dingus posted:Do you all normally pull the feature branch and run the code to test it manually? We have a react native codebase and it's expected for reviewers to build the app and test the feature manually. If you approve something with a bug and haven't tested it manually it's almost as much your fault as the submitters, no matter how detailed and documented the MR has been. IMO if your code passes the scrutiny of your reviewers reading your MR, passes the build pipeline and you create a bug, it's 100% on you to fix and shame for not having a test setup that isn't garbage. This has led to people being super cautious about issuing approvals and generally pisses me off. At least on my team, we don't do that, and the biggest reason is that the tool we're working on modifying infrastructure - testing it manually requires a lot of setup (getting the infra into the unfixed state, running it, checking the output matches/etc). We basically say 'if you open a PR that could need manual testing afterward, provide proof of your own manual testing in the associated task', because otherwise you might not understand how to do the manual testing in question. If it's something small that I can test locally and is specific to the app, I'd probably test it myself just to poke around at it, but that's not really the sort of thing I'm working on. In general, I think it's a bad idea to add more friction to code reviews of any kind, but honestly the biggest problem you're mentioning here is a cultural one - bugs happen, you can't fully prevent them, so unless it's something super obvious you probably should not be dunking on people for shipping bugs, you should be discussing how to prevent it from happening again. Edit: Slight clarification: you can try to fully prevent bugs, but no reasonable company is going to agree to the sort of timeline and design behaviors that NASA does with space shuttles or that medical device manufacturers do for embedded pacemakers or whatever; you're looking at more than a 10x timeline increase at the minimum. The bare reality is that companies make deliberate decisions to take on some level of risk associated with software development in exchange for change velocity, so when that risk manifests, it's generally not the fault of the individual developer, but instead the collective fault of the team, and the best discussion to have is 'what can we reasonably do to try and lower the chances of this happening again?'. A good company will not blame the individual, as long as they didn't do something egregiously stupid like bypassing reasonable safety measures with good reason. Falcon2001 fucked around with this message at 22:00 on Oct 8, 2023 |
|
#
?
Oct 8, 2023 21:56
|
|
|
a dingus posted:Do you all normally pull the feature branch and run the code to test it manually? We have a react native codebase and it's expected for reviewers to build the app and test the feature manually. If you approve something with a bug and haven't tested it manually it's almost as much your fault as the submitters, no matter how detailed and documented the MR has been. IMO if your code passes the scrutiny of your reviewers reading your MR, passes the build pipeline and you create a bug, it's 100% on you to fix and shame for not having a test setup that isn't garbage. This has led to people being super cautious about issuing approvals and generally pisses me off. On my team, often we'll reserve doing this for two cases: when reviewing code for developers that are still new at the company and are still learning the ropes of the codebase and for changes that are known to be high risk. Once someone has gotten used to working with the codebase this will happen less and less, though maybe with slight suggestions on additional testing notes they'll want to call out when passing a ticket to QA, who often does a manual test themselves before writing Cypress tests to reduce manual testing for changes moving forward. We also aggressively feature flag all of the changes we make, so if something breaks, oh well. Turn the flag off, throw a party if it's the developers first time breaking something in prod, get a fix in and try again tomorrow.
|
|
#
?
Oct 8, 2023 22:15
|
|
|
quote:We have a react native codebase and it's expected for reviewers to build the app and test the feature manually. Personally, I would just ask that there's sufficient test coverage (including integration tests etc) that it isn't necessary.
|
|
#
?
Oct 8, 2023 22:25
|
|
|
AskYourself posted:Guys et girls and everything in between or on the fringe, before we move to another page, I want to take 1/40 of this page to say how impressed I am that this thread got to page Forgot to mention, whoever does the 17th post would be the 420.68th page, which is the closest you can get to 420.69. Just putting that out there.
|
|
#
?
Oct 8, 2023 22:27
|
|
|
Glad Im not crazy about the high friction MRs. At some point you gotta build poo poo and ship it.
|
|
#
?
Oct 9, 2023 04:09
|
|
|
a dingus posted:Do you all normally pull the feature branch and run the code to test it manually? We have a react native codebase and it's expected for reviewers to build the app and test the feature manually. If you approve something with a bug and haven't tested it manually it's almost as much your fault as the submitters, no matter how detailed and documented the MR has been. IMO if your code passes the scrutiny of your reviewers reading your MR, passes the build pipeline and you create a bug, it's 100% on you to fix and shame for not having a test setup that isn't garbage. This has led to people being super cautious about issuing approvals and generally pisses me off. This sounds so, so stressful. I work for a live streaming service and we can run our services locally but it's not expected of code reviewers. Also, we don't even blame the committer for a bug much less the code reviewer. The creator of the bug usually fixes it because they have the most context on the code and maybe the bug finder helps (if it was another developer). If a bug happens there's no "blame" the team needs to evaluate why it go through and provide a wider fix (refactor an abstraction)/write better integration tests/etc. The last thing you want is "blame" and "shame" anyone because that's going to stop your velocity of doing complex stories, no one will want to go through that.
|
|
#
?
Oct 9, 2023 16:40
|
|
|
I got a splinter under my index finger's fingernail last night from a loving door of all things. It hurts my fingat to type 
|
|
#
?
Oct 9, 2023 16:49
|
|
|
a dingus posted:Do you all normally pull the feature branch and run the code to test it manually? I’ll only do this if it’s UI code and I’m not confident in the dev’s UI work. It’s pretty easy to make working UI code that passes all the tests but has some quirky behavior that looks bad. Backend code, I feel like tests work better.
|
|
#
?
Oct 9, 2023 23:32
|
|
|
Hate slack canvases
|
|
#
?
Oct 16, 2023 16:14
|
|
|
No idea where else to post this. I have two employers, one using G Suite and one using Office 365. As a computer touching goon, my personal preferences are odd at best and I prefer using Outlook for email management on the desktop. So what I've done to facilitate this is, I've logged into my G Suite account into Outlook alongside the Office 365 account so I can have my emails and calendar in one application. This is great, except some setting somewhere is syncing my G Suite calendar right onto my Office 365 calendar, often duplicating events on the Outlook calendar view. What's worse is if the event is updated, like the date or time changes, the Office 365 instance persists indefinitely as it was originally, so I have some phantom recurrences on my calendar now. Fortunately the update syncs to the G Suite calendar in Outlook just fine. Total shot in the dark, but anyone have any idea where to look for disabling this behavior? I've scoured the Outlook settings and I can't find anything on either account. It's limited settings for the G Suite connection, mostly credential management and cache clearing. Macichne Leainig fucked around with this message at 19:30 on Oct 16, 2023 |
|
#
?
Oct 16, 2023 19:28
|
|
|
Welp, after three years of being fully remote my company is pushing for >50% of all work time spent in the office and I've gotten a new boss who's the false empathy control freak type. Guess it's time to move on. It sucks because I was finally starting to get heard about accessibility stuff.
|
|
#
?
Oct 19, 2023 11:09
|
|
|
I am not particularly happy about the trajectory of my current company, so I am interviewing again. Apart from the usual interviewing bullshit ("competitive salary" -> proceeds to offer what would be ~25% paycut), I am continuously amazed at just how bad are recruiters at their job. I ticked the "remote work only" option on every platforms where I have a profile, why the gently caress do you send me job that is on-site and NOT EVEN ON THE SAME CONTINENT? Similarly, half your job is talking with people. Why do you not even have a microphone and rely on the built-in mic in your tablet? Just uuuugh.
|
|
#
?
Oct 19, 2023 13:31
|
|
|
As far as I can tell from my search this spring and summer: At best all the good recruiters are 1) at the best companies, 2) overworked, 3) were laid off. So that leaves a lot of stress for the ones who are left remaining and slows everything down. I’ve worked with some good internal recruiters who were extremely mindful of helping candidates have all the right material to be ready, lining up the right people for panel interviews, and really good at figuring out what teams are looking for in a candidate. And then they all got laid off anyway in the last 18 months of turmoil and are begging for contract gigs. That said, sending a job req for a different continent could be fun if they have relocation…
|
|
#
?
Oct 19, 2023 13:39
|
|
|
Xarn posted:I am not particularly happy about the trajectory of my current company, so I am interviewing again. "You never know if you don't try!  "Also, you're assuming they even remember who you are between emails.
|
|
#
?
Oct 19, 2023 13:42
|
|
|
Quantity over quality has been the strategy in all sorts of applications for a while now. It's not like you're going to switch jobs because you have a warm relationship with the recruiter.
|
|
#
?
Oct 19, 2023 15:42
|
|
|
This place is driving me crazy, we do these longass design forms now and the boss still swoops in and has us do whatever setup he wanted anyways. And afterwards any issues are going to get pinned on the person he overruled.
|
|
#
?
Oct 21, 2023 17:12
|
|
|
brand engager posted:This place is driving me crazy, we do these longass design forms now and the boss still swoops in and has us do whatever setup he wanted anyways. And afterwards any issues are going to get pinned on the person he overruled. Have you tried saying, No?
|
|
#
?
Oct 21, 2023 17:24
|
|
|
Or just not really bothering giving a poo poo on the design if it's going to get changed anyway?
|
|
#
?
Oct 21, 2023 17:28
|
|
|
Well my company culture has taken a big poo poo recently, to the point that the newly appointed VP of Engineering has informally complained about me to HR, and formally complained about my supervisor, to the point that my supervisor is leaving on Wednesday. The reason the VP of Engineering is complaining about me? He sent an email last week asking if we had any resources on private servers. I said no, because we do not. We don't even have dev or prod servers or anything like that yet. He replied, "not even on your local machine?" to which I replied, much more politely, "how do you think we develop the platform you loving idiot?" Be specific if you're going to ask questions. I shouldn't have to explain this to a loving VP. So he cried to HR because he didn't get the answers he wanted. Anyway I'm hemming and hawing sending an email to HR and the CEO about this VP dude since I've practically already got two feet out the door.
|
|
#
?
Oct 23, 2023 18:49
|
|
|
Yeah he PM'd me directly and got real nasty even though I specifically told him "I hope you understand that in light of recent events, I believe it's best for both of us to ensure that our communications are transparent and documented. I'd prefer if we can include a third party or have our conversations on open channels from now on. It's important for me to maintain an environment where I feel comfortable and protected. Thank you for your understanding." So I sent the email to the CEO. gently caress'em
|
|
#
?
Oct 23, 2023 19:38
|
|
|
You expect upper management to take your side over the VP? Sounds like the dude asked a dumb question and you overreacted. People in management tend to ask a lot of dumb questions, and don't take too kindly to being met with insubordination. What are you hoping to achieve by escalating? What is your plan B if it backfires?
|
|
#
?
Oct 23, 2023 20:08
|
|
|
He's been a constant problem for other people, making one engineer straight up leave, not to mention his beef with my supervisor. I don't think they're going to take his side If they fire me, I am very financially secure and don't have to work for years.  The company needs me more than I need them Also not to mention that he informally complained to HR about not getting any response for me despite the fact I replied within 5 minutes of his email, so that's at least demonstrably false. Macichne Leainig fucked around with this message at 20:49 on Oct 23, 2023 |
|
#
?
Oct 23, 2023 20:11
|
|
|
I feel for you if there guy is an idiot, but your not helping yourself responding to them in that manner.
|
|
#
?
Oct 23, 2023 22:24
|
|
|
The CEO and I just got off a call and it went great so gently caress all y'all haters. He's gonna tell the VP to gently caress off and that he should know to be more tactful considering the VP drove off another developer already
|
|
#
?
Oct 23, 2023 22:29
|
|
|
Macichne Leainig posted:The CEO and I just got off a call and it went great so gently caress all y'all haters. He's gonna tell the VP to gently caress off and that he should know to be more tactful considering the VP drove off another developer already Bottle this optimism for later
|
|
#
?
Oct 23, 2023 22:30
|
|
|
I promise I know a lot more about my employment situation and whether or not it will pan out in my favor, but I do appreciate the concern.
|
|
#
?
Oct 23, 2023 22:34
|
|
|
Macichne Leainig posted:The CEO and I just got off a call and it went great so gently caress all y'all haters. who hurt you?
|
|
#
?
Oct 23, 2023 23:43
|
|
|
VPs can probably be bullied right back if they are assholes and you are secure enough in your role. Anyone above that, no way.
|
|
#
?
Oct 24, 2023 00:25
|
|
|
thotsky posted:who hurt you? They work in development Who didn't hurt them
|
|
#
?
Oct 24, 2023 01:17
|
|
|
Weird move for a VP to run to HR. Most of the VPs I know, even the nice ones, would have zero problem confronting a subordinate for something.
|
|
#
?
Oct 24, 2023 01:57
|
|
|
Imagine siding with a VP on any level after somebody tells a story in this thread lmao
|
|
#
?
Oct 24, 2023 03:33
|
|
|
Xguard86 posted:Weird move for a VP to run to HR. Most of the VPs I know, even the nice ones, would have zero problem confronting a subordinate for something. Yeah it's hard to imagine getting to that level of management without being able to settle your own scores
|
|
#
?
Oct 24, 2023 06:05
|
|
|
|
| # ? May 9, 2024 21:56 |
|
|
This reads like 'Sub-60 person company' to me at least, dunno if I missed something outlining size. Lots of companies like that are run by just total weirdos.
|
|
#
?
Oct 24, 2023 07:37
|
|