1,196 karma · joined November 21, 2015
If they are raising $175M, their dilution is probably in the ~15% range, putting their valuation a bit north of $1B.
So, each founder probably is worth, on paper, around $50M right now. Again, this assumes equal splits. It's possible that the CEO has more shares by virtue of assuming greater responsibilities.
For example, it's impossible to invest in just AWS without AMZN's other business. However, AWS is far less susceptible to the current macro geopolitical instability than AMZN's retail business.
One of the most common biases I see in how we assess leaders is how we try to attribute success & failure to a single person at a discrete point in time (ex: Here in the US, the extreme Left claims Trump is taking credit for Obama's foundational effort for the economy while the extreme Right says it's all Trump). In reality, it is never that simple nor discrete but rather complex and continuous.
Do you know what Segment does? It makes it easy to send data anywhere -> https://segment.com/catalog
That said, the point OP was making is that in a startup origin story, there's a significant perception gap between those who actually moved the needle and those who claim to have done so. Those who actually drove the bus and those who rode it. Time and again, I've seen the latter people take advantage of the relative reticence of the former.
It's probably more like, "relative to this guy who tried to kill my company early on and later claimed undue credit for its founding, this dedicated early employee surely seemed like she worked 20+ hour days and sacrificed everything for me."
As someone who's also been an early employee, I totally see why Heather does NOT claim to be a co-founder. When you work your ass off alongside the founders, you learn two things:
1. Building a company is incredibly hard.
2. Nobody takes it harder than the founders.
Yes, I have worked hard. In the last six years, I always worked parts of my weekend if not my vacations (which were few and far in between early on). I pulled off all nighters as well as a last minute trip straight from work to close a customer. I fell asleep on my laptop answering support questions. There were many nights of dry tears and waking up in cold sweat from nightmares that were all too real.
But what I went through is a fraction of what the real founders went through. And I saw their ups and downs up close.
Startups are hard. Incredibly hard, especially for those who has to lead the ship from Day One. Early, dedicated employees see this first hand, thinking to themselves, "Man, I thought I had a good/bad day, but they are probably having it better/worse". That's why we never claim to be the "founders".
If someone is serious about array programming/APL and wants to make a lucrative career in it, study KDB+/Q/K. There's a small but active community around them.
Just to relate an anecdote: I used to be a fairly active KDB+ programmer in finance but left both finance and programming ~8 years ago. Just yesterday, I got an email from my friend who's building a statarb fund around cryptocurrencies. They were going to use KDB+ and offered me a job for "300-500k base with incentives"...
My friends clearly don't know that I now work in sales & marketing :D
Aside: Roger Hui, the creator of J, is a programming sibling of Arthur Whitney, the creator of K/Q and the founder of www.kx.com
If I had to guess, Dropbox improves their margin by getting people to share files and folders (because that counts toward multiple users' quotas).
1. Sundown is the name of a Markdown library written in C: https://github.com/vmg/sundown. That Sundown is pretty widely known and used among Markdown implementers. As such, when/if the OP's project takes off, it is going to be confusing (for awhile).
2. Also, the name itself doesn't strongly suggest that it's an alternative to Markdown. Do recall that Markdown's etymology comes from "(HTML) markup". For the Markdown-implemented-in-C Sundown, the name worked because it evoked its relationship with Markdown. In this case, that's not what the project is about. If the intention was to evoke Markdown, then they should have kept the "Mark" part of it, not the "down" part of it.
Based on that experience...
1) Yes, but that's not huge by modern standard.
2) Q is a DSL version of K. As others have commented, K is a pretty clean implementation of APL, and Q makes K more approachable.
3) I have to agree here, but Q for Mortals makes up for it.
4) It is really fast. As we all know, a vast majority of us actually don't have terabytes and terabytes of data, especially after a reasonably cleanup / ETL / applying common sense. I suppose it helped that I worked in finance, which meant my desktop had 16GB of memory in 2009 and 128GB of memory on a server shared by 4-5 traders.
Finally, Q was never intended for general-purpose computing nor a widespread adoption. At least when I was an active user, the mailing list had the same 20-30 people asking questions and 3-4 people answering them, including a@kx.com (= Arthur Whitney, the creator). Back then, I'd say there were at most 2-3k active users of Q/K in the world. Now that Kx Systems is part of First Derivative and has been working on expanding their customer base, perhaps they have more...?
Ditto. And if you still prefer the schema-free approach of JSON but with faster encoding and decoding support across all common programming languages, take a look at MessagePack.
Unlike JSON, MessagePack is optimized for speed and encodes common data types efficiently. Unlike Protobuf/gRPC, it requires no centralized schema.
MessagePack: https://msgpack.org/
1. Right off the bat, there's the cost of building all of this + maintaining it. Something like Mixpanel at scale requires at least two, if not three, engineers: one for client libraries, one for infrastructure (which the OP blogs about), and another for the web app (dashboard, real-time user stream, etc.) To be sure, not everyone needs all features of Mixpanel. To be really sure, nobody needs all features of any SaaS tools. But if you really want to compare apples to apples, then you have to account for these. To hire competent software engineers who can collaborate closely and maintain a complex piece of analytics software requires at least $100k per year, if not twice that based on locale. That's at least $300k and more like $600k right there.
2. The whole point of something like Mixpanel is to make analytics accessible to non-engineers. In their case, it's primarily product people and secondarily marketing/customer success. In any case, building an analytics/data product consumable by non-technical people is hard and takes way more than assembling a couple of cloud infrastructure together. If there's one reason Mixpanel is still in business, that's because of this.
3. Finally, the OP has a valid point which should have been highlighted more, if not to make their own biases more clear: Mixpanel's diminishing differentiation is dev shops/consultancies' opportunity. It is indeed incredible that a dev shop can build even a third of Mixpanel's functionality by leveraging GCP components. Mixpanel had to build a lot of its core backend systems from the ground up, including its original key-value store. Just this year, they fully migrated to Google Cloud Platform themselves, suggesting that there's really little room for differentiation among analytics vendors at the level of infrastructure components (Mixpanel's arch-nemesis, Amplitude, leverages Apache Kafka and various AWS components, most notably Amazon Redshift, heavily)
With all of this being said, one thing remains true: the most expensive cost of any software is people running them and the dependencies created around them. These may not show up as line items, but they sure are deeply embedded in your total cost.
We are looking for solutions engineers to help our global customers use their customer data better. We believe that businesses should own their customer data, not outsource to the Google/Facebook duopoly.
This is a job for you if:
* You have a technical background and interested in leveraging it to create high-impact solutions for customers: many of our customers are household names. The best candidates have a technical background (formal or not) combined with customer-facing experience (consulting, running their own business, etc.)
* You enjoy gnarly technical challenges around data.
* People describe you as resourceful, smart and empathetic (all three are important qualities for this job) * You don't mind traveling: there will be a fair bit of traveling.
About Us:
* Series C, HQ in Mountain View, offices in Japan, Korea with dozens of remote employees
* Active contributors to open source: Fluentd, MessagePack, DigDag, etc.
* Great salaries and benefits
* We invest in our people: most successful managers have been promoted from within
If you (or anyone on this thread) is interested in learning more, please feel free to ping me.
Great to see such corporate changes toward developer-friendliness.
However, when it comes to end-to-end experience, Apple's vertically integrated approach is simply better. This is one of the key reasons I switched back to iPhone recently: I just want my phone to work and to be taken care of when it doesn't work.
It's sad because every operator I know knows this yet succumbs to the myth-making "hack" because that's how you tell a "good story" that attracts much needed attention among media and the investment community. Traction, hockey stick curve, growth and all that jazz.
And to be fair, it's not entirely VCs's fault either. They have to deliver on their investment promises within a certain timeline. What's really terrible is that there's not enough discussion about this in the VC-backed entrepreneurship community to accept that this is the "game" that everyone has to play.
I've heard this from many users through my work on Fluentd (in fact, many end up using fluent-plugin-bigquery because they don't want to deal with the minutiae of insertId and whatnot on their own).
Also, I don't think a lot of people fully understand the quota policy and get tripped up: https://cloud.google.com/bigquery/quota-policy
>Separately, you can always use BigQuery's federated query capability of Bigtable.
Yes, and very few people understand what that means (I had to look up, and I am reasonably educated on GCP). This is not necessarily product shortcomings but packaging deficiencies that can be addressed with better product marketing.
This. I call it "end-to-end latency" and it doesn't get nearly as much attention as it should. This is, by the way, why it's a bad idea to use most OLAPs (like Redshift) as a backend for Segment if you want "real-time" analytics. Column-oriented OLAPs are not designed for real-time ingest because either they don't support streaming inserts (Redshift) or it's not particularly reliable (BigQuery).
While the principle of "per article" pricing is appealing, it won't probably work in practice: generating content worth paying for is not like spinning up servers because the cost of production occurs upfront _and_ have non-zero marginal cost.
To be sure, WaPo also sells data to their advertisers. At the same time, WaPo has broader coverage and probably needs a larger newsroom as a result. Ars Technica is a subsidiary of Conde Nast, and Conde Nast as a whole has paywalled publications (like New Yorker).
In general, I think it's perfectly fine to promote paywalled content on HN so long as the content itself is good. We have to fund quality reporting/writing, and HN can serve as a curation mechanism to surface "content worth paying for".
That said, Rails is hardly the only framework that has brought Ruby to the communities outside of Japan. Chef/Puppet/Fluentd played a key role in bringing Ruby to the ops world while books like "Understanding Computing" by Tom Stuart demonstrates Ruby's potential beyond web programming.
There's a tangible tension between Rails fanatics and sans-Rails Rubyists, but they have needed each other to get where they are today.
Completely independent of what's going on at Uber, I sympathize with Kalanick and his family. It's very hard to balance family tragedies with entrepreneurship.
The beauty of this product is that its adoption strategy is baked into the product itself: I'd share this with all Excel user friends of mine because I want the algorithm to get smarter, and I might even learn a bit of C# myself so that I can contribute and scratch my own itch. This in turn makes the product better (because of the larger training data), lending itself to more word of mouth.
One concern I have is security: I'd love to hear from folks who built this/more familiar with this about how to ensure the security of suggested transformations.
People misunderstand Google: they offer things for free because it lets them collect data (search, gmail, etc.) or it drives competition out (1TB free for BigQuery, for example).
For everything else, they either shut them down or charge money =)
One such example to me is his overview of Acme: https://www.youtube.com/watch?v=dP1xVpMPn8M
Russ's demo is one of the clearest technical demos I've seen.
I am really curious what was the thinking behind Square's UK launch (if there was). At least as a business traveler (and admittedly in London, the financial center of Europe), I saw no space in the market for Square to enter.
[1] (The ONLY place I could not use Android Pay was Apple Store)