It's urea, not urine. Urine does contain urea, but so do many glues, foams, insulation products, etc.

They're not the same thing.

Two thoughts: First, I agree that the baby was some sort of strange mercy killing. It's the only interpretation that matches up with the various sixes that appear and develop through the story.

Second, has anybody squawking about this every read Grimm's fairy tales? Anyone? Bueller?

In classical European fairy tales, kids are on the menu for chrissakes (and apparently only tasty if cooked alive)!

My niece (10) saw the baby-killing scene in BSG and her dad and I made a great "teaching moment" about it. Niece was a little shocked, but did not have a breakdown or other indication of serious problems.

References? Not being argumentative here, I'm actually interested in being able to forward your numbers to some family members and I'll need something to back up the numbers to them...

Erlang and Haskell are on the short list for 2010. A functional language is definitely in order for me. So far I'm really only comfortable with relational, procedural, or OO languages. Need to get outside that comfort zone.

I self-identify as a jack-of-all-trades whose primary skill is learning things quickly and whose second skill software development. I didn't start out knowing a darned thing about any of the domains that I've worked in through the years (DSP design, bioabsorbable polymers, CAD/CAM, sales force management, flood map evaluation, microwave WAN's, social web analysis, network security, contract management, Disney (ugh), online storage, cloud storage, etc.). Didn't slow me down. Am I an expert in any of them? Well, in two or three I knew more about the underlying issues than the business people by the end of the project. Don't know if that's enough to make me an expert.

Perhaps that's why we have to work with so many shitty applications out there. Ask for X, but programmer doesn't really understand X, and person writing the specs doesn't really understand how to describe X, so you get a program that sorta meets the requirements for X, and everyone just puts up with it because no one knows how to just write it themselves because they've got other shit to do.

This is why excellent developers are worth the cost and effort of hiring them. Really good software developers can learn about X (whatever it is) to the point that they can discuss details and balance trade-offs with the business people and then develop the best possible system to do X. There isn't a domain that can't be taught to a new highly skilled learner. If you're talking to developers through a spec, either you didn't hire the really good ones, or you're wasting their capabilities.

My (very self-serving) opinion, of course :)

Actually, I value long battery life and low cost. Since this is a DVD player first and emergency laptop second, that really is the order of things. If they can keep the battery life up and the cost down while upgrading to a higher-res 12" screen, I'll take two!

So, after reading the article (ahem), I think he did a surface analysis of some inaccurate numbers and is simply wrong. When looking at the growth of the world's economy in 2008, it was slower than previous years. Does that mean that there weren't any opportunities? No. You just have to look at more specific numbers to figure out where the growth is.

There are still plenty of software products and services to be written. If you want to have a shot at making a bundle of money, write one of those products or services. But don't think you're going to make a bundle of money helping a business keep it's desktops running and properly licensed. You'll get your pay and build up your 401k (which is enough for a lot of people).

If I had to advise somebody today I would say learn a field first, and then make sure that you can write the code in that field. That is the best combination.

This approach to resume construction is limited to a (potentially very small) subset of the software development jobs in the market, and is therefore riskier than keeping your general development skills sharp and learning new domains as needed.

Could you first learn the code and then the field? Well sure you can, but business will prefer the other guy first.

This assertion is interesting. I think there's more of a blended balancing of concerns than you're thinking about, and in my experience, knowing how software needs to be developed to work in the real world (whether embedded, desktop, multi-tier, SAAS, whatever) is the really hard stuff to teach, where the relevant business details are usually pretty straightforward. Again, in my experience, being expert in a kind of software is of more importance than the specific domain, though having experience in both aspects of a particular job will obviously be better than being experienced in only one.

