It appears tHooft's theory has determinism in common with Bohmian theory, but differs in that it proposes hidden local variables as not violating Bell's inequalities, rather than a wave equation which has non-local dependencies?
TL;DR - this is explained by:
1. Sociopathic corporate philosophies
2. Risk-mitigation against lack of competence and/or integrity of the parties involved in the transaction (HR, low-level manager, employee).
My initial response to this was cynical and pithy: if corporations were people, they would be sociopaths (in far larger proportions than the actual human population). In this case, they seem to have zero regard for fairness, but rather only how they can use others to maximize the benefit to themselves.
Upon further reflection though, it is more complicated, and there are many factors and actors in play.
There is a misguided but universally accepted belief that corporations' supreme obligation is to maximize shareholder returns, and that it would be immoral to NOT take any lawful action that would increase profits. The net effect of this is equivalent to having a single sociopathic business owner who will do anything to maximize their own profits without regard for fairness except when a deficit of fairness begins to negatively impact this end. The effects of this philosophy impact decision makers directly and indirectly throughout the organization, and this phenomenon is one of the results. Being fair or rational in treatment of employees is not mandatory or even the primary driver of decisions.
One way this manifests itself is that management justifies its large salaries and bonuses by minimizing costs, of which employees are often a significant portion. Thus, incentive structures throughout the organization will likely reflect this. It doesn't hurt that executives are likely to be sociopaths to some degree, and this just helps them justify their natural inclinations.
Even in a hypothetical case where all levels of decision makers in a company are benevolent and fair minded, there still remains the difficult problem of determining fair salaries for each employee. Developers aren't truly fungible, but they are difficult to value (especially by those further removed from that role). So, in a sense it is rational to treat them as fungible unless you have a reliably accurate means of differentiating. If an HR person is 100% certain they don't know what is fair outside of averages, it would be a rational decision to let an employee's market price be determined by a public auction process among other companies (aka job hopping), rather than granting a request for a large raise outside the normal range.
Of course, this end could be mostly satisfied merely by matching an offer made by another company (aka job shopping) without requiring the employee to leave and return later. However, that is a very low-friction and low-risk proposition for the employee compared to an actual job hop, so inevitably would see much larger participation if accommodated universally. As HR has no way of knowing what the market rate is for all of its employees, it would also have no way of knowing how much this policy would increase the company's costs if it implemented it and every employee utilized it. If a worst-case scenario would cause substantial destruction profits, this would be a high-risk change to implement, and likely would need other coordinated actions to ensure acceptable long-term profitability and approval from shareholders.
Additionally, there is the risk that the employee had no desire to actually accept the other offer, or even colluded to be given a non-genuine offer (from a friend, for instance) under the condition they had zero intention of accepting the offer. Only once the employee terminates employment and spends a substantial amount of time at another company have they proven the offer was genuine, and that their previous salary truly wasn't sufficient to keep them. That is, without a high level of trust in the employee regarding the offer. It also helps if a trusted party (manager, co-workers, etc) confirms their exceptional value to the company, both in justifying the raise and in indicating there won't be cascading impacts upon the rest of employee salaries.
Diverting from this policy requires additional risk and lower profits, mitigated only by a high degree of integrity and competency in all involved in evaluating fair compensation and the long term cost/benefit of granting a raise vs. hiring someone else. The larger the organization, the less likely it would be a rational decision for upper management to assume this to be the norm. Integrity and competency are impossible to objectively quantify or measure, so for those who manage by metrics, I can see how this would pose a problem.
Checked out the demo, looks great! I am sorry it didn't work out like you hoped, but I'm glad you landed in a nice spot.
Would you mind sharing your lessons learned? Such as, why you think it "failed" to take off like you hoped? What were your plans/expectations vs what actually happened? Any critical mistakes or major external factors which impeded success? Anything you would have done differently?
I second this, would love to learn what you thought worked and what didn't. Your product was beautiful and useful, was it mostly about market fit, business model or something unexpected.
Thank you for the clarification Paul (and Adrian for your perspective). May I ask if there is a bias against applicants who have spent a significant amount of time on the product (say, a year or more) but haven't built a user base?
For example, if the choice was made to put in more effort up front on iterating and validating the product design rather than trying to implement a MVP and try to start building the user base early? Is it easy for you conceive of situations where this is the best, or at least sufficiently logical, choice? Or is that likely a deal breaker?
It depends on what the company is building. Some things take a long time to launch. With others it's a bad sign if the company takes more than a month or two to launch.
Thank you Paul, I appreciate you taking the time to respond. Your answer is helpful in that now I understand your general perspective, which addresses my question.
My problem is that I purposefully tried to ask a general question with broad applicability, because I think that is respectful of your time and the community. However, what remains unclear are the specifics of how my product and company would be assessed. The devil is always in the details. I don't think it is fair to ask for such personal advice from you, but perhaps you have some advice as to the best way to go about getting good feedback on my company and product? Short of getting into YC, I mean. Should I take Adrian up on his offer if he is still willing (for my own edification, not for this round of applications)? Are there other good ways you know of?
And yes, at some point I will just launch on my own if necessary, but I continue to believe the cost/benefit trade off of getting counsel from experienced mentors is very favorable. So, I want to make sure I am doing everything I can to be successful and in the meantime to be able to demonstrate evidence that I am worth the time/effort/capital of those who are looking for those with potential.
Since YC alumni are now doing the preliminary application reviews, is there a process to avoid an unintentional conflict of interest (ie, an alumnus viewing a potential competitor's application)? Perhaps prescreening by YC staff and assignment to specific alumni for review?
Please forgive me if the question seems redundant. I am reluctant to even ask as YC has a reputation of integrity. However, the mantra that "ideas are worthless" causes concern that perhaps precautions might not be taken to avoid such a scenario (because by implication, it would seem this could be viewed as a non-event). My apologies if I have misunderstood the views of YC on the matter.
We tell the alumni explicitly that they're obliged not to disclose what they see in applications, and that if they see an application that competes with them they should click on the "skip" button provided for this purpose. We can't watch over their shoulder as they do it, but we're careful about which alumni we pick as reviewers, and there has never been any problem so far.
From what I have been told by YC alum the assignment process for application review is randomized, meaning it is hypothetically possible that a direct competitor may read your application.
As a counter point, if you want to raise external funding, you probably should accept the fact you will likely have to share your idea without protection - as its unlikely any VC will sign an NDA, and you have no idea who they will push your pitch deck to in order to get a 2nd opinion.
Pepsi, however, offers "Throwback" versions of Pepsi and Mountain Dew which use cane sugar instead of HFCS, and seem to be commonly available at many normal grocery stores in 12-packs for the same price as the regular ones. I prefer it to regular Coke, though Mexican Coke is a little better (but also much more expensive).
I visited the World of Coke in Atlanta a couple years ago, and at the end of the tour they had machines dispensing samples of all kinds of their international sodas. I was disappointed to find that Mexican coke was not offered, although in retrospect, not surprising as they probably would prefer not to advertise how much better cane sugar Coke is.
I agree that Cassandra CAN be used for basically everything a RDBMS can, but to claim it can be used just as easily is a stretch (based on my experience migrating from PostgreSQL to Cassandra). It lacks many administration tools, and for data with complex, non-hierarchical relationships, data modeling is more complicated and you must do any joins yourself. Sure you can get major performance and scalability gains if you use it correctly, but you also give up being fully ACID.
As a developer, using C for all data in any complex application is going to be harder up front than using a RDBMS. From what I have heard and learned about C, though, it is less painful to use C for a highly performant/scalable database than trying to scale most or all RDBMSs. From what I have read, Mongo is also hard to scale.
AI + substantial assumptions = almost free labour force
You are assuming:
- cost of materials and the energy consumed by an AI manual laborer or scientist would be negligible compared to a human for every n beneficial position, including the last position at the margin. That is, we would run out of resources to make AI scientists and laborers before we ran out of uses for scientists and laborers
- Zero R&D costs to build that AI, or that they have been sufficiently recooped so that the end-user cost is negligible
- AI can be equivalent (or superior) in every way to a human being in every possible task
- An AI scientist would be able to perform every function as well as a human, and yet would not demand an income, equal rights, etc. Essentially, disabling those parts of the human psyche would have no limiting effects on the capabilities of the AI system in any useful task. That seems unlikely, and at least is impossible to know at this point.
And then, if your assumptions hold, then given appropriate population controls so resource contention isn't an issue, I imagine it would be a pretty remarkable upgrade in quality of life for everyone across the board. In which case, the sentiment is not that no one is exempt, but that no one is left out.
