I wish I had mod points. Your post is the absolutely most concise and insightful in this entire thread. It is also completely correct. This Swedish scientist is the equivalent of one of those scientists who says that climate change isn't happening.

I also agree with one of the posters who said that this scientist having a model is a good thing -- even if it is wrong. A model lets the rest of the community put it to the test, change it, and improve it. There have been many predictive models which estimate the number of earth-like planets out there. I haven't seen a model which says that earth-like planets absolutely should not exist at all... and that earth itself is an infinitesimal anomaly.

If anything, the model should provide a nice contrast to test opposing models. Definitely a good thing.

... I swear. Lean, SCRUM, XP, Agile, Waterfall, Kanban, Scrumban, TDD, BDD, Pair Programming, Code Review, User Stories... etc... etc... etc.

How about just be a responsible craftsman, understand the customer's requirements and needs, and implement your solution responsibly and with integrity? Whatever that means. If you need to pull someone in, then do it. If you don't, then don't. Christ, how complicated is this? It's one thing to be a junior developer and having to learn things. Fine. But an experienced software developer should not require constant canoodling to get their job done responsibly, with integrity, and with good quality. Is it really that hard?

I'm from a pretty old-school programming upbringing -- back when you were a "Programmer" or "Analyst" or "Programmer/Analyst". I'll tell you in those days... if a programmer demanded this kind of ridiculous hand-holding, canoodling, and process-implementation to get their job done... they would be fired. Plain and simple. This industry has become awash with process and tool zealots... while knowing the customer's needs be damned.

The movie was better than the book. This guy is like the second-coming of Michael Crichton -- on steroids. The level of detailed minutia he creates is entertaining at first but quickly becomes tiresome. The only reason "The Martian" is remotely decent as a book is because the story he thought up was actually good. The microscope level of detail was absolutely unnecessary.

I think the guy actually has a decent ability to create and tell a story. But he doesn't need to prove the feasibility of his stories to the audience. It's fine to suspend belief sometimes. Especially in science fiction, right?

I just hope the story he tells in this new book is as good as it was in his last one. Otherwise, the book is going to be horrible.

My first programming job was working in a food manufacturing company as a junior programmer. There was a team of programmer/analysts. We knew the business of food manufacturing. We understood our own business. We understood the day-to-day jobs of employees who had to use our software. We tested our own code. There was no formal "QA" for the software. Part of the job was testing the code. If you didn't test your code, repeatedly had failures, your ass was fired. It's as simple as that.

Most pieces of software do not require a separate formal team to test it. All it requires are programmers who understand what they are doing, what business they are in, and how their software is going to be used. What the hell has happened to this business?

Woodworkers have more capability, domain understanding, and work ethic than programmers these days. A good woodworker tests their angles for trueness. They design their cut sheets to maximize wood usage and eliminate scrap waste. They test their joints for racking. They will sand every edge of a piece to make sure no blood can ever be drawn. They will make sure that every plane is perfectly level.

If you want to be a good programmer, get off your lazy ass and make an effort to understand your customer and the business you are developing software for. Test your own code and be intellectually honest with yourself while you do. If you need to automate, fine, but automate where it makes sense. Test things that make sense. If you do that, most of your code will be free of critical bugs.

If this was Yahoo's goal, then good for them.

Any subject in general could be extremely fun to learn if the educational pace was more easy going. THAT is the problem.

We are a generally long-lived species these days. Why in the hell do we need to compress several times the knowledge of 60 years ago into the same time span they had 60 years ago? It makes no sense to me. High school teenagers in AP (advanced placement) classes are competing so hard that they need to be up until 1am or 2am in the morning three or four times a week just to keep up with the homework. 4 to 5 hours of sleep per night. Terrible sleeping and eating habits. No physical activity. It has gotten RIDICULOUS. I don't know what in the hell we think we're teaching kids these days, but we're sure not teaching them that learning is fun.

There has to be a breaking point soon. Kids should be able to enjoy being kids. Kids should also feel like they don't have to pressured to have half of their college credits finished by the time they graduate high school. They also shouldn't feel like they should need to get their PhD by the time they are 21.

What are we doing to these kids?

At its inception, the Agile manifesto was simple. Four priority/value statements and then a list of simple principles. The goal? Merely to say that delivering value to the customer, collaborating with customers, frequent delivery and feedback, and team empowerment are the way to deliver software. Focus on delivering value. Don't focus on delivering things that aren't valuable. Very simple.

Once Agile values started to become embraced and a couple of new development processes came along (SCRUM, etc), you all of a sudden had a bunch of consulting companies and community meetups appear that all but destroyed the perception of Agile. For these companies and community groups, it's all about the process. They will teach you how to "do agile". They will provide you with bodies/contractors who can "do agile". They will sell you certifications which show you "do agile". They will sell you seminars and training on how to "do agile". They will sell you software which "does agile". Agile has went from a basic set of values to becoming a fundamentalist religion.

So my statement to "Agile Process Improvement" firms is this: You are all just scammers and profiteers. You are software development Pharisees. It is amazing that you focus on profiting from creating processes, enforcing processes, teaching processes, and writing process software... for a methodology where the first value statement is "Individuals and interactions over processes and tools". Why don't you guys teach REAL agile? Why don't you teach companies how to better define value and deliver it to customers instead of selling new processes, fundamentalism, and bodies?

For the rest of you, if you want to be "Agile". Read the Agile manifesto. Create your own process that suits your team and your business. Work continuously with your customers to understand what is valuable to them. Deliver good value to them often and get their feedback. Allow your team to learn and grow and understand the needs of the customer. THAT is Agile. THAT is all you need to do.

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.