In your case (and here's where I think the confusion lies), you're not doing the same variety of "stored data shuffling" that most of the rest of us do, your code is much more analytical and algorithmic. It's quite possible that you're actually doing what a CS degree prepares BSCS graduates to do (extremely unusual in my experience). That means that your "kind of software" is algorithms, so being an expert in that kind of software development IS the more general skill for you. I would personally label that set of skills as distinct from the specific application domain (fixed income, market predictors, risk analysis, etc.).

Further, I absolutely think you're being short-sighted if you're not keeping up to date on other aspects of software development so that if demand for your current skills declines, you can still return to the larger market of software developers. In late 2002, as I was looking for a job in a crap market, I sent applications to both coasts (New York and Los Angeles) feeling that I could interview strongly for jobs in finance or in the various kinds software being developed in LA. I got offers from both coasts and I'd like to think that it was because I successfully argued that my fundamentals were strong and I could quickly get up to speed on anything that was missing.

I have no idea what's behind Siebel's statements. In my continuing experience as a software developer and as someone who's hired software developers, he's completely full of it. I suspect that, like many others who hire software developers, he's frustrated by the price he has to pay for highly skilled people (the 10x developers) and he's just venting. He's entitled to do that, of course. I'm just as entitled to ignore him.

After all most of the code these days is written in "very safe" languages where it is hard to shoot yourself in the foot.

Out of curiosity, which languages are these? I've been writing commercial software for 15 years. I try to learn a new language each year (ruby in 2006, php in 2008, python in 2009). But I currently have very little idea what "more safe" or "less safe" mean when describing a computer language. Any pointers?

Honest, yup. Open, more important than can be possibly imagined. Calm, not so sure.

On what to be open about: every argument, every single time my wife and I felt upset with each other and had to talk it out later, the underlying issue had to do with unstated assumptions. One of us thought we were doing one thing, the other expected something completely different, and conflict follows. Explaining my actions as I'm doing them, especially when I feel a hint of "What did she want, exactly?" has helped me over and over.

On calm, well, it depends what parent means. It's good to be upset and angry sometimes. It's even good to get into an argument sometimes (I'll explain these two in a minute). It's not okay to let being upset turn into rage or hostility or linger into bitterness. That way lies the end of your marriage. An argument is a discussion about how your relationship got hurt and can be fixed. As for why it's okay to be angry and argue: you are two different people. There will be differences. Some of those differences are more important than others. If you never have an argument, one of you has given up on expressing themselves. That leads to bitter resentment in the quiet one, which means the relationship is doomed.

The trick is to argue with the goal of both of you understanding what went wrong and figuring out how to avoid it next time. Here is my list of important pieces of advice about arguing:

• Remember that you're arguing about a harm to the relationship and that your goal is to understand what went wrong and to fix the relationship.
• If either one or both of you tries to "win" the argument, you will hurt the relationship more instead of fixing it.
• If you can't argue without calling names or rationally discussing why you feel hurt, force yourself to walk away until you calm down, then come back.
• Have your discussion as close as possible to the events that caused the problem as long as you are both able to discuss the problems rationally. Leaving issues to simmer and erupt at a later date causes even more problems.
• I've never wanted to go to sleep angry and so I've worked to draw my wife into saying what's wrong and working it out before we go to bed. After initially being afraid that I was being controlling, she now knows that arguing with me is not yelling and screaming and is much more comfortable with it. (this one may not work for everyone)
• It is very likely that by the time you get to an argument, both of you will need to apologize for something.

On apologies: my wife and I have very carefully drawn out rules around apology and acceptance of apologies that have helped our relationship enormously. Maybe they'll help yours:

• Once you accept an apology, that subject is closed. You can't bring it up again (this is bad form anyway, but it's explicitly verboten in our relationship).
• Don't even think about accepting an apology unless you're really willing to let it go.
• You don't have to accept an apology right away. Maybe you're still too angry to let it go. Maybe you'd like the apology rephrased. It may not address why you felt hurt. It may not offer a future course to preventing the hurt again. When you feel up to it, explain why the apology isn't what you want to hear.
• Don't take too long to accept if the apology is a good one. If you can't accept the apology within a few days of it being offered, even if it's exactly what you wanted to hear, find someone to help (friend, couples counselor, psychologist).

One last piece of pretty universal advice:

A marriage is hard work. Living that intimately with a person who looks at the world through different eyes takes patience, a willingness to compromise, and a strong sense of self. A marriage is also worth the hard work.

Good luck to you both!

He wants an open and public discussion about exactly this situation so that he can point the whiner to it and show consensus on what the GPL does and doesn't say. Smart, actually.

Of course.

Just like "free" television programming, "free" web services absolutely need to be paid for.*

It may be worthwhile for Google to offer some things that are truly free if it means that there's more money coming in overall, but in general, Google definitely wants to offer attractive services that can pay their own way via subscriptions, advertising, or something else we haven't thought of yet...

* I offer Twitter as a temporary counter-example to this. I still have no idea how they're going to make money.

He doesn't, actually.

I do, actually.

My experience was with Sharepoint in 2005 (before I started at Google). Small company (about 100 employees). Over the previous two years, the project team had created an extensive development info repository with TWiki, but the new VP Dev thought that we should switch from mixed Linux/MS to MS only. So they asked all of the developers to move everything over to a new Sharepoint deployment, under the guidance of a MS certified Sharepoint consultant (never knew exactly what certification they guy had).

This basically meant taking each page from the Wiki, creating a Word doc that said something similar (without the effortless linking of a wiki), and uploading it into the Sharepoint knowledge base. There was a very cumbersome checkout/edit/checkin process which seemed to take the worst of the issues from VSS and bless them with new life. The whole thing was awful and ended up being abandoned in favor of the old wiki within a year. We were also trying to take the core product (contract management) and move it so that it could be accessed via a Sharepoint interface. The API's were worse than the document management system, and this architectural 180 was also abandoned within a year as completely untenable.

I never did see an useful/informative definition for what Sharepoint was, so a document store that couldn't quite be a wiki and several attempts to improve the collaborative interaction, was what I experienced. It wasn't very impressive.

BTW, I'm not anti-MS, just have nothing good to say about Sharepoint. I really like .NET (even though I don't get to use it at Google). Some very cool stuff in there. The internationalization support I found particularly shiny.

