beder

Yes, this is absolutely right (for some sufficiently complicated prompt). Borges wrote a great short story that explores this idea, "Pierre Menard, Author of the Quixote", where Menard, a fictional 20th century author, "wrote" Don Quixote as an original work.

This is how I read it too. What's more, it looks like they're interested in going senior -> staff; at all Large Tech Companies, senior is a perfectly reasonable "terminal" role for a SWE, and many SWEs don't want to get promoted to staff. (Staff SWE is a different job from senior SWE; you might not want want to do that job, and that's typically fine.)

So I think the lesson here is wrong too - when the manager said

> These tasks aren’t business priorities and had no impact on customers and other teams

that didn't mean they were worthless tasks - just that they weren't business priorities and had no impact on customers or other teams. Which is probably true(ish - I would have phrased it very differently if I were their manager).

Improving the release process is great, and helps the team a ton - and indirectly helps customers by enabling the team to ship faster. This is incredibly valuable! And at the right scale, it can be a staff job: at my Large Tech Company, I know several people that have been promoted to staff SWE for this kind of work, but it's for systems that hundreds of SWEs work on. I also know people that have been promoted to senior SWE for this kind of work - these are systems that tens of SWEs work on. It sounds like this example was more like that - this person was doing a good senior SWE job, and the manager didn't see any reason to course correct given that they had given no signal they wanted to get promoted.

I agree, and even moreso, it's easy to see the (low!) cost of throwing away an implementation. I've had the AI coder produce something that works and technically meets the spec, but I don't like it for some reason and it's not really workable for me to massage it into a better style.

So I look up at the token usage, see that it cost 47 cents, and just `git reset --hard`, and try again with an improved prompt. If I had hand-written that code, it would have been much harder to do.

At one point at Google, there was a huge chunk of code that was hard to understand, probably at the wrong place in the network stack, and stubbornly hard to change. And it kept growing, despite our efforts. We renamed it "[Foo]Sorcery" (this was about 10 years ago); people stopped trying to add to it, and periodically someone would come in and remove parts of it, all thanks (I think) to the goofy (and somewhat scary) name.

How so?

This reminds me of the fantastic book, A Canticle for Leibowitz, by Walter Miller. He has a similarly pessimistic take.

Here’s an example for chess: I found that I was repeating the same lines and the same ideas over and over during matches. One of the key points in the book is to simply observe what you’re doing without judgment. I realized that I’d fixate (especially under time pressure) on an idea that didn’t work.

I tried working on this with deliberate practice on cycling through different areas of the board. There’s a mental feeling (not too different from the physical feeling of swinging a racket) of working through a line, and then moving to another area and trying a different line.

The author mentions “The Inner Game of Tennis” as an example of how to train in images and feelings, not words, and I highly recommend it to basically anyone, not just tennis players.

If you’re doing anything that you might hear “don’t overthink it”, then it’s for you. It was recommended to me by a friend who played competitive Foosball; I read it as an instructional about playing chess; and later, after starting to play tennis, I read it again, and I think it’s equally applicable to all of those.

I was on board for points 1 and 2, but completely disagree with 3:

> The components might look wrong when rendered. Tests are very bad at this. We don't want to go down the esoteric and labor-intensive path of automated image capture and image diffing.

This is the main reason we have tests for our (Angular) typescript all; all the tests roughly look like:

1. set up component with fake data

2. take screenshot and compare with golden

3. (maybe) interact with component and verify change

These are super easy to write, and also easy to review: most review comments are on the screenshots anyways. And since the goldens are checked in, it’s easy to see what different parts of the app look like without starting it up.

FWIW, I turned this option (to not quit on Cmd+Q) a long time before it was the default, and it's saved me time so many times - I absolutely love it. Before, I would constantly try to hit "Cmd+W" and accidentally tap the Q, and the whole browser would close.