It sounds like a lot of the criticism is that employees don't get enough compensation or don't get it quickly enough. With options, the variance is too high, since even companies that raise a lot may fail, and liquidity takes a long time. Plus, if the shares are voting, founders have to give up some control. I guess the variance will always be higher than many employees would prefer (at least not considering schemes that share risk among multiple startups), but how about something like the following for mitigating the concerns people are raising?
The company commits that some percentage of each month's revenue will be immediately set aside for existing employees (to a first approximation, split equally between them). Crucially, any investment should be counted as revenue for this purpose, since early-stage startups often get major investment before major revenue. Ideally the percentage should be something big, like ten.
To encourage employees to stay, the revenue will be paid out to them over a period of years, similarly to how options take time to vest. A detail to be worked out is what to do with any money that isn't paid out because the employee leaves. (Maybe just return it to the company, though that could give companies an incentive to get rid of employees after a major funding.)
The company should be able to revise this commitment but not without a warning period of, say, half the period over which compensation is paid out to employees.
Do you have evidence of this? This web page suggests that the extra costs in the UK are not that high: https://www.crunch.co.uk/knowledge/employment/how-much-does-... In some European countries it is hard to fire workers, which could be a serious issue, but in general it is hard to believe that hiring in Western Europe is not cheaper than in the US, usually.
I work at a global (nominally European) company with some of its largest offices in Europe. When I have floated the idea of hiring in Europe instead of Seattle, because of wage costs, I have been informed that it doesn’t save much money despite the wage difference. The employee overhead in the EU is (to my USian mind) astonishingly high. The UK is not as bad as the continent, but I floated that too and was informed it all washes out the same.
In short, the apparent arbitrage opportunity doesn’t actually exist. As you would expect in any semi-liquid, semi-efficient market.
It sounds like you're complaining, but if it is really so easy, just become a founder. In a way, it is impossible for there to be an unfair distribution of wealth between people who do A and people who do B if everyone has the choice whether to do A or B.
you've missed the important point. It isn't for everybody. I specifically mentioned that it is already successful people with a lot of good connections. Thus such a startup is just the next step in the career progression. For a plain engineer, like me for example, who can't make even a CTO/VP of engineering of a small company or a Director/division Chief Architect/etc. at a BigCo creating a startup would be exactly or even worse than described by grand-grand-parent. There is a reason that early stage VCs, for example YC, invest in people, not ideas/business. One of the friends got invested with "just name the number" amount right on the spot the moment he mentioned that he got his own startup even without telling what his startup is intended to do (of course there were due diligence done by small people afterwards before things formalized on paper) Where is couple other friends, engineers more like me, who went through a very harsh interviews at those few VCs who agreed to listen to them and got, unsurprisingly, nothing, and still sitting as engineers.
>It sounds like you're complaining,
there is huge difference between recognizing reality and saying that the reality is unfair (which it just can't be by virtue of being the reality)
Starting a business isn't for everybody, but not for the reason you stated. You're making the mistake of believing the VC hype. You don't need and probably shouldn't seek funding until you can articulate a need. So suggesting that you can't start a business because you won't get funded when you don't actually have any need for funding is absurd.
Starting a business isn't for everybody because it's a lot of stressful work. You have to wake up early and stay up late laying the foundation while your friends or spouse or kids or work are vying for your attention. You have to scrape together your savings or max out a couple credit cards to actually launch your product. Once you start hiring you are responsible for putting food on other people's tables. And even once you start making money, you have no idea what you're doing pretty much every step of the way.
If you actually do want to start a business, just fucking sit down and do it. There are a ton of profitable, bootstraped SaaS companies out there. Build a product, pay for the first couple months of hosting out of pocket, bill yearly, profit. (Notice "get funded" isn't a required step.) Complaining that VCs probably won't love you is just an excuse to take the path of least resistance and stay mediocre.
OK, sorry that I misunderstood you. But for what it's worth, lots of people with no connections have bootstrapped or gotten into incubators and then gotten funded or just hustled and got funded. For instance, just yesterday I talked to a woman with no connections or track record who got seed funding for her startup, but it took her over a year of "making friends with investors". Obviously it is a lot easier if you are well connected though.
I don't know if you can really put a p-value on this result without a more specific null hypothesis, but anyway it looks like this tournament result provides extremely weak evidence that Stockfish is better than Houdini. In the round robin component, Stockfish and Houdini played two games against each other, each winning one and losing one. In the "superfinal", they had 15 draws, Stockfish won 3 games, and Houdini won 2 games.
Obviously it is a problem that social security numbers are often accepted as proof of identity, but the article seems to be saying that permanent id numbers are bad even apart from this. I don't understand what the argument is though
Hard drives need a gas because the heads use it to float over the platter. And helium is hardly that rare that it is an issue; it is used in balloons for children.
Helium used for balloons is low grade helium that has already been recovered from another process. Medical grade helium is virtually pure helium and that is in short supply. Question whether this HDD needs pure or low grade.
Yes, or a full-featured programming language. Even though I don't really know or like Ruby, I still like that Vagrant uses it for config since it is at least possible to do complex things if you need to.
It makes it impossible for the system to reason about the outputs though (due to the halting problem and a lot of other practical issues). Therefore a Vagrant setup just "does its best" to execute the given prescription to set a machine up, whereas something like Terraform will actually intelligently figure out if work needs to be done.
I don't understand why you have been downvoted. Many of these tools are very imperative and make assumptions about the starting state before they replay their updates. For a fully declarative solution, NixOS is the best I have seen.
This is a strange assertion--you run the DSL to generate, at runtime, a data model that can then be checked. Hell, I wrote a Terraform competitor that was certainly no worse at planning than Terraform is. (Still not great, because the problem is a hard one, but.)
And doing so gives you such niceties as if-statements and loops (I mean, have you seen the straight nonsense people have to pull to make a simple 'if' in HCL?) as well as a seamless way to introduce external data sources. This is why Chef remains the only part of my workflow that has not changed over the last five years (and why first Puppet and, eventually, Ansible will fall by the wayside): because, as a programming language and set of libraries, I can bring it with me by extending it at the user level without having to extend the runtime to do something. Patching the runtime means I need CM for my CM; doing it at the user level means it goes with me and plays with the base tools.
> Hell, I wrote a Terraform competitor that was certainly no worse at planning than Terraform is.
So why is Terraform so popular instead of your tool? :)
Both approaches have tradeoffs, and what you've mentioned are clearly advantages of the full-PL config style. The problem with a full-blown programming language, though, is that the flexibility makes it more difficult to reason about effects without actually running the code. If you're just using it to generate a declarative data model that then gets applied, you're still doing fully declarative management, just with extra steps.
It's not _necessarily_ a good thing to have something like if conditionals in a provisioning system either - the goal with these systems is usually to reduce uncertainty about outcomes, not multiply the # of branches you need to reason about. Ultimately I agree Terraform has issues with restrictions of HCL, but I don't think I'd say choosing a programming language instead of a purely declarative style is a no-brainer.
In favor of Ansible, I'd argue that extending it is trivial.
I tend to write simple Jinja2 filters when I need something done quickly that's not included, and it's as simple as making a specifically named directory (filter_plugins) and a python class (FilterModule). You can write your own modules pretty simply as well but there's a bit more boilerplate.
Considering that Vagrant is their most famous tool so far, they should have had a good reason to move to HCL then right? (And they do, as linked in a sibling comment.)
Wow, that is a shockingly steep dropoff! If you believe this chart, clojure will be extinct in another year. Could there be some other explanation than that clojure is really in a death spiral, like maybe Indeed has been growing faster in less developed markets or something?
I don't want a full-fledged ORM, and I sort of like SQL, but just normalizing nested objects to put them in the database and then unnormalizing them on the way out is really annoying to do in raw SQL in my experience. Every time you want to store a new object in the database, it feels like so much effort to write a bunch of boilerplate functions. Or do you have a solution to this?
I enjoy using SQL in an environment with first class hash/map/ whatevers; I don't like to build up an object. SELECT X, Y, Z from .... gets you an array of things with X, Y, and Z keys.
Turing your hash into parameters for an insert isn't going to be great fun, although perl hash slices aren't bad. I think I've seen something about named SQL variables instead of just ?, that might be usable with a hash directly?
The namedtuple is just a datastructure interface with psycopg2. For instance, you could write an arbitrary query "SELECT left.x AS cats, right.created_at FROM left JOIN right ON etc" and you'd get namedtuples with attrs `cats` and `created_at`. Similarly, you can insert namedtuples just like rows, since they are iterables, or as namedparameters with the nt._asdict() method. It's great!
"People talked about putting a telegraph on every desk in America to improve productivity. But it wouldn’t have worked. It required that people learn this whole sequence of strange incantations, Morse code, dots and dashes, to use the telegraph. It took about 40 hours to learn. The majority of people would never learn how to use it." He is probably right. And yet, how tragic. Forty hours is not that long. Imagine that the telephone hadn't been invented. Would we still today be living in a society where people went to the telegraph office to send telegraphs but basically no one could telegraph themselves?
The company commits that some percentage of each month's revenue will be immediately set aside for existing employees (to a first approximation, split equally between them). Crucially, any investment should be counted as revenue for this purpose, since early-stage startups often get major investment before major revenue. Ideally the percentage should be something big, like ten.
To encourage employees to stay, the revenue will be paid out to them over a period of years, similarly to how options take time to vest. A detail to be worked out is what to do with any money that isn't paid out because the employee leaves. (Maybe just return it to the company, though that could give companies an incentive to get rid of employees after a major funding.)
The company should be able to revise this commitment but not without a warning period of, say, half the period over which compensation is paid out to employees.