Forgot your password?
typodupeerror

Comment: Move on -- this is ordinary supply and demand... (Score 1) 574

by javabandit (#36841924) Attached to: Why Netflix Had To Raise Its Prices

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?

Comment: Re:The rake is the problem... (Score 1) 104

by javabandit (#31867890) Attached to: Revised Mass. Gambling Bill Won't Criminalize Online Poker

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.

Comment: The rake is the problem... (Score 1) 104

by javabandit (#31867572) Attached to: Revised Mass. Gambling Bill Won't Criminalize Online Poker

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.

Comment: Solve a problem that is interesting to you... (Score 1) 293

by javabandit (#31218846) Attached to: After Learning Java Syntax, What Next?

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.

Science

Why the First Cowboy To Draw Always Gets Shot 398

Posted by timothy
from the more-guns-less-crime dept.
cremeglace writes "Have you ever noticed that the first cowboy to draw his gun in a Hollywood Western is invariably the one to get shot? Nobel-winning physicist Niels Bohr did, once arranging mock duels to test the validity of this cinematic curiosity. Researchers have now confirmed that people indeed move faster if they are reacting, rather than acting first."

Comment: It sounds like a hedge answer, but "it depends"... (Score 1) 426

by javabandit (#30508778) Attached to: When Developers Work Late, Should the Manager Stay?

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.

Comment: Find the Nash Equilibrium... (Score 1) 376

by javabandit (#29251873) Attached to: Dell Says Re-Imaging HDs a Burden If Word Banned

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.

Comment: Re:Programming != Engineering... (Score 1) 141

by javabandit (#29088291) Attached to: 14-Year-Old Wins International Programming Contest

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.

Comment: Re:It is a managerial problem. You aren't motivate (Score 1) 601

by javabandit (#28490877) Attached to: How To Get Out of Developer's Block?

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.

Comment: Re:It is a managerial problem. You aren't motivate (Score 1) 601

by javabandit (#28490839) Attached to: How To Get Out of Developer's Block?

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.

Comment: It is a managerial problem. You aren't motivated. (Score 4, Interesting) 601

by javabandit (#28475175) Attached to: How To Get Out of Developer's Block?

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.

Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (10) Sorry, but that's too useful.

Working...