Netflix isn't raising prices just for the hell of it. Prices get raised for two reasons: 1) Increased upstream costs (passed on to the customer), and/or 2) Increase in demand.

The reality is, Netflix has run the numbers and they believe that the demand for their product is such that most of their customer base will be willing to pay the higher price. They'll definitely have some attrition, but that loss in revenue will surely be replaced by the increase in revenue from the customers that stay. Believe me, they've already run these numbers.

Netflix has a great product, it is served through far more mechanisms than it used to be (phones, gaming consoles, televisions, set-top boxes). As demand has increased, I'm certain their delivery costs have increased. As Netflix's demand has increased, I'm sure the entertainment industry has raised their prices to meet the demand. It isn't that big of a deal. Okay, yes, they could have done a better job of publicly positioning the price alterations, but so what?

In the end, we have a company that raised the price of it's higher demand service and lowered the price of it's lower demand service. Is this really surprising?

I wish I had mod points. GREAT post. The analogy of teaching a child to write is spot on. Excellent post.

I think you are seriously understating the rake...

Of course the rake is capped. If it weren't, nobody would play. Because the rake would be unbeatable by even the most skilled of players. Any rake is intended to maximize the house's profit while still keeping good and bad players interested in playing.

The situation you describe is a rare one. For every hand where the "rake doesn't matter", there are probably 10 or 20 hands where the rake DOES matter. Hands where you paid an ante to simply fold. Hands where you paid a rake to fold on the turn. This happens WAY more often than not.

Like you said, you can't be a winning player by winning only the small pots. I'll go further to say that you can't be a winning layer by winning medium pots. The only way you can be a winning player is to maximize the profit potential of all hands -- small, medium, and large.

I agree with you conceptually.

But the big problem is *THE RAKE*.

I am a poker player. I do believe poker to be a skill game. But the reason why poker is not a complete skill game is because of the rake. Being consistently more skilled than your opponents at poker is not enough to make you profitable. You have to be skilled enough to also overcome the rake.

Let's say that in an ideal world, with no rake, I am skilled enough to win 5 dollars per hour. After introducing the rake, I could potentially lose 10 dollars per hour... putting me at a net loss. Even though I didn't change my playing style one bit. Overcoming the rake is a hard feat given that it is at least 10%. Over the long run, that is an incredibly huge amount of money. And you pay the rake regardless of whether you win or lose.

Being better than your opponent isn't good enough. You have to be skilled at maximizing profit. This is what most people don't understand.

I know very skilled players who win a lot of hands... but are losers... because they don't know how to maximize their winning value to surpass the rake.

Brainfuck.

Niris,
I have helped teach several people how to program. What you really need to next is apply what you have learned and solve a problem. Ideally, solve a problem that you know something about. Or solve a problem where you have some subject-matter expertise.

I'm not sure if you actually like being a security guard or not. Maybe you do. Maybe you don't. But you are probably familiar with the subject matter. Write a program that will solve a problem related to the subject matter. Using problems that are in operations research are really good ones. For example, a problem I might give you:

Security Scheduling Program for a Business

Purpose
The program should create the optimum shift schedule for a week -- guarding a business 24 hours a day.

Requirements
1) The program must allow for the user to input the number of available security guards.
2) The program must print out the shifts for each security guard.
3) No shift schedule can be over 8 hours long.
4) No security guard can work more than four days in a row.
5) All guards must be used in the schedule.
6) Each guard must have a 30 minute lunch and two 15 minute breaks each day.
7) During a break or lunch period, another guard must cover the watch.
8) If any of the constraints cannot be met -- given the number of guards available -- then the program should indicate that more guards are needed.

This problem is just an example of an operations research problem -- finding optimality. If you don't like this problem, you can make up another one. Or do a search on the internet. The idea is that you find a problem to solve that you: 1) know something about and/or 2) have some interest in.

When first learning to program, the key isn't the language you learn. The key is proving that you can solve a real world problem using programming. Good luck to you.

Interesting. I've never heard the converse question... "When the manager comes in early, should the developers come in early?" But that's another topic...

The real question is "why would the manager stay?" Here are some possible -- one or more -- reasons:

1) Because the manager does not trust that the job will get done... "trust but verify".

2) Because the manager feels like it will gain him/her credibility with the team.

3) Because the manager feels guilty and wants to share in the pain.

4) Because the manager feels like it will give the bosses peace of mind during hard times.

I can't think of any other reasons. But it is important to say that usually, if a manager wants to stick around, it is for noble reasons.

My advice to developers, is that if reasons #2, #3, or #4 are any of the motivations for their boss to stick around... cut them a break. Even if #1 is also a reason.

The possessive form of "yall" is "yall's". Here is an example sentence.

"I saw the car outside and figured it was yall's."

"Yall's" is a contraction of Yours (all of yours).

In the northeast, a variation is "youze guys'es". In the deep south, another variation is "your'n".

Gotta love English.

One of the earlier posts talked about the difficulties around "too big to fail" or "to big to succeed". To me, this is where the concept of finding a Nash Equilibrium is critical.

To resolve this situation optimally, a means to an end must be found where all of the affected parties benefit the greatest as a whole. You can't simply issue a patent judgment and say "have a nice day, you have X days to comply". That might benefit i4i, but it really hurts a lot of other stakeholders in the system -- including consumers (who do you think will bear the cost of that judgment?). Like it or not, by the law, i4i deserves something for the infringement (if the court finds the patent valid).

However, this is where our legal system in the free market breaks down. You've got to make sure you can come to judgments where the market isn't overly harmed, but everyone gets a taste of what they deserve.

Your analogy is off. Let me restate it.

You don't need to have knowledge of engineering to engineer a bridge.

Likewise...

You don't need to have knowledge of programming to write a computer program.

Stop getting the wires crossed. Engineering != Programming. The two are completely orthogonal.

This is so well said.

You are exactly right. It does NOT matter at all who's fault it is.

The reality is, the manager has to address any kind of motivational issues. Regardless of the source of de-motivation. De-motivation kills individual productivity, team productivity, and can even sour an entire organization.

Uh, exactly. If you have an employer that uses terms like "self-motivated", "works smarter and not harder", "ability to work without direction"... et cetera.... RUN (don't walk) for the hills.

These are companies who have incompetent managers who delegate their own management responsibility to their workers.

Managers are supposed to actually serve a purpose.

I'd argue that you don't want to work for such a boss, then.

As a director of a software development organization, I won't be popular for saying this. But... it is your boss' fault. Not yours.

You simply aren't motivated. I want to slap the person somewhere in another post who said... "motivation comes from within". It *rarely* comes from within.

When one of my managers or peers comes to me and complains about "unfocused" or "unmotivated" employees, I tell them to get off their collective ass and motivate their team or their employee. Psychologically, as an employee, you should feel driven by your surroundings to achieve a goal. That feeling should be driven by your team, your boss, your organization.

Being "self-motivated" is the single, biggest path to burnout in existence. Don't even begin to blame yourself.

Here is what I would recommend. Go to your manager. Tell your manager that you simply aren't feeling very motivated about the work you are doing. Have an open and honest conversation about it. You might be surprised. Your boss might actually bring some out some of the motivational mojo that you need. If your boss doesn't come through for you, then think about going to another organization.

But don't quit programming. You probably love it and you probably are pretty decent at it. You just need to be motivated, that's all.