reeses

Fully agree. There are so many people who can't do the basic Excel work even to generate the information on the chart who are capable of starting a business. (I include in this every restaurant ever opened, modulo statistical outliers.)

That's not a problem with the chart. That's a problem with starting a business.

You don't have to grow along a fixed axis, whether that be # of users, # of widgets, etc. You just have to average the growth in income.

I had a similar initial reaction to the chart because I stick to R&D-driven startups that will run at $0/week for as long as it takes. However, pushing the stop-energy out of my head and running with it is a good gut check for viability on breaking even given assumptions about expenses vs income over time.

The output isn't "we will grow at an annualized 360% forever, yielding foo," it's "we only need to kick in $x to have a good shot at getting to B/E."

It's that race to the bottom they mention. As they mention, they're in a relatively expensive labor market (although, as I sit here in the Bay Area, they have me thinking about a recruiting run to the UK).

They're paying for the market validation that can be eaten up by a company in a less expensive market to produce a knock-off version (or, more likely, ten knockoff versions) for that USD9.99 and enjoy boatloads of sales.

This pattern sets an expectation that, because it can run on your phone, it should cost significantly less than desktop software, even if it is more useful than a desktop version.

I'm a big fan of leverage and my father taught me the ROI model of tool selection from an early age, for everything from shoes to calculators. Unless it's completely unaffordable, the cost of a tool is irrelevant outside the context of its ability to amplify your thought and your output.

This works out when discussed in the context of "competitive compensation" in your market. While your manager may not care that you want to live in a USD5,000/mo apartment, she may care that companies x, y, and z are paying programmer analyst IIIs USD5k/mo more than she's paying you.

I almost never give COLA raises, but I will raise based on performance and desire to remove money as a reason to look for another job. It's the easiest way to overcome inside recruiting and it doesn't take much thought, so I can spend my time with other retention techniques.

The concepts are the important part. You can get a long way with a nasty interpreter to see if your concepts play out. :-)

If it's a "deep" concept, I'd pick a simple representation that I can implement without much cognitive overhead (a basic Lispish or Forthish stacks-and-registers syntax is usually something I can spin up in a few minutes) and then start layering my concepts in.

Some of the things you think will be awesome will end up just being wrong or inefficient, but you'll cut the loop down really quickly.

It makes it really easy to compare your hypotheses. If you want to factor them into a more conventional syntax model (c, python, haskell, etc.) you can always learn that along the way.

In fact, if you want to get really simple about it, write the code you would want to write and hand interpret it. You can get really far with simple pre-processors written in whatever text or AST manipulation environment with which you feel comfortable. (I'm notorious for being lazy and writing 50-pass compilers, just writing 10 to 200 line features and chaining them, all in a ghetto RPN.)

Well timed after prime music imports your itunes library.

no hairy workarounds to replace an iphone in your mac ecosystem, which is something google has not achieved.

(yes, other than apps, but that will follow)

To make a comparison for anyone who hasn't programmed FPGAs (especially on the path to etching silicon), placement is extraordinarily important. Not only can (will) you make a highly non-optimal layout, FPGAs are not orthogonal. You'll spend a lot of time trying to route the bits that need to talk to each other via direct connection as much as possible instead of going through a gp line or worse.

Depending on the make and model of FPGA, you will have "large" areas that you either can't or don't want to plop logic.

You can have a pretty netlist that validates and simulates correctly (although you'll eventually end up dealing with Cadence, who seem to have the right hand side of the bugs per line of code curve locked up) but still takes weeks or months of that inline ASM work to make it competitive with a rack of Xeons. The edit/compile/debug cycle is not quick by any means past a trivial number of gates.

Dealing with that junk is why IP blocks are so attractive, but you end up on the road to structured ASICs and that just leads to misery.

Former LVMH director here.

The Chinese luxury market is insane and has been popping for the past ~10 years. It's not just LV (and child companies) but across the board, with Richemont and others doing quite well. LV just happens to be very good at a) encouraging mobility in its staff so that the "experience" is consistent b) grabbing a great spot of real estate and building monstrous stores in which you could fit an Apple store or ten and c) selling product that advertises the financial status of its owner.

I'm sure you could run a similar metric with Rolex or other "conspicuous consumption" brands.

And no, it's not the poor kids sewing Nikes who are buying the top kit. The average purchasing power is very low.

In general, of course, it depends.

In the case I mentioned above, we left the candidate site immediately, arranged earlier flights, and flew back to Seattle. There may have been exec communication but I was just the technical DD guy at the time. But I never heard from them again.

Had the code been stellar, we may have given them time to sort it out so that the package was clean.

A fun one is finding loans from friends and family that involved any sort of strings, whether convertible or interest that has accrued because Aunt Bertha forgot about the $50k she gave you.

It's easy to forget these loans from the early days, especially if there were 20 people who gave the founder little bits of money, especially if it was before he or she set up the corp accounts, etc.

Other than that, one of the worst I've knocked down uncovered a lack of assignment of IP (an early rich-media MUA) from a contractor that effectively meant the candidate company had zero value. "Who's Bob Smith of Bob Smith, Inc.? Can I talk to him about this shitty code? Oh, he owns it..."

Some commonly involve artificially boosting turnover by trying to be clever and using in-house developers as a separate concern, billing or paying through companies owned by family members. Sometimes this sort of setup is kosher (you want to smooth out and isolate capex and a friend has office space and a couple devs, or there's an overseas component, or whatever) but if money is moving between them in a semi-closed ecosystem, it's often a bad sign.

Usually, as stated, it's sloppy stuff, but sometimes you get a real weasel.

As for being a founder, having an accountant/CFO makes a huge difference. The first contract CFO I hired was a revelation. The commitment was low and the upside was huge. We were too small for a FT CFO and I was a babe in the woods and didn't even realize these people existed.

The most commonly-heard excuse is that programmers do not like all the parens.

I would assert, rather, that we have 60 years of compiler and runtime experience, both academic and industrial.

Consequently, I would propose that there is no excuse for a public release of a commercial programming environment to be so slow unless it introduces significant novelty sufficient to render the preceding work inapplicable.

It's also more pronounceable and appetizing, like the chilean seabass.

Don't worry, it will turn out to be, in fact, an aardvark. Please see the "panda bear is a racoon, oops, no, he's a bear," controversy.

The fundamental problem is that Wikipedia's editorial policies great drag on the memory hole.