Commodify everything the customer needs to use your product. This is taught in business school 101. That Google is pursuing such a strategy is not newsworthy. It would be newsworthy if a company stacked with this much brainpower wasn't aware of such a strategy and making sure that their competition was on it's toes. Microsoft, for their part, argues quite correctly that Windows and Office have many more features than the oversimplified little trinkets that Google is putting out. We'll just have to wait and see what the market really wants (which is the whole point).

Is Google using our current dominance of search to distort other markets? I don't think so. Linux was already free and being used by netbook makers, and nobody will be coerced into using Chrome OS. Firefox and Safari and Opera are all free so Chrome is just another free browser. Even search is a pretty precarious monopoly. Someone comes out with a better search (and Microsoft is trying very, very hard: look how fast Bing changed from sucky to pretty interesting) and the masses will shift just as quickly as everyone abandoned altavista back in the day.

Ultimately, the question of whether Google is levering an arguable search monopoly into other markets is a question for lawyers to answer. I certainly don't see it. Google really is trying to make a profit in Apps and Gmail and will move in that direction for Chrome and Chrome OS as they mature.

First of all, it's very difficult for corporations to not be sociopathic, but in my experience, Google management does try to avoid most of the pathological problems of modern corporations. "Don't be evil" has been getting pretty rough treatment in the press, but from my inside perspective, the whole company perks up and pays very close attention if it looks like the company might be reneging on that statement. Upper management keeps on trying to be transparent, which also helps a lot.

In this case, the behavior is a rational response to an aggressive competitor known for doing underhanded things to eliminate competition. I don't mean to make excuses, as Google's behavior is not defensive in nature, but in the (sometimes, occasionally) free market, competition is rough business and Google is willing to step up, even if our culture does put some big ethical boundaries around what we will do. Microsoft has been famously big on much shadier tactics. Starting acquisition talks with competitors to get strategic information, then screwing them over. Google won't do that.

The value of Google's behavior is a situation where the consumer spends less and less for more capabilities until they only have to pay for the marginal value of the hardware to do just about anything a computer can do.

Next sub-question: who's at risk? Without needing to ask anyone inside Google, any organization who can throttle or put a toll on Google's services is at risk. Speculatively, telecommunications companies, mobile carriers, governments, etc. are all vulnerable to various tactics intended to minimize the chance that they'll be able to cash in on or otherwise interfere with how Google makes money.