Tesla engineers were on-site to evaluate the Twitter staff’s code, workers said • Hacker News Board

Re: Tesla engineers were on-site to evaluate the Twitter staff’s code, workers said

#481

Post by ratsmack » Sun, Oct 30, 2022, 2:19 AM UTC

bagels wrote: post #464

ratsmack wrote: post #458

Earlier quoted context omitted.

Every company I was with when it sold had lawyers come in and inform everyone that all processes are frozen, no equipment can move or be transferred while inventory is taken, everyone involved with computers surrender their passwords to their incoming engineers... etc, etc, etc. It is standard practice and there is nothing nefarious about it.

Tesla didn't buy Twitter, as far as we know though. Seems grossly inappropriate.

I can see where people that get a sense of entitlement, for whatever reason, would have a problem with it.

Re: Tesla engineers were on-site to evaluate the Twitter staff’s code, workers said

#482

Post by rtkwe » Sun, Oct 30, 2022, 2:20 AM UTC

ratsmack wrote: post #471

2OEH8eoCRo0 wrote: post #75

Earlier quoted context omitted.

You'd arguably have a case that Musk is not acting in the interest of Tesla and is using his Tesla position to enrich himself rather than the Tesla company. Exactly what the "CEO is supposed to serve shareholders" is all about.

Do you believe that Musk is not going to push his cars on Twitter? Seems to me that you have access to a fairly large audience on there.

Just being tangentially related to the company isn't enough to justify it imo. You could also buy a lot of twitter ads for the cost of having devs come over.

Re: Tesla engineers were on-site to evaluate the Twitter staff’s code, workers said

#483

Post by mancerayder » Sun, Oct 30, 2022, 2:20 AM UTC

Will the new bots be fully self-driving?

Re: Tesla engineers were on-site to evaluate the Twitter staff’s code, workers said

#484

Post by Kamq » Sun, Oct 30, 2022, 2:21 AM UTC

kibwen wrote: post #455

longrod wrote: post #448

I think people are looking at this the wrong way. It's not so much about the code as it is about establishing an authority. Musk takeover is often regarded as banditry and I wouldn't be surprised if the employees didn't take him seriously in the beginning. This is his way of saying, "I don't trust you, I don't know what you have been up to but things are going to be different so better get used to it." Using Tesla en…

Only incompetent managers (and executives) think that "authority" is interchangeable with "respect". Fortunately for Musk, incompetence rarely disqualifies billionaires from anything.

There's no way Elon would have any respect yet, there hasn't been nearly enough time (respect is earned).

There are going to be power games for a couple of months, until the new management identifies a subset of the old staff that they can trust (or, more cynically, exploit), and then that subset will be elevated above the rest. The losers will either back down, quit, or be fired.

Source: Seen a couple management changes before.

Re: Tesla engineers were on-site to evaluate the Twitter staff’s code, workers said

#485

Post by ManWith2Plans » Sun, Oct 30, 2022, 2:22 AM UTC

ipqk wrote: post #65

I'd be pissed off if I were a TSLA stock owner. Is Twitter paying Tesla to contract out these employees for their work? Otherwise, it's tons of thousands of dollars Tesla is pissing away on behalf of the CEO's side-hustle.

It's perfectly plausible to believe that Elon Musk paid them to take vacation days off for this purpose. I wouldn't jump to any conclusions.

Re: Tesla engineers were on-site to evaluate the Twitter staff’s code, workers said

#486

Post by alchemist1e9 » Sun, Oct 30, 2022, 2:22 AM UTC

fzeroracer wrote: post #434

alchemist1e9 wrote: post #253

Earlier quoted context omitted.

What’s more funny is how people commonly believe like this their code is so special or different than everyone else’s. Reverse engineering a large code base is not anywhere as hard as most software engineers somehow believe. I was tasked with analyzing a large code base from a company that my employer had been an investor in and as part of their investment had been given IP rights, the company employees were floored…

And how long exactly did that take? I'm going to cast doubt on your story because in my experience people that often claim to understand how a codebase works in a quick amount of time tend to be full of it and end up blowing things up when they try to change or modify things. The codebase often isn't the issue, it's the use cases and the reasons why it evolved into the form it did.

I guess large is a relative question. For me ~600K lines of C++ is a pretty large code base. Apparently Facebook Messenger just on Android is 10M lines of Kotlin in another comment. To me that seems like they are probably doing something wrong.

