3 ms·

This thing with small PRs bothers me somehow. Where does design happen? Do we just make endless tactical changes? For juniors this is even worse, they get to

by pipes 2y ago

This thing with small PRs bothers me somehow. Where does design happen? Do we just make endless tactical changes? For juniors this is even worse, they get to wait until PR time to validate their design. With trunk based development this means continually commiting unreachable code with back and forth with more senior staff via PRs, instead of sitting down for an in depth discussion where they'd actually learn how to do this job. This isn't really aimed at the parent poster, just an observation. I've been working since 2006, GitHub brought in PRs and I think we lost something over night: code reviews where you get to sit with more senior staff and discuss your code.

Sakos 2y ago
At my first job a few years back I sat down with a senior dev at least once a week (informal meeting) to discuss my tasks and the code bases we were responsible for in general. It was incredibly helpful. I could also request feedback at any time. At the end of it, the final PR might be large, but it had mostly been discussed and reviewed by then, so doing a final review was more of a formality, dotting the i's and crossing the t's to ensure the criteria had been properly fulfilled. I thought it was a great process.
- pipes 2y ago
  I think I'm going to suggest that if I'm assigned as a mentor for junior staff again. Thanks for sharing it. :)
fishtoaster 2y ago
I've been working through PRs since around 2011 and I don't think I've ever seen a place where PRs were intentionally used to handle design issues. Occasionally design problems will get brought up in PR, but that's always been considered a failure of earlier planning when it happens. Depending on the company, the design discussion you're talking about has happened: 1. In verbal discussions with other devs before fingers ever touch keyboards 2. In long-form writing (Text docs, then Google docs, then later Notion) 3. In per-project slack channels 4. Out loud, on a whiteboard. Right now it's very much #4 because my company is 2 devs and a founder. But even here, I wouldn't expect to get anything non-trivial into pull request before figuring out the overall structure with the other dev verbally or in writing.
- pipes 2y ago
  For non trivial work do you expect it to be delivered via small incremental changes? Genuine question. Not trying to but pick or win an argument.
  - fishtoaster 2y ago
    When possible, yeah. I imagine some sort of golden rule: "make PRs for others to review that you would like to review yourself." There's plenty of room for exceptions there - my coworker is currently reviewing a 1300-line PR after my apologies for it :) But yes, we generally break things down into the smallest meaningful chunk possible to deliver. If that chunk is too small to understand the larger work that it's part of (as is usually the case for non-trivial work), we can discuss the larger work in another forum (ad-hoc verbally, via design doc, via meeting, etc).

by pipes 2y ago

Sakos 2y ago

At my first job a few years back I sat down with a senior dev at least once a week (informal meeting) to discuss my tasks and the code bases we were responsible for in general. It was incredibly helpful. I could also request feedback at any time. At the end of it, the final PR might be large, but it had mostly been discussed and reviewed by then, so doing a final review was more of a formality, dotting the i's and crossing the t's to ensure the criteria had been properly fulfilled. I thought it was a great process.

pipes 2y ago
I think I'm going to suggest that if I'm assigned as a mentor for junior staff again. Thanks for sharing it. :)

fishtoaster 2y ago

I've been working through PRs since around 2011 and I don't think I've ever seen a place where PRs were intentionally used to handle design issues. Occasionally design problems will get brought up in PR, but that's always been considered a failure of earlier planning when it happens. Depending on the company, the design discussion you're talking about has happened: 1. In verbal discussions with other devs before fingers ever touch keyboards 2. In long-form writing (Text docs, then Google docs, then later Notion) 3. In per-project slack channels 4. Out loud, on a whiteboard. Right now it's very much #4 because my company is 2 devs and a founder. But even here, I wouldn't expect to get anything non-trivial into pull request before figuring out the overall structure with the other dev verbally or in writing.

pipes 2y ago
For non trivial work do you expect it to be delivered via small incremental changes? Genuine question. Not trying to but pick or win an argument.
- fishtoaster 2y ago
  When possible, yeah. I imagine some sort of golden rule: "make PRs for others to review that you would like to review yourself." There's plenty of room for exceptions there - my coworker is currently reviewing a 1300-line PR after my apologies for it :) But yes, we generally break things down into the smallest meaningful chunk possible to deliver. If that chunk is too small to understand the larger work that it's part of (as is usually the case for non-trivial work), we can discuss the larger work in another forum (ad-hoc verbally, via design doc, via meeting, etc).