stevenameyer

Computer science ultimately boils down to the study of how to efficiently compute a solution to a given problem.

From here the field has a bunch of different areas that investigate aspects of this including things such as how difficult a problem is to solve, what kind of hardware is required to be able to compute a solution, the efficiency of an algorithm to solve the problem, data structures which make solving the problem more efficient, etc.

But ultimately the field is the study of efficiently in computing a solution to problems.

They need to keep the number of companies to a reasonable amount in order to give the companies that do get significant value out of the program. So until they manage to figure out a way to scale the YC program to be able to accommodate more companies (which I'm not necessarily sure is possible) some good companies that could have been very good fits with YC will be passed on.

They will inevitably miss some awesome companies as well as select some companies which wont amount to much. This is just part of doing something that is speculative. But they need to limit the number of companies in order to actually help the ones they do accept.

YC is a good program that certainly helps a lot of companies, but by no means is it the be all end all. There are many very successful startups that didn't go through YC and many not very successful startups that do go through YC. So if a company doesn't get into YC it's not the end of the world. There are plenty of paths to success that don't go through YC.

Hardware has functionality in and of itself, for example a flop-flop is a circuit that can store a voltage (ie. a one for an arbitrary voltage or a zero for a different arbitrary voltage), an adder is a circuit which adds to sets of values etc.

In a computer there are a bunch of these different low level circuitry components which when combined in different ways can be used to produce any functionality. There is a certain amount of the circuitry which is unusable by the programmer which is reserved to know where all of these components are and how to connect one component to another. You can think of this as a program that is built into the hardware which knows how to install and run other programs.

Basically when you write code, there is a program or multiple programs which transforms the words you write into a string of binary numbers which tells the control circuitry how to arrange the free components to get the desired behavior.

As a fellow young professional, in my opinion the only way to improve decision making is to increase the amount of information and experience that you have to draw from to make the decision. This can be first hand information and experience or second hand.

So work on gathering information before making a decision, surround yourself with people with more experience and/or different areas of expertise and take every opportunity to try and absorb their second hand experience that you can, and finally make decisions and learn from them. The more you have to draw from the more likely that you will be able to make the best decision.

I would be interested to see how prevalent this is at top institutions around the world. I can be fairly confident that my program does not do this as my class is very far from diverse. (the large majority of students being asian males)

I have heard of a little bit of black magic that is involved in the acceptance process but in order to accept people who are more likely to succeed in the program. But race definitely does not come into play.

As much as I have a personal dislike for Jobs, I think this is advice that a lot of people fail to see value in. Having people who care standing up for their opinion and taking whatever comes out on top will often lead to the best product.

People need to stop avoiding friction between opinions and ideas and instead embrace it. That's how great things come about.

The one thing I would give as a benefit to setting a deadline is that it can help prevent feature creep for a specific version.[0] The amount of times that I have had a manager come to me just prior to a version being ready to ship and ask me to squeeze a new feature into this release is staggering. This is where being able to push back with "not if we are going to hit the release date." really helps.

Now ideally you are able to agree on what to put in each release and stick to it, but a lot of work places are not ideal and feature creep can be a huge issue which can easily be addressed by implementing a release schedule and sticking to it (for the most part).

[0]This is more applicable to areas such as mobile where it is unrealistic to ship releases every week.

I'm not disagreeing with the fact that taking a different approach to a mobile OS could be successful, simply that there is a certain expectation that people have about mobile and if you are not following that then you will have to convince people that this way is better.

Is this possible? of course, if its better it will win out. But this is definitely a hurdle that needs to be over come. Convincing people that they way they are use to is worse then an alternative is often a difficult task, especially for a device that pretty much never leaves someone's side. I even notice that people often have a lot of difficulty switching between Android and iOS if they have used one for a significant period of time, and most of the differences between these two platforms are fairly minimal.