Goodbye, and Thanks for All the Bikesheds

Phone wiretaps, conversation wire taps and access to letters have been normal since those communication technologies existed.

So what the heck are you on about? Content of conversations, letters and phone calls was critical to many investigations - including famous ones like WaterGate and bringing down Al Capone.

Again, if you decide to attack the government's ability to do their work, expect a pushback. This isn't hard.

I'd like to know where you're getting these decisions. All of my hard decisions are due to not knowing what technical obstacles we'll run into later.

That is often a different type of difficulties. I was thinking about decision like, should I buy car A or car B. I've done my research. Economy, safety, et c. are very similar. But it is a lot of money, and I don't know which is the "best", and of course I want the "best". I could spend weeks on a decision like this. Now I just acknowledge that they seem to be equal. Car B comes in a nice shade of red that I really like, so I buy car B.

Regarding your question, there's always going to be known and unknown unknowns down the line. My only advice in that case is to get to the unknowns as fast as possible. And from the start take into account that you most likely will have to rebuild a big part when you learn more. That is one of the reasons modularity and decoupling is so important. You want to be able to easily scrap and replace one part without it affecting everything. And keep it simple. Never try to build something that should be capable to handle all imaginable scenarios in the future. You'll be bitten by one of the unimaginable ones, and your complex "can handle everything" architecture will be too rigid to change.

To comment on my concrete (and quite miserable) situation, here's how it went (and does, even worse with the advent of AI, to this day):

* A report comes from the field (to the support team) that something is broken (or highly desired by the customer).

* The support team assigns the ticket to the lead engineer.

* The lead engineer writes the code and after a quick battle with CI pushes it all the way to the customer in need.

* Since it's the lead engineer, he has the authority to merge PRs w/o consulting anyone, which is what he does. You just pull the changes and marvel at them, or at the sunrise, whichever you like best. The "urgency" is used as a justification to skip the due process.

Now, when AI came into play, two horrible things were added into the mix:

* AI audit and code review. The audit is a 50/50 chance between finding a real problem vs misunderstanding of the purpose of the code or the context in which it is executed. The AI will also come up with a solution that is either completely wrong, unnecessary or touching too many things for a human to track. Code review acts in a similar way, except, technically it fills the role of a human reviewing the code, so it gives a sense of false security to anyone making changes.

* AI generating code that is hard for humans to follow. First and most obvious problem is the volume. In minutes AI generates changes that will take months of effort to review. But this is only the beginning of the problem. When reading code written by humans, another human builds a model of the author's approach, ability, intention and permissions. When it comes to AI, these... let's call them "dimensions" are all over the place. The generated code you read may seem very plausible for a while until you stumble into a crucial functionality that completely invalidates everything you've learned about the change so far. The change may make unnecessary segues into the territory it was never meant to touch.

So, even when there are code reviews, they now miss a lot more than they used to when only humans were writing code.

Also, and this is a pathologically bad, but a very common practice: the reviewer's name is missing from the record. You run git-blame and only see the author, not the reviewer. When things go down, the author takes the heat and the reviewer is nowhere to be found. Subsequently, reviewers don't feel like they need to care as much about the outcomes.

Oh, and one more thing. To be effective at reviewing anything you'd want to try things... as in to test them. Perhaps come up with some idea about what things must happen and what things absolutely must not. But where do you find those? Usually... in a design document, s.a. a PRD, but in the case where that design (allegedly) was solely in the head of the person writing the code, how do you even know if the behavior you conjecture the code has (because there are no tests) is the desired one?

Everyone has to learn how much feedback they can give in a code review without making an ass of themselves. The code isn’t right at the end of that, it’s just less wrong.

On the first project I had with routine code reviews I learned to wait for one or two others to file their reviews and then I would catch everything they missed.

It was an app with too many interactive components on top few pages so perf issues and footguns were both a priority. That generates a lot more comments on CRS. There were two of us doing all of that work and the other had English as a second language so he tended to point out one or two issues and let the rest slide.