Paul Graham has this advice in his latest essay:

Instead of working back from a goal, work forward from promising situations. This is what most successful people actually do anyway.

In the graduation-speech approach, you decide where you want to be in twenty years, and then ask: what should I do now to get there? I propose instead that you don't commit to anything in the future, but just look at the options available now, and choose those that will give you the most promising range of options afterward.

It's not so important what you work on, so long as you're not wasting your time. Work on things that interest you and increase your options, and worry later about which you'll take.

When I ask people what they regret most about high school, they nearly all say the same thing: that they wasted so much time. If you're wondering what you're doing now that you'll regret most later, that's probably it.

The only real difference between adults and high school kids is that adults realize they need to get things done, and high school kids don't. That realization hits most people around 23. But I'm letting you in on the secret early. So get to work. Maybe you can be the first generation whose greatest regret from high school isn't how much time you wasted.

Jon Udell has started screencasts - small movies available for broadcast over the Internet. His comment: "the possibilities of the screencast medium continue to fascinate me. Movies communicate so much more than the obligatory static screenshots you typically find on product websites. I've mostly done long-form screencasts so far. But today's exercise makes me realize that the short film -- which highlights one specific thing and takes no time at all to produce -- is a useful form as well."

Barry Briggs writes:

Here's the conundrum (or at least thought experiment): today, integration servers largely serve the purpose of normalizing, or at least putting a facade upon, a wide variety of heterogeneous API's, protocols, data formats, security models, transaction models, and so on.

Now, let's posit a world in which all legacy protocols and formats melt away in favor of SOAP, XML, and WS-*. We all know that this transition won't happen overnight -- it may take decades, but that the transition over some period of time is inevitable is our assumption. So, if all these messy issues are going away, then does the integration broker go with them?

Put a different way: if every business application in your computing ecosystem exposes rich, standards-compliant services, then does the traditional hub-and-spoke model of integration still have value?

We need a refined notion of sequencing of services, of process, and we need a hosting environment where those processes can run, can be monitored, can be tracked. In the bad old days it was easy to do quick and dirty integration applications by writing a little VB here, a little Java there, and getting the data from one system to another in a point to point way. But as we learned, this didn't scale; it was completely unmanageable. Today we recognize we want a server that provides the process execution environment.

The Shifted Librarian (Jenny) points to a post by Werner Vogel: "The increase in the number of feeds will leave many users frustrated, as there is a limit to the number feeds one can scan and read. Current numbers suggest that readers can handle 150-200 feeds without too much stress. But users will want to read more and more as new interesting feeds become available and they run into the limitations of the metaphor of current aggregator applications. The current central abstract of aggregators is that of a feed, and there is a limit to how many individual feeds one can actually handle. Aggregators will need to find ways in which the users can be subscribed to a select set of feeds because they want to read everything that comes from these feeds, but also subscribe to a much larger set of publishers for which the feed abstraction may not be the right metaphor. Aggregation, fusion and selection at the information item level instead of at the feed level seems to be a first abstractions to investigation."

I am at about 175+ feeds currently.

Russell Beattie writes:

I've got what is arguably the most powerful mobile phone in the world in my pocket. It's a 3G device with a variety of communications and media capabilities, yet it sat there for the past 72 hours with nary a button press. In *my* pocket. Why? Obviously there are other devices and offline activities (sleep, mostly) which are competing for my loving attention. And honestly there's also really a dearth of apps and content for the phone - I've played with most of what's available already (but that hasn't stopped me with fiddling with all that stuff before). But I think what the real reason I haven't used my phone is this idea of context.

Mobile phones still need that killer app which takes out the need for context. They need to get to the point where they are less devices that you use while out and about, and considered more destinations in their own right. In other words, the current crop of apps are mostly created with that "mobile context" in mind. So you could say I haven't looked at my phone lately because I haven't been moving much. This is wrong. It's limiting a platform which can potentially do anything that a small computer with broadband access can do. The person who comes up with the app that compels a person to use their phone without considering the fact that it's a phone is going to have a killer app on their hand. One could argue the opposite, that mobile phone apps *should* only be used in the mobile context, but I think that's too narrow minded.

Mike doesn’t necessarily imply a thin client. “A local client needn’t have no storage. It could have storage, and even a local processor. Many people who are reading this are assuming the client would have to be some completely dumb terminal. I can almost guarantee this would not be so. Applications would simply not be responsive enough without some local storage and processing power, and this would be a very poor design, indeed. Remote application provision and administration absolutely do not preclude local processing and storage.”

A later post by Mike adds: “The biggest reason I think some measure of ASP and centralized computing is inevitable for the vast majority is because the average user will never desire to, or in many cases even be able to learn, all the steps that the author of the post had to complete to clean and then secure that Windows machine.”

John Zeratsky wrote in a post referenced by Mike: “Many assume Mike is talking about using so-called “dumb clients” (simple computers with little or no local memory or storage). I think he’s suggesting a more subtle shift away from the massively complex computers we run on our desks today. For years, I have been a proponent of moving the tools for creating, manipulating and collecting information online. Centralized (i.e. web-based) systems have advantages for all kinds of users, and needn’t result in the extreme scenario the commenters on Mike’s post call for. It’s not that everyone has missed the point. They’re just asking the wrong question. Distributed computing is already here. Most day-to-day tasks of average computer users are online. And it works.”

Om Malik wrote about Mike’s post: “It is nice to finally meet a kindred soul. Mike in a well articulated essay points out that as broadband becomes more prevalent and bandwidth to the home increases, the operating systems and computers as we know of them today will become irrelevant. With Longhorn, Microsoft is trying to perpetuate the days of local computing, and I feel they are moving in the wrong direction. Like an off-balance fighter, the first time a company starts punching in the other direction, the momentum is likely to shift to the other fighter – in this case, cheaper, better-prepared applications such as Linux, Firefox, and other Open Source applications available for free… Broadband frees us from the tyranny of bloated operating systems and faster processors.”

This was my initial response: I have written extensively about the opportunity to reinvent computing in a world where communications exists. This is one revolution which will begin not in the developed markets but in the emerging markets. It will also integrate computing and communications. Our Emergic vision is about making it happen, and bringing to the next billion users services built around a centralised ‘commPuting’ platform.

- Tomorrow's World (Nov 2004)
- CommPuting Grid (Nov 2004)
- Massputers, Redux (Oct 2004)
- The Network Computer (Oct 2004)
- Reinventing Computing (Aug 2004)
- The Next Billion (Sep 2003)
- The Rs 5,000 PC Ecosystem (Jan 2003)

Tomorrow: Comments