Beanis

What distinction is being made between sharding by entity and sharding a graph? The approach seems to be the same, just with different naming.

From the little I can see from their blog posts, Schemaless seems to be both a sharding layer and an immutability layer that can sit on top of postgres or mysql. However, discussing the costs of mutable data when you have created an immutable data storage layer doesn't make much sense.

That is how I understood it too. Updating your data with a call to insert won't run into the same problems as updating your data with a call to update. Their immutability implementation seems like it would behave nearly the same under both databases.

All of these response posts seem to miss one big piece that made no sense to me. Uber goes really in-depth around the higher cost of updates in postgres, but then Uber describes Schemaless as an immutable append only data store. They created a custom database with no updates, but one of their primary reasons for changing from postgres to mysql was because of the high cost of updates?

I used to be terrible at interviewing. I know when I see other people going through similar problems, and make every attempt I can to work around them. There is only so much you can do though, and you have to accept that you will miss out out on some good candidates.

The phone screens I performed were just a quick first round check to see if a candidate would be a valuable employee for us. They weren't supposed to be super in-depth or time consuming for either party. The whole thing is basically one big ice breaker. Hoping that I can hit on some topic that will cause a candidate to expose some skill, knowledge or enthusiasm that would move the company forward. There was very little structure. It was all about finding skill overlap, and then trying to decide if they would pass an in-person round of interviewing. If I hit on an ice-breaker at the end of a conversation, it means I had already exhausted all of the others.

You're right. I was thinking about it for a while and have seen his name show up other times where I've thought about commenting and haven't. Normally I wouldn't say anything, and it would have stayed personal and private. I hovered over the submit buttton for a few minutes and then even after I submitted I was hovering over the delete link for a few minutes.

I wanted to give some perspective on what "not interviewing well" means in this case. It seemed as if a lot of comments were assuming age discrimination and issues with mental illness among other things. I wouldn't doubt that is the case sometimes, but from my experience that wasn't the case. There were other issues. I'm sure most people who interview him run into the same issues.

I think his biggest interviewing problem is that he can't live up to the expectations others will expect from a one-man encyclopedia.

I interviewed/phone screened Xah Lee about 2 years ago.

I'd never heard of him, so I skimmed over his resume and checked out his site an hour or two before the call. I remember when I was looking at his site I was seeing various articles around math and programming, and then articles about things like "2 girls 1 cup". The breadth of articles completely threw me off. He seemed to have this unfocused interest in EVERYTHING. After looking over everything I could I had no idea how we'd be able to use him, but I was really interested in talking with him.

I went into the call expecting a lot of tangents about various topics he was passionate about and thinking I'd constantly have to refocus the conversation. Instead the conversation was pretty boring and not really going anywhere. He had breadth, but the depth was not there. At least not for the things I brought up. I couldn't understand how someone who seemed to be interested in everything could have no real interest in anything.

For the last couple of minutes we talked about his site, and how he maintains/updates it. He finally seemed to light up, and we hit on something he was really interested in talking about. The basics of the site looked like it was just a couple of scripts, a lot of static text files and some emacs. The setup might have been impressive in the mid-to-early 90's, but it wasn't relevant to anything we would have wanted/needed.

The call lasted maybe 20 minutes, and then we wrapped it up. Every topic, other than talking about his site, was a dead-end. My internal feedback at the end was: "No! Maybe... if we were trying to hire encyclopedia writers".

I think his main problem with interviews is that his real-life personality doesn't even come close to his online personality. If I would have gone in expecting the standard slightly-awkward developer interview, things might have gone better. I still would have said no, but it would have been a weaker no.

Developer work is too varied to have a single consistent voice. Drop the union idea, the word has too much baggage and becomes a huge people management issue. Turn it into what developers do best, build an app/api.

I'm not sure if this idea will make too much sense; I need to see if I can find some time to explore it a little more. I could see building an app/api which is a mixture of a news/issue aggregator and a remote config editor.

Figure out how to surface issues to developers in a consistent way. Then let developers decide which issues matter to them, and how to deliver updated configs. Then let developers decide how to use the api/config from there. Maybe some apps will decide to disable in-app purchases for some time period, maybe some will alter code-flows to use a competitor of a big company, maybe some app will praise some company for their stance on some issue. The developers need to be in full control at all times though. The api would let developers read the remote config from their apps.

Maybe it just turns into a remote config service, and the activism part gets lost... but it might work as a vehicle for this kind of activism too.

I'm not sure if you are serious, but I don't understand what you think would be involved. If you remove the time inconsistencies from a calendar, any decent calendaring app will solve the scheduling problem you are left with. Scheduling is a data entry problem. It is a problem we have with or without timezones and dst changes.

If you live up north, adjust the local schedule instead of the clocks. If kids are waiting in the dark, move the start time to later in the day. If it is light out at midnight shift your schedule so you go to sleep after 12:00am. If you are living your life based on the position of the sun, the numbers on the clock are going to mean something a little bit different everyday anyway.

Time is supposed to have a relatively consistent meaning, and we jump through a lot of hoops to give it an inconsistent meaning. Schedules are much more fluid and easy to change with little external side-effects.

People will need to learn to partially decouple their routine from the numbers on the clock, but that seems like a much simpler/cheaper problem to solve than our current time mess.