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.

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.)

[1]: https://yaml.org/spec/1.2.2/

[2]: https://yaml.org/type/merge.html

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?

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:

https://philosophy.williams.edu/files/Egan-Learning-to-Be-Me...

This is focused on just one aspect of the philosophical dilemma, and both Dennett and Egan touch on the horror of it in delightful ways.

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.

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.

[1]: http://www.dms.umontreal.ca/~andrew/PDF/VS.pdf

I wrote a semantics doc to try to help on the documentation front:

https://google.github.io/dagger/semantics/

It's not intended as a tutorial, so perhaps it won't quite meet your needs, but if you're curious how all the pieces fit together, it may help.

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.

In that case, you should divide by "expected", so you get a percentage difference for each day. (Normalizing by total for the year doesn't make sense, since imagine that there were 300 days per month instead of 30 - your numbers would be divided by 10 again, but the data you want to visualize would stay the same.)

A few comments on the stats themselves:

1. It looks like the total number of tickets in 2009 and 2010 is about 10% that of 2011. I'm guessing that there weren't actually ten times as many tickets given in 2011, so either the data is incomplete (as the author suggested), or there was a typo. If the data is incomplete, I'd suggest normalizing to the 2011 totals; otherwise, the 3-year average doesn't make much sense.

2. The scale of the "normalized" difference graphs (showing "Actual - Expected"). The formula given is

(actual - expected) / total * 1000 = normalized number

If this is the case, then since the scale goes to about +/- 5, the differences are very small (less than 1% away from what you'd expect!). But from eyeballing the data, that doesn't seem right.

In any case, a better scale might be to expect the data to be normally distributed, and scale the differences to # of standard deviations. (See, e.g., http://en.wikipedia.org/wiki/Normal_distribution#Standard_de...)

There's plenty of discussion relating to the article he references at http://news.ycombinator.com/item?id=4455225, and much of the same applies here.

1. He's not comparing apples-to-apples between `std::list` and his intrusive linked list; the proper analogue would be to unlink a node from its iterator, for which the running time is still O(1).

2. The main (only?) reason to use intrusive lists is for the single indirection (which helps both memory and speed). In his example for how using std::list would crash his server because of the O(N) node removal, he's just not storing the right data for each connection (again, use an iterator).

3. He looked at boost's intrusive list, but I'm guessing he didn't actually try it out. The examples are pretty good, and it's much easier than it "looks". (That is, boost libraries can look intimidating when you first look at them because they're so template-heavy.)

4. It may even be that a vector, plus an auxiliary data structure for lookup, may be faster.

You can do a second pass over the list to check that your solution is actually a majority element. This maintains the linear time and constant space properties.

> On his LinkedIn page, Mr. Milner lists his occupation as “hacker,” and under the category called “Specialties,” his entry reads, “I know more than I want to about Wi-Fi.”

While I don't know for sure which use of the word "hacker" Milner intends, the author of this article ought to have added a line like, "Software engineers use the word 'hacker' in a positive, non-malicious sense...", since this is effectively taking his words out of context.

@ghempton, if you're still reading these comments, it's likely you're passing a iOS 4 or 5 message without checking to see if the message is received.

I ran into this recently with a number of simple startup checks, e.g., if the device is a high-res ([UIScreen scale]) or if it's an iPhone vs. iPad ([UIDevice userInterfaceIdiom]).

There is a touch arcade thread that people occasionally visit, but most of our contact with our users is through email. We're planning to add a direct email link in our "about" page in the game (we already have a link to our website), so hopefully that will make it easier for people to contact us.

(We readily admit that we're pretty bad at forming a community. This is a spare-time thing for both of us, and neither of us uses twitter, facebook, or really any social service, much personally, so we feel a little like fish out of water when it comes to the social aspect of the game. We have a level editor, but no way for people to share levels outside of the game itself, and no way for people to talk about levels they make. We're getting there...)

I understand that, and it's happened to me a few times also.

But I still feel like the first response, if it's possible, should be an email. We're just a couple of guys, and both our website and our game's credits make it clear that we're not a major faceless company.

I suppose people are conditioned by large companies ignoring them, so I hope that the proliferation of indie developers in the App Store can recondition people to actually send emails.

We love getting direct email from people, and we respond to every single one. I think people are sometimes surprised to get a personal reply; hopefully that won't be such a surprise if enough developers do it.

We just had this problem. Someone posted a 1-star review on the App Store saying:

> I create puzzles under the username: [---]. The editor is designed to allow you to upload an increasing number of puzzles as a reward for earning high ratings on those puzzles you've created so far. However, if the rating drops, the puzzles you can upload may actually drop. This is lame and unfair. Numerous times I've trashed a puzzle with the intention of replacing it with a new one, only to find that I am now not allowed to upload a new one because my max number of uploads has dropped. Fix this and I will give you 5 stars. Otherwise I will stop uploading puzzles altogether.

The annoying thing is, he's absolutely right. We didn't think of this use case, and we're fixing it right now (it should be rolled out within a few days). But it's so frustrating that he felt like he had to threaten us ("otherwise I will stop uploading puzzles altogether") and didn't even think to contact us first.

And what's more, he decided that our game deserves 1 star, even though he's clearly played it for many, many hours, and presumably has really enjoyed it.

I'm doing this too, and we're using a 128-bit random GUID, which has an unfathomably small chance of being a duplicate.