plumefar

I had access to a repo (from a closed startup) with 800K lines of python & C code, written from the 90s to today. They had some very interesting approach to a specific chemistry problem. 20-30 years of work of several persons.

But God, I could not understand the code, and I could not easily make it work with modern technologies (GPU etc).

So I used Claude and Gemini to reverse engineer the codebase, extract the core ideas, and rewrite it from scratch with modern frameworks (with guidance from the original authors)

It took me only 10 days to have a functioning equivalent, in 10K lines of code (using many libraries that did not exist in the 90s and 00s), which I find much easier to understand, even though I wrote none of it myself.

10 days to rewrite 20-30 year of a few persons. That was quite scary.

I’m not a pilot. Zero experience except remote controlled airplanes.

But IIRC, it happened by night, over the ocean. If the instruments fail you, this is really hard to “perceive” your speed and orientation.

I had the same reaction.

I’m half the person I used to used to be, after a painful burnout. And it’s not even close as painful as what the OP experienced.

So many of my friends went through some very hard time that I stopped counting.

So yes, is this everybody?

There are times when life gives us the opportunity to be that guy; just not exactly in the same way. Pay attention, it has and it will happen.

In my +- 25 years of experience, I've encountered exactly 1 compiler bug. That cost me a full week of debug. Unfortunately, it happened during my very first year as a developer, and that triggered sub-optimal debugging practices (ie: is that the compiler fault again?)

At the end of the day, you want to optimise for debug time. There's the probability that it's a compiler/developer bug (respectively very low/very high) and the time it takes to rule it out. It's of course best NOT to start by investigating the compiler bug.

There seem to be 2 points of view here. One technical (sensors and the algorithms), one organisational (people and teams working on the problem).

My understanding is that by focusing on fewer things (vision only), they bet to make progress faster because of the simplified organisational aspect.

When facing such large scale issues, communicating properly is very hard: Several teams might be investigating several possible root causes in parallel, and you might change your mind over time as to what is the most probable root cause.

So you might end up communicating something ("we think it comes from X, we're fixing it that way"), just to find yourself changing you mind a few minutes later.

Changing your message is usually not well perceived, even though that's actually normal during an investigation.

I would not like to be in charge of the communication. Finding the balance between saying too much or too little is tricky.

Maybe the right question is: how do you become a great boss?

Getting promoted to an EM position is one thing. Getting good at it is... very hard, and requires new skills. There's very little in your day to day job as an engineer that prepares you to become a good EM.

One can both be a bad EM and become a good one.

The key questions are:

- Does the person have a growth mindset?

- Is the environment helping the new EM grow?