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.
A very pedantic point, but merge keys are not part of the YAML spec [1]! Merge keys are a custom type [2], which may optionally be applied during the construction phase of loading. I definitely wouldn't say that merge keys are integral to anchors.
(Also, as a personal bias, merge keys are really bad because they are ambiguous, and I haven't implemented them in my C++ yaml library (yaml-cpp) because of that.)
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.
Agreed, Dennett hit all of the high points of the who-am-I philosophy in a really entertaining story. It also reminded me of a great Greg Egan story, Learning To Be Me:
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.
She was claiming something more fundamental (and less sophisticated) than that. Nigel Boston and Andrew Granville wrote a review [1] of her book that distills some of the problems with her argument. A sample quote:
> In fact, her central theme is that non-Euclidean geometry, and indeed any mathematics related to non-Euclidean geometry, is nonsense.
This reminds me of a time there was some unusual lottery result in my area, like 123456, and a TV station asked my father, a statistics professor, to comment that the odds of that happening were 1 in a million.
(Disclosure: I work on Dagger in my 20% at Google.)
What's more, Dagger gives you (compile-time) insights into the graph of dependencies.
For example, we've hooked up our internal code-search tool to give you Dagger cross-references, so if you (e.g.) click on a parameter to an @Inject constructor, you'll see the place that provides that object.
Also, if you click on the @Component, you'll see a visualization of the entire graph.
We're working on surfacing these hooks in the open source repo, which would allow IDEs like Eclipse to gain this functionality as well.
I'm not currently, but I was doing that for the last couple years with no ill consequences. I'm only not doing that now because I don't have a 20% idea that's particularly exciting to me.
I understand this confusion, but it totally isn't how research is done. It's very much a community and social effort; it can be very lonely working all by yourself on something.
This is an incredibly interesting area of mathematics, and it's disappointing that it's dying out. When I was an undergrad, I wanted to go into this field, but I was dissuaded by my advisor because of the direction it was going (fewer active researchers means fewer PhD positions, and ultimately, fewer academic jobs).
I'm glad that there's an effort to consolidate and simplify the proof, since as they say, it could end up effectively lost forever.
I work in the Chicago office and I love it! Our site lead is really passionate about making sure we're relevant, and the team I'm on has a substantial presence in Chicago, so I don't really feel like I'm in a satellite office.