vraylle

He mentions (in the comments of the video) the catch-22 of needing the thatch to last long enough to make enough bricks to make a brick and tile workshop that doesn't need thatch.

Guess you haven't met my neighbors.

I'm still running 16GB. I built my PC in 2015 and it's been my gaming/work/dev machine ever since. Have only upgraded GPU and storage.

It is definitely showing its age, but I don't need to worry about the Windows requirements. My CPU isn't supported for Windows 11 so I'm sticking with what I've got until Windows 10 hits EoL. Then I'll probably buy a 64GB AMD system and switch to Mint at that point.

Bingo! Rural in particular is slow and unreliable. Something like this isn't a practical option even if I was OK with it. I'm already planning to switch to Linux when I get a new PC or when Windows 10 hits EoL. This would make the switch a necessity.

At least with my subscriptions I've been noticing an increase in sponsored segments. And you know what? I don't mind. It's much less jarring when the "host" is also doing the ad and pretty much just works it into the video. People have to make money, and this old-school approach works for me. Reminds me of ads in old TV/radio shows. And it doesn't suddenly change the scene and quadruple the volume along with seizure-inducing backgrounds.

We use a version of Git Flow for branching (since everyone is talking about branching strategies here). But technically, you asked specifically about code review process. Every ticket is it's own branch against the development branch, and when complete is merged by PR into the development branch. We're a small team, so our current process is:

1. Merges to the development branch require one approval
2. Merges to the main branch for a release require two approvals
3. If the changes are only code, any developer can review and approve
4. If there are "significant" SQL changes a DBA approval is required.
   • "significant" means a new entity in the DB, or...
   • an inline/Dapper query with a join

As we grow we'll probably have to silo more and require specific people's approval for specific areas.

A lot of what we do is "cultural", like encouraging readability, avoiding hard-coded values, and fixing issues near the altered code even when not related to the original ticket. The key is to be constructive. The goal is better code, not competition. So far we have the right people for that to work.