ericwaller

I find the idea of IRL multi-user UX really interesting. So much of modern computing is built around a 1-to-1 model of users and devices. And then multi-player, collaboration features are built on top of that. Sometimes they’re quite slick (ex. figma) and sometimes they’re pretty clunky (ex. apple family sharing stuff).

But what’s really lacking is a model for multiple people sharing a single computing experience in real life. Companion mode in Google Meet or Spotify Jam are two attempts but both still force you through the one user, one device path.

Two adults sitting in a car shouldn’t have to constantly think “whose phone is this?” connected to CarPlay. Especially when they’re part of the same Apple “family” and on a Spotify family plan.

Two people seamlessly interacting with one “system” would break all sorts of auth and other assumptions, but it seems worth figuring out as computing becomes more and more prevalent in every facet of life.

I like it! I've definitely found myself doing this while manually breaking lines in code comments

I'm guessing you mean music venues? The short answer is yes, eventually.

The slightly longer answer is that we'll probably be the strongest option for smaller venues that want to do more complex stuff. To the extent that there's always some tradeoff between simplicity and power, we're likely to continue to lean pretty heavily on the power side for our core ticketing system.

Very cool (well, not the getting screwed part). Most of my experience so far is on the sports side, with music exposure being more indirect.

It's amazing how many ticketing systems of various forms have been built over the years. It seems like one of those things that should be simple, but there are just so many ways to slice it.

Heh, I may get overly excited to tell people that we're building a Ticketmaster/Live Nation competitor... The sentiment that one is sorely needed is so common, and yet so few people know we're doing it (the StubHub comparison is more typical)

Almost as a rule, in the US at least, large multi-purpose venues sign exclusive contracts with their ticketing provider. That means that all events, including any concerts that come through the building, are ticketed by the venue's chosen ticketing provider.

While we're probably better known as a consumer app for buying tickets, SeatGeek also builds the full set of software you need to run a major venue. Everything from issuing and managing season tickets for the resident pro sports team, to working with promoters in selling tickets to their national tours and hosting the big, high-demand concert on-sales that accompany them.

A big component of our path into the market is that it's often the resident pro sports team that operates the venue and makes the ticketing decision. They tend to be very focused on the fan experience, particularly for season ticket holders, and that's our strong suit.

For anyone who wants to take a crack at building a competitor on the ticketing side: https://seatgeek.com/jobs

I can't speak to any of the details, but this is definitely an interesting approach: https://www.cnn.com/2021/05/03/business/running-tide-kelp-ca...

This is a great insight for full applications.

But latency (mostly) aside, there seem to be a lot interesting use cases for what is more or less programmable CDN configuration. Particularly when you have a relatively straightforward application (architecturally at least), but want to tap into the very distributed, very scalable CDN layer for little bits of critical functionality.

I'm one of SeatGeek's cofounders, good question.

It was indeed Apple's "Sign In with Apple" deadline that prompted us to make the change (for those who don't know, apps that offer sign in via a third party auth mechanism will also need to offer sign in with Apple), but it's something we've considered on and off for many years.

Two big reasons. The first is that when we work with pro sports teams, fans of that team are able to sign in to their team accounts using SeatGeek. Having Facebook, and potentially Apple, also in the mix there felt like it would lead to a lot of confusion. The second is that while we've seen that sign in with Facebook leads to more sign ups in the first place, we've also seen that it causes confusion for users who are later unsure how they initially signed in, and that confusion can hit just as they're trying to pull up their tickets outside of an event.

For what it’s worth, Amazon did just have a very public search for an HQ2 location and ended up picking one on the other side of the country: https://en.m.wikipedia.org/wiki/Amazon_HQ2

That's actually not the case, estimated tax is due quarterly (ex. for income in Q1 of 2016 for which your employer doesn't withhold taxes, you have to pay estimated tax by April 15, 2016).

But yeah, definitely talk to a CPA.

Heh, I always feel a bit bad when people mention this since we're not using it ourselves anymore. Though it's a nice and easy way to get going quickly if you're already running redis (and especially if you've got a rails app).

We're using elasticsearch now which is definitely a bit more of an operational headache.

Go's JSON parser ignores fields that aren't present in the destination type, so the addition of new parameters shouldn't be a problem.

All you kalman filter fans out there will be happy to hear that you can grab a ride from SideCar and some Giants tickets from SeatGeek[1] for a truly algorithmic afternoon.

1. http://chairnerd.seatgeek.com/using-a-kalman-filter-to-predi...

Eric from SeatGeek here. Do you happen to remember what you searched for? I'd be happy to take a look at why you got that odd result. "uconn women's basketball" seems to work for me (I get http://seatgeek.com/connecticut-huskies-womens-basketball-ti...), but I can imagine there are plenty of queries which are less well-behaved.

For anyone skeptical of the claim "90% of Expedia's business comes through their API," it appears to actually be 90% of the Expedia Affiliate Network's business [1], which is far less interesting.

[1] http://www.travolution.co.uk/articles/2012/04/04/5576/open-a...

For some context, I work at SeatGeek, Jack's startup, and participate in the later stages of the hiring process referred to in the post.

I think something that a lot of the recruiting/hiring discussions on HN miss is that the hiring process is not only about finding people who are capable of doing the job. It's also about finding people who will thoroughly enjoy doing the job and get along well with the rest of the team.

For example, I spoke to a candidate (in other words he made it through this set of heuristics) whose background was in security and whose primary platform was windows. He was definitely very bright and very well accomplished, but by the end of the interview, I genuinely thought he would have been bored out of his mind at SeatGeek.

Similarly, if you don't use at least one of OSX, git, ruby or python, there's a decent chance SeatGeek just isn't for you. An important caveat, that should probably be in the post, is that if your answer to any of the specific-tech related questions is "no, but I saw that you use X at SeatGeek, and I'm interested in learning more about it", that's probably equivalent to a "yes".

I actually like the side discussion about restroom design a lot. The difficult part about these types of problems is that the guy who's picking up the paper towels doesn't have the authority to move the trash can.

From page 3 (http://tools.ietf.org/html/draft-ietf-appsawg-xdash-02#page-...):

employ meaningful but currently unused names

I think what vaksel means to say is that Thiel's 20 under 20 project will prove nothing about the value of a college education because his sample consists of 20 of the most brilliant kids around. It would be like trying to demonstrate the worthlessness of a programming course by taking 20 brilliant programmers and having them skip it before starting inevitably successful careers.

I think that ambiguity is important to the feel of ruby code. It encourages you to think about expressions in terms of their semantic meaning rather than their imperative effect^. I think python's @property decorator is a testament to the "nice"-ness of said ambiguity.

^ I realize this can also be dangerous and is the same reason '!' is encouraged as an annotation for methods which have significant side effects.