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

I doubt I'm the only one who made this choice. For some of us, content is still the reason we use a web browser; that includes those of us who value privacy and minimising the amount of arbitrary code we run on our devices.

Apps market? Piwik (tracking)? Why would I allow these?

https://i.imgur.com/OFWYnWy.png

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".

1. 20-hour days are not actually worked, not even by slave labor.

2. Sacrificing your personal life for your employer is pathological, not heroic.

This isn't an article about heroism. Keith Teare claims he co-founded TechCrunch. Arrington says "no" and then details why.

One part of the "why" is about value-adding output. Arrington "could never get [Teare] to write anything, or help pay any bills." Co-founders add value; Keith didn't do that.

The second part of the "why" is about input. Output requires input. But it's fair to highlight both, in part to block claims of unappreciated work. In highlighting Heather's "20 hour days" and "sacrificing [of] her personal life," Arrington draws into contrast the difference between someone he considers a co-founder and someone he doesn't.

> 20-hour days are not actually worked

Founded a company. Worked twenty-hour days. Deceptively easy to do if you're chasing a short-term deliverable across multiple time zones. (Short-term because this tactic is obviously unsustainable.)

I've pulled my share of all-nighters too, but (from the comment) the implication was it was a regular thing.

Far in the weeds here, I guess if I had RTFA maybe I wouldn't have bothered to comment. :-)

Then you've never been there. Yes, they are. Have done it many times.

If you're regularly working 20-hour days, as opposed to the occasional all-nighter, then you're not doing anyone any favors -- not your company, not your friends/spouses/children, not yourself.

But anyway I was alluding to the tendency to boast about how little one sleeps...

I'm definitely dead inside by the weekend, and noticeably affected after the first day. The logistics of what I do probably really does make it somewhat of a necessity, but I wish there was at least provisions for comp time afterwards or at least some kind of bonus pay.

o/t but I'm surprised this random comment touched a nerve here...

I agree that almost nobody could actually sustain working 20-hr days every single day.

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."

It takes a fair bit of experience with long days to know that the feeling of doing work and doing 'stuff' pales in comparison with the productivity of doing that work well while rested and focused...

Overtime creates 'undertime', cleaning up tired mistakes takes longer than doing them, and when it comes to coding nothing is worse than wasting 15+ hours implementing something you didn't think clearly enough about to start with, and realizing it was all wasted/could have been done in 1.

> this dedicated early employee surely seemed like she worked 20+ hour days

I feel the discussion of this line is perhaps conflating "worked 20 hour days [on the rare occasion something crazy was happening]", vs "worked 20 hour days [from 0400 hours to midnight every day]". Just because someone worked some 20 hour days does not mean they worked 20 hours every day :)

When I was in startup-land, if we had a big deliverable we'd work until we couldn't work, which usually was about noon to 8am. Then everyone would go home and sleep it off, and the next day we'd try to not do that again... sometimes successfully, sometimes not.

Now that I have a "normal" job, I still occasionally do a big coding sprint of 20 hours or more, but I don't do it day after day.

In startup land, when the CEO came in at 7am and saw us frenetically coding away in the Nerd Loft, I sure hope he told everyone we all worked 20-hour days. :-)

(a) If you did even 75% of what you just described you did more than many founders do.

(b) just because one is a founder one doesn't have magically more energy than other humans.

(c) just because one is a founder doesn't magically mean one earns a bigger share of the success. An early employee shares most of the cost (time spent, fears, real danger of having no money next month, possible conflicts with the law) but doesn't get that much of a share when getting rich. Idolizing this economically unreasonable situation doesn't make it better.

(d) I'd say the best enterpreneurs enjoy the thrill. So they actually go through a lot less negative stress than their employees.

Did he edit that recently?

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

Looking at this "C" code, it's pretty clear that he was destined to be an APL-style programmer :)

Did you think finance programming industry (specifically around the KDB+/Q/K niche) fostered a "bro" culture (think wolf of wall street)? It always seemed like an interesting field, but every once in a while I hear discouraging stories. Curious about your experience with it.

One guy in London who worked in kdb was a huge arse, the tens of others I've encountered have all been lovely. It's an insane little language, though I'm only a basic user.

Also related is range-based programming. https://wiki.dlang.org/Component_programming_with_ranges

    return
        // Start by generating all dates for the given year
        datesInYear(year)
        // Group them by month
        .byMonth()
        // Group the months into horizontal rows
        .chunks(monthsPerRow)
        // Format each row
        .map!(r =>
                // By formatting each month
                r.formatMonths()
                 // Storing each month's formatting in a row buffer
                 .array()
                 // Horizontally pasting each respective month's lines together
                 .pasteBlocks(colSpacing)
                 .join("\n"))
        // Insert a blank line between each row
        .join("\n\n");

Wouldn't adding 8 lines of comments help newcomers to APL, too? This seems like a rather unfair contest.

Familiarity counts for a lot. 25 years ago when my primary language was 6502 assembly, I would have said 20 pages of assembly code look more readable than either of these.

