> You need to write a book and/or explain how you can review 500kloc in 8 hours. That sounds ridiculous to me but I may be missing something

I feel like what you could do in 8 hours would be less "reviewing" and more "starting to get a basic sense of the codebase in the way a new hire would" but when you're the new CEO of the company maybe saying that doesn't sound cool enough?

In 8 hours I would be surprised if you got more than a 10000 feet view. Also, there is deployment, ops, policy.

To say you got everything you needed in 8 hours is disrespectful at best (even for way smaller code bases)

What you're missing is that dilligence is NOT coming in as the new Super Senior Distinguished Principal Architect who's going to rebuild the whole system overnight.

If I'm doing dilligence, I'm looking to see if there IS ops, deployment, etc. I'm checking the coverage of the IAC compared to the infra (can spot check in console and ioc). You can ask for an overview of metrics code and how thye monitor their infra (walk through a dashboard). Diligence is NOT being able to re-write the codebase, or even work in it. It's to make sure that what people are saying is happening, is there, is with high confidence, actually there. You're also looking for "oh shit". Such as no IAC, no tests, no monitoring.

That's shifting the goalposts quite a bit. You're looking for process, you are also asking for pointers from the people working on the project. Throwing out numbers like 500kloc is completely unnecessary as you're not going to look at them unless in cases where you're spotchecking (and you won't know where to look without someone pointing it out to you)

I don't feel I'm moving the goal posts. I'm relating what I did with numbers. Others may have assumed my goals.

My goal was to reduce the risks that the acquiring company felt were the biggest. I did that in 8 hours. Then we focused on specific risks previously identified in the review. That usually took the form of asking the selling company to explain, not for me to read more code. Usually the answers clarify the concerns, or admit them.

That's not really code review though, I'd argue. The report was that they wanted their code printed on paper, and to review it. That seems very... specific to the code itself. Not the same as reviewing code coverage, documentation and Ops specific workflows.

Of course, those things are absolutely vital, and must be long and tedious work, and I give you kudos for having these skills :-)

That's fair as far as kicking the tires on the truth value of management's claims, but what Elon's doing here is performance management. Deciding someone's work is bad and they should be fired, does imply that you know how the work ought to have been done instead.

Due diligence happens before not after the deal closes. This is not due diligence, it's a clown show

Does it tho? If you're cutting 70% of 1000-2000 coders is that what you're doing, fully understanding twitter, or are you just looking for dead weight or unimportant systems and axing those immediately?

This is IMHO a very naive take on software engineering and on keeping a complex system running.

There is no way we're going to see a 70% cut and twitter survives. There is also no way an outside party cam figure out what the "unimportant" systems are in days or even weeks.

Realistically if you want to cut you start by reviewing everything and pretend you just want to understand. You place key people in key positions and help them build an understanding. After 3-6 months of observing maybe you can do some cutting.

Oh I 100% agree with everything you said here. You do due diligence before. You don't just blindly cut 70%.

I was just saying if I had to (because I was being asked to) cut 70% or even 10% immediately that's what I would do. But I'm also not sure I'd take that job.

I'm just enjoying the popcorn cause no one seems to know what's going on.

This is an average rate. There are large parts of the code base that are configurations, mappings, or just glue code. Even if you're not familliar with the language you get a sense for it quickly, you can power through those at 10kloc or higher when you hit a run, you can also rule out directories quickly after you see an example. You can also ask the people you're reviewing "is this directory just all kube config? where's the security settings?". and go at a high rate for reviewing the code.

When you get to interesting code you then slow way down, maybe 10loc / minute.

Remember, for diligence, you're doing risk reduction, your job specifically is determine that there is in fact secret sauce, the product is there, not to understand it. In fact it's problematic if you 100% understand that secret sauce.

Yeah no. I still don't see it. You claim "I could review the 200-500kloc codebases".

I've worked on due diligence from both sides of the table in the past and this is not how it works.