RethinkDB looking for a technical cofounder
defmacro.org
defmacro.org
Larry Ellison said: "Flash".
Apparently, Oracle is taking flash very seriously. They already have a flash-based Oracle database product that is shipping.
And with the Sun acquisition, Oracle now owns MySQL.
RethinkDB needs to move ahead fast.
- You're not afraid of modifying Linux kernel source code.
- You're not afraid of modifying MySQL source code.
Both Linux and MySQL are huge, complex systems and if you want someone who can immediately start making usable changes to those systems, you should probably recruit on their respective mailing lists. Developers running in to huge things like Linux and MySQL ad-hoc and making changes causes lots of problems. See Debian's SSH-certificate problem from a year or so back for just one immediate example.
As with any complex platform, it takes a lot of tinkering and experience to know what flies and what doesn't. Those dudes should change their ad away from the cute thing to the serious thing unless they plan on allowing the hire time to figure these things out.
Hacking Linux really isn't that hard. I implemented two kernel-level projects - a stackable filesystem that gives you an assurance your files haven't been tempered with, and an "object orientation" system that lets processes modify and inherit their syscall vectors. Each project took about four days and I never looked at the kernel code before. I had pretty good access to a Linux expert who pointed me in the right direction, but I didn't ask that many questions. It wasn't the caliber of code that would make it into vanilla, but it was very useable.
The idea that hacking the Linux kernel requires superhuman abilities is a huge misconception. I can assure you that I'm as far away from being a genius as anyone. If I could do it, any reasonably competent software developer can. And the complexity of MySQL codebase pales in comparison to Linux.
We want some degree of experience hacking high performance low level systems, but we care about competency, determination, and ability to ship working code far more than experience in any specific area. It's Linux and MySQL today, but it could be FreeBSD and Postgres tomorrow.
I'm not saying one can't learn, but I am saying that most good developers who haven't changed the source code for ginormous things like MySQL and Linux _are_ scared to take a new job where they're expected to be able to make meaningful and/or significant changes to any ginormous thing they don't have much familiarity changing, especially if you want to changes that are immediately deployable in your project.
If you're going to give the dudes time to get used to MySQL and Linux and tinker and discuss adequately, then that's fine. If not, and you expect them to go from 0 to "usable filesystem" in 4 days, you should probably be more specific in your ad.
Deleted comment
Fortunately, we get to deal with both world-class legacy systems, and write some blank slate code. We get the best of both worlds :)
They've gotten a huge amount done in the last few months -- in my "On Applying to YC" entry, they were the most notable exception to the "the teams that were moving the fastest at the beginning were also moving the fastest at the end".
But if you remove YC from the equation, RethinkDB probably wouldn't have incorporated yet. (Well, let's pretend that they wouldn't have, at least.) They're just a few months in. Really, I think it's exceedingly rare when "co-founding" teams all start on the same day. There's a period where the company comes together over a few months and the people that are there when it incorporates become codified as the "co-founders". In this case, the RethinkDB guys are early enough on that I think some of that DNA is still being laid down, and the term co-founder isn't completely off.
If it dies, the law considers there there is a very large difference. :-)
More seriously: The English language says that "co-founders" are "people who found together"... not "people who found together plus anyone who joins them shortly thereafter".
If this to-be-hired person is going to be on-par with the existing "founders", in terms of pay, equity, and ability to vote to affect the outcome of the company, then I would call them a co-founder.
If instead this to-be-hired person is going to be a very senior employee with more equity than later employees, and some input on the product management stuff, then they are an employee, not a co-founder.
I do not know which case is true, my only point is that we do not need to invent new pseudo-titles for everyone to feel special.
ie. A first emplyee doesn't usually house with the founders. A cofounder may be expected to.
I've also had conversations with other founders who independently used the exact same language to describe how they feel about their companies.
My simple rule: if there's nothing there when you start, you're a founder.
Expecting these things and calling the person an employee would be dishonest at best. We're in this to nurture a great company, not to nurture our egos. We feel that assigning a title of employee at this stage would be a display of vanity and would significantly detract us from the real goal of building a next generation database that will change the world.
We clearly have different opinions here. I'd say that calling an employee a cofounder is dishonest at best; that you're in this to nurture a great compnay, not to nurture your employee's ego; and that for someone who joins several months after a company is founded to insist on being called a founder is an unreasonable display of vanity.
- I don't think it is fair to expect your 1st employee to put in 15-20 hour days consistently. Even if the 1st employee did put in such effort, as Rethink guys point out, they would be putting in almost the same effort as them and thus calling him/her an "employee" would be wrong.
- A big objection you seem to have relates to how long the company has existed. You think that 3 months is a long time for a cofounder to come in. If you look at the longterm roadmap of a startup, the initial 3 months hardly register. Do you think 10 years from now the new cofounder will look back and feel inferior to the other founders? With each passing day the 3 month thing becomes less significant.
Your disagreements are not so much about semantics as your lack of understanding between the possible difference in pay, expectations etc. between a cofounder and 1st employee. It might be subtle but it exists.
You can give someone the amounts of equity and salary which are normally given to cofounders, but that doesn't make them a cofounder. The word "cofounder" doesn't say what you do; it says what you did -- specifically, it says that co-founded something (in this context, a company).
If I incorporate a company one day and bring you on board the next day with half of the available founders equity then would you argue that you're "just an employee" because you weren't there on the day that the company was incorporated?
When did attempting to maintain consistency in how the English language is used become playing semantic word games?
... would you argue that you're "just an employee" ...
No, for two reasons. First, I wouldn't say just an employee, since I don't consider that word to be derogatory; and second, I wouldn't stop at saying that I was an employee (unless I was deliberately attempting to obfuscate) because that would fail to mention a large equity stake. I would probably say "early employee", "co-owner", or something else along those lines.
But if the company was founded without the intention that I would be part of it, I would never claim to be a co-founder.
In practice, founding a company is a process, not an event, and hence is an interval of time, not a specific point in time. Legally, founding a company is considered an event at a given point in time, purely for reasons of convenience (how do you tax something that came into existence over a period of time?)
If you look at it that way, we're coming from the practical standpoint, not from a legal standpoint, and we feel that on the practical side we're still founding the company. If you look at it this way, poof, the inconsistency disappears like a cloud of smoke :)
Sometimes using a label that is technically incorrect is the most succinct way to make a point.
You're looking for an employee.
Also, the most important feature for SSD storage (no random writes!) is fulfilled by Cassandra / BigTable implementations based on SSTables, I wonder how a btree-based implementation compares to them.
Today a gigabyte of NAND costs less than 1/3rd as much as a gigabyte of DRAM and the gap between the two is growing. ... By the end of 2012, when a gigabyte of NAND costs 1/19th as much as a gigabyte of DRAM, the optimum balance of flash/RAM will be very different.
The Q is, why don't directly jump to RAM instead to take this intermediate step?
But RAM is still more expensive than Flash.
That said, seriously, I think that what applies for SSD applies for RAM: that it's going to be cheaper and cheaper, and bigger, super fast, and unlike SSDs the writing and reading latencies are comparable, so even if as today it's a psychological barrier to hold your data in RAM, I think it is going to be much more common in high load applications in the future.
Actually most people are doing it already, with memcached. Sometimes the total memcached memory used could be enough to store the whole dataset well organized given that when you use a K/V cache a lot of space is wasted compared to using it to hold data.