Hacker News Reader

Comment by alerighi | Hacker News Reader

This is a very stupid thing to do. First, code is not the issue. Code can be rewritten in not a lot of time, when you have clear what to write. Twitter is not something so complex, in principle, thus it shouldn't be that difficult (a team of 10 good programmers in a month can probably rewrite everything).

The thing where is 99% of the complexity and you can't redesign in a month is the infrastructure, how data is stored, how the various components communicate together, how everything scales globally, and all the related components. Things like Twitter are not complex for the application (that is trivial to implement) but for what it takes to run that trivial applications with that kind of numbers.

Looking only at the code is stupid, since code is fairly trivial to rewrite, while doing infrastructure changes is something difficult, costly and in some cases even impossible.

View on HN

> a team of 10 good programmers in a month can probably rewrite everything

unless you scope-down "everything" to the point of triviality, that is ludicrously underestimating the intrinsic complexity of twitter's product surface, and all the plumbing and necessary tools that lie beneath

given how many people twitter employs and how many features actually get shipped at twitter, I'd say scope-down isn't that terrible of an idea

Probably not as hard as it seems, Amazon does this regularly with the concept of 2 pizza team. The real challenge is figuring out what is the 20% of Twitter that drives 80% of revenue. Probably basic Twitter posting and ads, and whatever fraud/bot prevention is needed to keep running smoothly.

why would you throw away 20% of your revenue? Obviously a lot of functionality is there to chase marginal percentages of revenue, but it's still worthwhile at Twitter scale.

Because twitter is a money losing business. The cost of that 20% revenue is too high and hurts the profit margin.

Amazon has more than 50 employees.

Here’s just what Twitter has open-sourced: https://github.com/orgs/twitter/repositories

Laughable that you think 10 people can rewrite all of this in a month. It would take longer to scope out the design docs alone.

Its not stupid because he knows and trusts his engineers at Tesla. He knows nobody at Twitter. Hes probably trying to get an understanding of whats going on without relying on a bunch of employees who might not like him. It takes a while to build an employee base you trust, certainly in his situation.

I believe you’re missing the point. Random code reviews performed by people in a whole different sector aren’t the best way to find out “what’s going on”.

In my career I did a few rescue operations when I as external expert was asked to come in and understand why project was failing. Random code review is amazing tool to understand quality of engineering talent and process maturity.

My process was to schedule 2h block and then start with pulling random diff. I checked if engineer can explain diff purpose from both technical and business perspective. Then dive in and assess understanding of code base by asking about random functions/lines. Follow up if I do not understand something. Why was it done this way? Did you consider other options? What are pro cons? How long did it take you to write this? Who reviews it? Any approvals were needed? What was process to ship it?

You will be surprised how often sr/principal engineers are clueless and dev process is full clusterfuck when people copy/paste without understanding what they are doing.

You very quickly understand what’s going on. You do not need to talk to every engineer - random representative sample is good enough. You do not need to have domain understanding too - though it’s obviously very helpful.

Those who think this is a code review for the sake of looking for bugs or architecture issues are missing the point.

It's an intimidation factor on Musk's part. Are you willing to play along and show your work? Or are you going to huff and puff and complain about it? Maybe you're hiding something, or maybe you're not going to be a cooperative resource going forward. Now you're on the cut list.

Maybe the code will get glanced at for a moment. Most of us can tell well written code from spaghetti without running it through a compiler. But still, that's not the prime objective here.

We don't know who they people he brought over are. It's doubtful that they are people who've never done anything but write code for Tesla. Were I in Elon's shoes, I could easily imagine digging up some employees with prior relevant experience and asking them to just browse through the codebase and give a rough appraisal of how tight it is. You can tell a lot by looking at basic things like coding standards, state of source control, development environment, testing strategies, what kind of code reviews are happening, how modular the code base is, what the service architecture looks like, etc. I've worked in a number of industries and good code and tight systems look different from bad code and sloppy systems. He's probably not looking for anything specific, but rather to get some understanding of the state of engineering there.

They don't really need to find out anything meaningful. They are basically just putting Twitter employees on notice that they may be going deep into the details when assessing where the company is at and what changes they might want to make.

It may not be the best way, but I could certainly see it having some value.

Twitter has a ton of home grown tooling that a company it size wouldn't have if it was started today.

Is the team of people maintaining their custom stream processing engine really going to say "You could probably just replace this whole team by using Flink"? Repeat for their custom NoSql DB, their batch processing engine, their RPC framework etc.

I never said it was the best way, but it may be the most viable option. And you dont have Tesla engineers personally go through the code, you have them sit down with twitter engineers and have them walk through how it works. Its probably a general understanding exercise.

It's the job of an incoming CEO to (1) gather information from the existing staff, (2) build relationships (and trust) with them, (3) use that information to help inform/tailor strategy, and (4) identify key individuals that can help execute said strategy.

If he needed an outside consult to confirm or refute suspected problems, that's ok, but that's not what happened here. He started off this relationship adversarially, and first impressions matter. This one is going to take some effort to repair. And if it isn't actively repaired, it's going to be a bumpy ride before he starts seeing good progress on his vision.

Just the iOS app is 2.5 million lines[1]. Good luck writing tenth of that from scratch in a month.

[1] https://twitter.com/bhcarpenter/status/1585834343766773761

I agree, I made my own google docs implementation using a `<textarea>` and it was super easy.

> (a team of 10 good programmers in a month can probably rewrite everything).

Is this satire?

Reply on news.ycombinator.com