1,056 karma · joined January 28, 2011
This attitudinal difference is most acute when the driver drives for both: they generally like Lyft better for how the company treats them but are also on Uber to ensure steadier business.
Also, one thing people absolutely do not understand about Box (or they underestimate this aspect of Box's business): they are an 1) enterprise 2) SaaS company that 3) targets slow-moving, low-churn departments. Look, for example, this analysis by SaaStr: http://www.saastr.com/2014/12/18/saastr-on-techcrunch-box-wi...
Also, in my experience, what sets the smartest people apart from "just" smart people is their ability to retain the how: not only do they have broad and deep models, but they also know how these models are built and can adapt them quickly as they acquire new information.
Most people need to run a disassembler of their compiled thoughts, and after a certain point in life, their binaries are so bloated that they can't decompile them at all.
pgbovine nailed it. I learned this lesson from mathematics (I studied math in college and theoretical CS in grad school): the best math teachers always introduced a new concept/idea using a "toy" example. A toy example may not have the full generality of the overarching theory/idea, but it has all the essence without any of the abstract inaccessibility.
I try to apply the same lesson when I teach people data analysis: I learned (through my time as a quant on Wall Street) that a lot of people feel very comfortable in Excel but find other data analysis tools (SQL/R/Python) too abstract/scary. So, instead of telling them "Oh, you should use Pandas with Postgresql" or "that stuff can be done better using R", I show them what the equivalent operation looks like in Excel first, then show them how they can be done in SQL/R/Python (See, for example, this: http://blog.treasuredata.com/2014/12/05/learn-sql-by-calcula...)
And yea, it's too soon to tell. Software & software business are evolving rapidly under our feet. I am curious to see what will happen next.
This is something I ask myself a lot (as someone focused 100% on open source at a company whose core business is not open source support).
For all the hype that open source has enjoyed as a business model, it is much smaller/untested/too early to tell compared to the proprietary model. The most financially successful open source company to date is Red Hat, which, at 10B USD+, is a great success by anyone's measure. But that's the best any open source pure play company has done. If you look in the other direction, Oracle is worth 180B USD, and even a fledgling BI company like Tableau is in the high single digit billion.
As much as I'd like open source companies to be an Oracle-grade blockbuster success, the brief story is not exactly promising.
What makes it awkward is that you can't say this stuff and hope to convince the critically important group of people for open source software/companies: user communities.
Users care a lot about their software and community around it growing and improving, but they won't be convinced by the needs of venture-backed, growth-oriented corporate strategy. (I am not saying this is good or bad but stating the fact).
- company: www.treasuredata.com
- job: Developer marketing for www.fluentd.org
- why: Fluentd is gaining traction: it is part of Kubernetes (Docker orchestration software), used at hundreds (at least) of companies.
- how: Email me at kiyoto@treasure-data.com with the following information
1. Samples of your best writing/blog.
2. Your GitHub account if you are a programmer (this is neither necessary nor sufficient)
3. Tell me something that you marketed really well to the developers in the past: how you marketed, why it became popular, etc. It does not have to be software!It really vexes me to see how a lot of distributed systems projects claim to support "exactly once", and it makes me happy to see a grounded, intelligent summary like this one.
Not always the case, especially if you have a large professional server component to your software (& sometimes SaaS). See, for example, Workday > http://www.sec.gov/Archives/edgar/data/1327811/0001193125123...
Gross margin is not the sole metric. However, high gross margin is not a given even at software companies.
Look no further than Tableau's valuation. The "traditional" BI market is still huge, and if anything, direct SQL-level access benefits a small portion of the entire BI user universe.
I agree, and that's unfortunate because that's not the most differentiating thing about array languages. As you point out, it is the semantics: some of it appears in other functional languages (like doing away without loop constructions) but some are unique to array languages (like using various properties of matrix/vector operations to express certain computations concisely).
I am a big believer of linear algebra as a great tool of thought for computation that most people have little to no knowledge of, and the APL family (and actually, Excel) brings home this point.
EDIT: And I definitely speak from my experience. I was a professional q programmer for two years, and I came to realize what makes q difficult for many people is not just its cryptic notation but also the general lack of understanding of linear algebra/matrix operations.
No, I am not kidding. Excel, or spreadsheets in general, is a great, readily available environment to learn how to think like an APL programmer. Sure, the notations are not there, and you will be copy-and-pasting cell references as opposed to typing in obscure operators, but the essential idea is there: how to think about computation in a geometrical/tabular way.
Also, I totally agree with your comment on Japan. I think start-ups have a very tough time sustainably generating value through innovation in Japan. Taking the national psyche and tendency for risk aversion into consideration, most likely, it needs to come from either big companies or government programs (like in the 60s-80s).
We are looking for two positions:
1. LOCAL Product manager.
2. REMOTE/LOCAL Open source engineer: I lead the open source team at Treasure Data where we primarily work on Fluentd (www.fluentd.org). In particular, we are looking for someone who knows systems programming/middleware well. Familiarity with Go or Ruby a plus.
Email me at kiyoto@treasure-data.com. For the product manager role, please send me 1) your resume 2) a paragraph describing why a company needs a product manager.
For the open source engineer role, please send me your GitHub handle.
One thing that we should all consider is that, first and foremost, this lecture was for the Stanford students in the room whose attention span ranges anywhere from 0 and 15 seconds on the topic of enterprise software. I am pretty sure the required reading is a twisted, self-deprecating joke, and the theme song is to get the audience's attention.
Based on the table of contents, a more accurate title would be "Modern Foundations of Theoretical Computer Science with an Eye Towards Machine Learning", and even that is given a disproportionately large weight on machine learning.
As I commented above, the syntax is horrible. But I still think it is an effective tool for certain problems.
Yea, I know all about the training and First Derivative. My employer also hired them.
In their defense, every First Derivative KDB+ consultant that I worked with was very sharp and an excellent teacher. They really knew their stuff, and First Derivative is no small part of what has made KDB+ so successful. However, even with their excellent pedagogy, most of my co-workers were totally lost/weren't willing to apply themselves to learn q/kdb+ well.
Here is another way to think about it: many people can't ever get their heads around certain conceptually difficult topics, say, measure theory or quantum physics. I don't think kdb+ is nearly as hard, but it seemed that way looking at my peers who were no slowpokes.
1. kdb+ was (and maybe is) a good solution to the problem that we had: doing complex data manipulation/simple statistical calculations against billions of rows of time series data. Hadoop is the term du jour for data processing, but truth of the matter is that finance doesn't have really huge data. At best, it's a couple of terabytes, and most of the time, you are working with a small subset of it. Running KDB+ on a beefy server or two would usually do the job (rather well).
2. Maybe because I studied math, but I find k/q's vectorial/functional sematics appealing. I think the syntax is horrible, but the semantics is very neat.
3. Finally, because it helped me keep my job. It was rather amazing to me that all these Ph.D. statisticians that I worked with couldn't bring themselves to learn kdb+ effectively. Apparently this stuff can be very hard for even the smartest people (or maybe they thought it was such a niche skill with a low ROI).
No shit. I used to work as a quant, and while I was an okay quant and mediocre trader at best, I survived for three years in the industry because of my kdb+ proficiency: the firm I was at spent a couple of million dollars on kdb+ only to find out that most people could not wrap their heads around kdb+ let alone debug it effectively.
My (former) colleagues were definitely smart people. In many ways, they were way smarter than myself. But I somehow could get a much better handle of kdb+'s idiosyncrasies, and my ability to stare at dense k/q code (usually no more than a dozen lines) and figure out what's wrong with it earned me the reputation as the "q guy" - and some level of job security.
The firm eventually phased out kdb+ completely after my boss and I left (the two proponents of kdb+).
I totally agree. Most of useful "big data" is time-series data, and they aren't all that huge compared to images/videos/etc.
That being said, I think the reason to adopt something like Hadoop/MPP engines is not for storage but ease of querying: while Postgres can handle storing terabytes of data, joining two terabyte-scale tables can get a little iffy. This gets even more complex if you start packing data into array columns for space efficiency.
There is an argument to be made that historical/archival data aren't all that useful and thus do not need to be analyzed: that was definitely my assumption coming from finance. However, I've been surprised how far back some of our customers at Treasure Data go to mine insights from data.