fizx

There's a difference if the client developers can register stored procedures. Typically, you can't do that with RPC, and it's a big value-add of GraphQL.

If that happens, then SQL and GraphQL look a lot alike. SQL would be more powerful, which also means that it'd probably be somewhat harder to implement, though there are so many SQL engines existing. I can't imagine people implementing from scratch.

I can't wait for Hasura SQL-to-GraphQL-to-SQL.

Depends on whether you want to exist on ads revenue.

You could run Meetup with 5 people in a basement if you had simple subscription revenue, but effectively maximizing an advertising opportunity requires at least ~1000 people.

protobuf can do nullable values, but you have to ask for them as primitives are the default. e.g. StringValue (nullable) vs string (not)

Quick, give him a growth-hacking gig!

Take-home projects are a band-pass filter on hiring. The best candidates won't bother, the worst candidates can't complete.

Though, honestly, it seems like you could save everyone's time and get similar results screening for university GPA > 3.8.

https://gradientretreat.com/ is close to this.

It's a bit harder as a programmer, because we naturally have access to money in a way that artists don't, so people are less inclined to help us.

I do recommend taking significant sabbaticals in your career, finding a corner of the world, and writing some project by yourself. I've done this three times, and it was quite rewarding, though a bit lonely at the end.

I don't think I've seen another situation where the arguably premier framework for some language was so contrary to the language's purpose and community goals.

It would be like building a GraphQL framework that serialized all data as Base64'd XML inside a single field, or perhaps if the biggest Burning Man art car was police-themed.

LMAO Ferret was sooo bad. It was written by a guy who effed off to Japan to study Jujitsu, and I remember my first startup job was porting all of its ints to size_t.

I mean, that product is called LogDNA.

But Elasticsearch has evolved into a whole bunch of things to meet everyone's needs. There's a way to do what you want and simply, but you have to find the simple path in the middle of the big product.

You don't get to lead thousands of people by making publicly offensive statements, even accidentally. So yes, that does lead to more boring answers to newspapers.

Politicians don't swear in public, but they sure do in private. I'm sure a smaller conversation with Jeff would be fascinating.

It's rare that I notice the compile time for either. Incremental compilers are great!

That's more of a proof that regexes can't do everything, than a proof email is bad.

It's amazing how much driving a nice car in a downturn makes your employees hate you.

You're both right :)

You want the "quirky rockstars" as your prototypers, not your architects. Then everyone can thrive.

My brother built a wedding photography business in ~2008. He filled out the entire first summer of bookings with $50 of highly targeted facebook ads (female, engaged, 200mi radius).

The same ads today would be much more competitive, but there's a huge amount of leverage here.

AFAICT, the point of GraphQL to get an API that corresponds to your React state tree, so that there's much less mental overhead from client developers who don't want to deal with multiple shifting data representations.

Batching almost seems like a nice-to-have.

This is a UI-centric take.

There are lots of internals that could/should be shared between apps. Recently relevant examples: a customized WebRTC stack, a websocket client with extra authentication and delivery rules.

FWIW, my take on this has been to embrace Conway's law: if you have enough shared work to form a team around it, then break off a c++/whatever library and a team to maintain it. But if the hope is just to save 200LOC here and there, just bite the bullet and write it twice.

Big thanks to whoever pointed out Kotlin Native: seems interesting enough to poke around with.

That's around 100,000 engineers worth of salary. Good luck (:

Hello from Sequoia Capital!

Hi, I'm a senior human acquisition engineer with [some dumb startup] who just raised an A round with Sequoia (yet to announce, please keep confidential).

Talking E2E for a second, would you like to hear about the great work we're doing?

(1 day later)

Hey, bumping this up.

fast.ai

Agree that 90% of people want to do effective work. The problem is that 6 people have 7 opinions about what effective means.

It's not about blame, it's about trying to ensure the team works together cohesively, and that individuals are unblocked.

Making standups useful to everyone on mid-to-large teams (i.e. > 6:1 employee:manager ratio) is quite challenging, but yes, you raise a good point that this is viable, particularly for smaller teams.

As someone who has gone to the dark side, there's an interesting tradeoff here. There's basically three scenarios:

(1) all employees are trusted and unmeasured, but you have to tap people on the shoulder every once in a while to confirm that they're on track. Naturally, this is easier if everyone is on-site.

(2) everyone is accountable for producing of tickets, and you can check that everyone is at least doing some work. Check-ins can happen via comments in tickets.

(3) Everyone just does whatever they think they're supposed to be doing, and the manager only finds out something is wrong when the employee volunteers the information or the project isn't delivered on-time.

(1) is the common case, (2) requires time and skills many managers don't have (and creates @#$% Jira commentary form the peanut gallery), (3) requires building an excellent team with years of mutual trust between them, and still goes wrong all the time.

Seeing you at your desk working, and asking a casual question or two at the water cooler is by far the easiest (laziest?) way to make sure things don't go too far sideways.

Ideally, every self-driving car would have secondary insurance baked into its price. If someone dies, it's an insurance payout of a standardized amount.

A reasonably configured Postgres is easily sub-millisecond for reads and writes on a small dataset like this. I suspect that the author is doing something quite wrong.

People generally reach for Redis too quickly, IMO. Postgres is about as fast, has better tooling, and will slow down gracefully as the dataset increases, rather than evicting records as the limit is hit.

That said, I guess if you're relatively junior, it's hard to grossly misconfigure Redis, so that's a point in its favor. Somewhat like Java vs Node.js--you can write higher performance network services in Java, but it's a lot easier to make mistakes.

It is illegal, which is why you'll never see them do it in writing.

There's plenty of active research into quantum computing meets machine learning. Any real progress here would create quite a market.

> After a company grows beyond its ability to maintain order within its own activities, it should always prune down toward its essential businesses and reform itself before the next stage of growth.

Why?

I use SQLAlchemy to serve tens of thousands of requests per second on one of my services at Reddit. It's painful, but possible.

SQLAlchemy uses the data mapper + unit of work patterns. This means that your connections and your record objects have the same lifecycle. If your request takes 200ms, then you are likely holding open your connections for 190ms, even though the only SQL query takes 20ms. If connections are scarce, and they usually are, you will not utilize them well at all.

There are two ways that I know of to solve this, neither of which is pretty: (1) run pgbouncer as a sidecar on your python processes. This has the effect of making connections a far cheaper resource. (2) After every single query, manually close the related transaction/connection/cursor in your code.

ActiveRecord defaults to giving up the connection after every query, which in a high-traffic webapp, is much less of a footgun.

I have a non-striver on my team of strivers. He is quite valued, because he's:

- always fun to be around (a consequence of not being overloaded)

- the guy to say "the emperor has no clothes" (having time to look around does that)

- always accurate with his estimates (because he really doesn't want to work overtime)

- always high-quality with his output (because he's not rushed)

Done right, working at 80% speed means that you have 20% of your time to pick up the super-high-value tasks that might otherwise fall by the wayside.

Now, maybe he'll get promoted more slowly than his potential as a striver, but I don't actually think that's going to happen.