In the long run, though, in every field I've worked in, being able to turn 20 lines of code into 20 characters has turned out to be a huge benefit. Once you familiarize yourself with the vocabulary, you can operate at a higher level. Nobody fears concise names and symbols when it's in a context they understand. I think even the most APL-phobic would admit that "a←b+c" is more readable than "assign(a,sum(b,c))".

  require 'dates general/misc/format'
  4 3$ calendar 2018

  ": 4 3$calendar 2018

The piece of code |/0(0|+)\ (all 9 characters of it) efficiently computes the maximum subarray sum[0] of an array using Kadane's algorithm. You'll either have to learn K or trust me on that.

While it is possible to break it down to multiple parts and document each, it is idiomatic to just use it and document the whole line. Or not document it at all, because experienced K people know that already. Why call a function "average" (7 chars) when an implementation (+/x)%#x is only 6? Furthermore, you know from reading it what the average of a zero length list is (NaN). Do you know what a function called "average" would return in this case?

I would say the answer to your question is that K is very different than other programming languages, and requires a different mindset. Somehow, attempts to give it a more mainstream face (e.g. article author's "Kerf" project) do not seem to take off.

[0] https://en.wikipedia.org/wiki/Maximum_subarray_problem

They're more likely offering 500k for someone who has a lot of experience managing financial tick data in a KDB environment.

The catch will be that not everyone who has read the KDB for Dummies book (OK, I made that up) will be able to walk into a stat arb hedge fund and add 500k of value.

Edit: Just saw beagle3's comment after posting mine. Some interesting points there. Still wonder about the non-tech factors though, as listed in above part of my comment.

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...?

The machines that $dayjob-1 used to build dominated the STAC-M3 for a few years (2013-2015) because we paid careful attention to how kdb liked to work, and how users liked to structure their shards. Our IO engine was built to handle that exceptionally well, so, not only did in-memory operations roar, the out of memory streaming from disk ops positively screamed on our units (and whimpered on others).

I miss those days to some degree. Was kind of fun to have a set of insanely fast boxen to work with.

[1] http://kparc.com/q4/readme.txt

OP could have phrased it better, but I presume his point was that 500KB is extremely small by modern standards. The whole executable fits comfortably in L3, so you'll probably never have a full cache miss for instructions. On the other hand, while it's cool that it's small, I'm not sure that binary size is a good proxy for performance. Instruction cache misses are rarely going to be a limiting factor.

k's performance is a combination of a lot of small things, each one independently doesn't seem to be that meaningful. And yet, the combination screams.

The main interpreter core, for example, used to be <16K code and fit entirely within the I-cache; that means bytecode dispatch was essentially never re-fetched or re-decoded to micro instructions, and all the speculative execution predictors have a super high hit rate.

When Python switched the interpreter loop from a switch to a threaded one, for example, they got ~20% speedup[0]; I wouldn't be surprised if the fitting entirely within the I-cache (which K did and Python didn't at the time) gives another 20% speedup.

[0] https://bugs.python.org/issue4753

Yes, I presume it's very fast because of a number of smart design decisions. I would guess that the relatively small on-disk size of executable is a consequence of these decisions, rather than a cause of the high speed. And as you point it, it's really the design of the core interpreter that matters.

When Python switched the interpreter loop from a switch to a threaded one, for example, they got ~20% speedup[0]; I wouldn't be surprised if the fitting entirely within the I-cache (which K did and Python didn't at the time) gives another 20% speedup.

I'm familiar with this improvement, and talk it up often. Since certain opcodes are more likely to follow other opcodes (even if they are globally rare) threaded dispatch can significantly reduce branch prediction errors. But despite not having measured the number of I-cache misses on the Python benchmarks, I'd be utterly astonished if there were enough of them to allow for a 20% speedup. My guess would be that the potential is something around 1%, but if you can prove that it's more than 10% I'd be excited to help you work on solving it.

The people who surely know what difference it makes today are Nial Dalton and Arthur Whitney.

That sounds quite plausible. The front-end of Intel processors (the parts that deal with making sure there is a queue of instructions ready to execute by the backend) has made some major advances since then. The biggest jumps were probably Nehalem in 2007, and then Sandy Bridge in 2009.

It's not that binary size no longer matters, but you almost have to go out of your way to make instruction cache misses be the tightest bottleneck on a hot path. And when it would be the bottleneck, the branch predictor and prefetch are so good that it's usually only a problem when combined with poor branch prediction, so it really only adds to the delay rather than causing it.

Lisp on the other hand is more like Emacs - naturally. Here we have a small, carefully chosen orthogonal basis of abstract operations - not domain-specific, but "theoretically-foundational" small basis. Then you have a library of macros on top of that, and ability, of course, to extend.

In other words, basis for APL is "classical" math, made executable and expanded with mechanisms required to put in one line programming constructs (logic, control flow, ordering...). It's harder to expand, but you don't often need that. Lisp is a specific branch of math, lambda calculus, which is provably enough to solve arbitrary programming problem. The "inner core" of Lisp is also hard to expand, but what you expand for your task is "the usage" of the language, which is made to be straightforwardly expandable.

To me it's hard to say what is better.