But to address your question here is my recollection of what happened, now more than 20 years ago fwiw. We were given the code and I spent maybe 6-7 days, all day, reading it and analyzing it with this tool I had, called Source Navigator [1]. Then we spent 1 full work week at the other companies HQ, mostly in meetings asking questions on different modules and classes. Then when we returned to our offices it took me another 2 weeks of work to get the system setup and deploy a few components inside our own middleware system. I was the primary c++ expert, there was another business analyst and I had a more junior developer who worked with me. So in comparison to Twitter certainly a much much smaller scale situation. The team that had written the system was around 15 people.

We definitely used the code and I don’t recall it being much a problem at all that other people had written it. Plenty of open source projects have random contributors show up and work fine in their code base.

I think a lot of SWEs have pretty big egos and tend to overestimate how special or unique their particular projects are based on my own professional experience. This particular situation was an example but there have been plenty others. When I fix or find bugs in other’s code sometimes they are surprised which for me is always surprising. Why are you so surprised I can debug your code?

[1] https://sourcenav.sourceforge.net/

(I’d be curious if people have a favorite more modern version of a tool like Source Navigator)

Re: Tesla engineers were on-site to evaluate the Twitter staff’s code, workers said

#487

Post by bagacrap » Sun, Oct 30, 2022, 2:23 AM UTC

alchemist1e9 wrote: post #253

lohii wrote: post #154

If someone completely new to my codebase came along and tried to evaluate my code I'd laugh. You can't jump in and "evaluate" without knowing context and being familiar with the features.

What’s more funny is how people commonly believe like this their code is so special or different than everyone else’s. Reverse engineering a large code base is not anywhere as hard as most software engineers somehow believe. I was tasked with analyzing a large code base from a company that my employer had been an investor in and as part of their investment had been given IP rights, the company employees were floored…

I would say it's pretty "special" and well written code if outsiders can come in and quickly understand it. You should have commended them for their work.

Re: Tesla engineers were on-site to evaluate the Twitter staff’s code, workers said

#488

Post by bpodgursky » Sun, Oct 30, 2022, 2:23 AM UTC

tasty_freeze wrote: post #203

I don't at all object to code reviews/evaluation, but the thing I wonder about is this: I rarely open an empty file and write some big block of code. 98% of the time I'm fixing bugs in legacy code or shimming in some new feature. It would be trivial to produce the diffs I generated in the past 30 or 60 days, but the volume of code isn't really a great metric for my productivity. There may be some three line change th…

I think this is true and an big problem when artificially separating the top 10% from the top 20%, or top 1% from top 5%...

... but in practice, I think you will find 0 overlap in raw lines of code produced between the top 10% developers and the bottom 10% developers. Especially at a notoriously unproductive organization like Twitter, the bottom tier simply does nothing.

If Musk is trying to cut 60% of the org, he's going to have a problem doing it this way. If he's trying to cut 20%, I honestly don't think it's going to misfire much of the time.

Re: Tesla engineers were on-site to evaluate the Twitter staff’s code, workers said

#489

Post by alchemist1e9 » Sun, Oct 30, 2022, 2:25 AM UTC

dorkwood wrote: post #310

alchemist1e9 wrote: post #253

Earlier quoted context omitted.

What’s more funny is how people commonly believe like this their code is so special or different than everyone else’s. Reverse engineering a large code base is not anywhere as hard as most software engineers somehow believe. I was tasked with analyzing a large code base from a company that my employer had been an investor in and as part of their investment had been given IP rights, the company employees were floored…

> Trust me if one is experienced enough they can understand your code perfectly fine, it’s definitely not as special as you think it is. What if a large portion of the codebase is, for example, shader code? I chose this example because coding for the GPU isn't the same as coding for the CPU. Do you think that's a scenario in which you'd require more study, or are you confident your experience would spill over into th…

This I agree with. I was very familiar with the business domain and the technology they had been using. So yes I agree if either of those were radically different it would be much harder. Good point.

Re: Tesla engineers were on-site to evaluate the Twitter staff’s code, workers said

#490

Post by xnyan » Sun, Oct 30, 2022, 2:26 AM UTC

throwaway09223 wrote: post #90

aaronharnly wrote: post #18

Earlier quoted context omitted.

Respectfully, very little of this seems to be operating by standard procedure. Have you seen the incoming CEO ask people to bring printouts of their code, ever?

Musk is reportedly looking to cut deadweight before Nov 1st when equity vests -- with layoffs possibly happening over the weekend. He might already have a basic idea of key teams and for non-key teams he might be looking to cut very fast. I absolutely have done things like this when acquiring companies - sat with people, asked them to basically interview for their own jobs while showing me the most important thing th…

>I can see why it might make sense to just tell people to print stuff out to demonstrate competency

Review of work based on your last 30 days of code that’s printed out on 8.5x11s is nonsensical. I’ve never heard of anything like it in my software development career and can’t think of any reason one would do it except to encourage people to quit.