I’m English, not American but I see it as Saturday and Sunday are the two ends of the week. Like how a string has two ends. The weekend is both the start and the finishing end of the week.
So, when someone asks if you are free the next two weekends, you assume they’re talking about the next Saturday (tail weekend) and the next Sunday (front weekend)?
I’m refering to end in a temporal sense because we are talking about a time context here. There is a clear direction so going backwards brings you to the begin.
I see, somehow completely forgot that apps might be different. In browser version in landscape (I just noticed) there’s also the right sidebar, which reserves some space. So it wouldn’t even have to go all the way.
I just calculated exact subpixel accuracy, for me it’s exactly 20.5̅9̅5̅5̅3̅3̅4̅9̅8̅7̅5̅9̅3̅0̅5̅2̅1̅0̅9̅1̅8̅1̅1̅4̅1̅4̅3̅9̅2̅0̅ % that is still missing to fill the whole comment body with rainbows, way to go!
I just unfolded everthing. Seems we are on the 8th rainbow. Almost looks like on my phone, while in potrait mode, 10 rainbows will likely have it filled up.
Oh wow, even if you put it in landscape? In either case, lemmy’s web interface hides a lot of context by default when answering via the “messages” notifcation. So in a sense, with that one could reply endlessly. Then again, that’s not part of our experiment I’d say.
Oh boy… can’t promise you that I will last that long. I know it sounds pathetic, but is replying to one’s own comment an option (just for stress testing)?
The worst case is when someone requires changes, you address them, but then they disappear/go on a leave.
If the repository rules require all conversations to be resolved before merging and only the original reviewer can mark them as solved, the PR is stuck forever even if the rest of the team approves it.
“Debugging. The game where you are the criminal, the victim, and the detective at the same time. But you probably don’t know where the crime took place, or what it was. But there definitely is a crime.”
I am a human who transcribes posts to improve accessibility on Lemmy. Transcriptions help people who use screen readers or other assistive technology to use the site. For more information, see here.
I would review it and immediately tell them to break it into bite sized PRs.
My coworker kept doing that. We had several talks about it. Other members of our team had talks about it with them, and even our manager. Finally, I marked the PR as needs work, told them to break it into several PRs. They weren’t happy, but I was tired of dealing with PRs that were 30+ files, unrelated in change, and over 1500 lines of code changes. They were pretty mad at me for a while. But it stopped shortly afterwards.
It shouldn’t take more than an hour to review a PR.
If this is a breaking change to a major upgrade path, like a major base UI lib change, then it might not be possible to be broken down into pieces without tripping or quadrupling the work (which likely took a few folks all month to achieve already).
I remember in a previous job migrating from Vue 1 to Vue 2. And upgrading to an entirely new UI library. It required partial code freezes, and we figured it had to be done in 1 big push. It was only 3 of us doing it while the rest of the team kept up on maintenance & feature work.
The PR was something like 38k loc, of actual UI code, excluding package/lock files. It took the team an entire dedicated week and a half to review, piece by piece. We chewet through hundreds of comments during that time. It worked out really well, everyone was happy, the timelines where even met early.
The same thing happened when migrating an asp.net .Net Framework 4.x codebase to .Net Core 3.1. we figured that bundling in major refactors during the process to get the biggest bang for our buck was the best move. It was some light like 18k loc. Which also worked out similarly well in the end .
Things like this happen, not that infrequently depending on the org, and they work out just fine as long as you have a competent and well organized team who can maintain a course for more than a few weeks.
The follow on. Lots and LOTS of unrelated changes can be a symptom of an immature codebase/product, simply a new endeavor.
If it’s a greenfield project, in order to move fast you don’t want to gold plate or over predictive future. This often means you run into misc design blockers constantly. Which often necessitate refactors & improvements along the way. Depending on the team this can be broken out into the refactor, then the feature, and reviewed back-to-back. This does have it’s downsides though, as the scope of the design may become obfuscated and may lead to ineffective code review.
Ofc mature codebases don’t often suffer from the same issues, and most of the foundational problems are solved. And patterns have been well established.
That’s seems awfully short no? We’re talking a couple hours of good flow state, that may not even be a full feature at that point 🤔
We have folks who can push out 600-1k loc covering multiple features/PRs in a day if they’re having a great day and are working somewhere they are proficient.
Never mind important refactors that might touch a thousand or a few thousand lines that might be pushed out on a daily basis, and need relatively fast turnarounds.
Essentially half of the job of writing code is also reviewing code, it really should be thought of that way.
(No, loc is not a unit of performance measurement, but it can correlate)
To be honest, I agree they should be able to be larger at times.
I had a lot of disagreements when I was on a new codebase, knew what I was doing and I was able to push a lot of code out each day.
The idea is to have them small, easily readable with a tight feedback loop. I argued that bootstrapping a project will have a lot of new code at once to lay the foundations and my communication with the team was enough feedback. If I split it up, each PR would have been an incomplete idea and would have garnered a bunch of unnecessary questions.
That said, I think it’s generally pretty easy to put out multiple PRs in a day, keeping them small and specific. As you say, half of the job is reading code and it’s nicer to give my coworkers a set of PRs broken down into bite sized pieces.
I read that recently as well, it is a great read. I can relate to a lot of the things. While it is meant as a humor piece, there is some solid advice in there.
I didn’t exactly have it in mind when I wrote my comment, but maybe subconsciously 😅
programmer_humor
Hot
This magazine is from a federated server and may be incomplete. Browse more on the original instance.