Brian Shaler

Occasionally Interesting

Gravity is for chumps

Archive for May, 2007

The Allegory of Time Investment

It has been said that ‘time is money’. The association is generally drawn between the two in reference to billing hours. If you are not doing something that brings you money, you could be doing something else that would. Therefore, the profitless activity is costing you the money you could be earning.

This concept should not be new to most, since the phrase exhibits fairly widespread use. However, it serves as the perfect introduction to a deeper metaphor between time and money.

I am going to illustrate how successful people — often subconsciously — embrace this metaphor, while others may be limited to thinking of investment in terms of dollars and cents.


If we begin to examine the concept further, we will notice other striking similarities indicating that time is very much like a currency.

First, we can note some coincidences in the English language. The word ‘currency’ can either relate to time or money, depending on context. Time, like money, can be refered to something you can ‘spend’ or ‘save’. With these similarities being part of everyday dialogue, it would seem like this allegory is dangling under our noses in the most conspicuous way.

Both time and money can be wasted or invested. This is another seemingly rudimentary statement. Everyone knows you can invest time into something (e.g. “I invested a lot of hours in that video game!”). In many cases, the term ‘waste’ should have been used instead (e.g. “I wasted a lot of hours on that video game!”). Investing generally implies that the amount spent was done so with the intent of receiving some sort of return. For the sake of this discussion, I will only use the term ‘invest’ when a return on investment (ROI) is expected, and use ‘waste’ otherwise.

Yes or Uh Oh

All the time you spend can — and should — have some sort of positive ROI. You should be able to ask yourself what I call a “Yes or Uh Oh” question: Am I investing my time right now? This is a “Yes or Uh Oh” question because if the answer is either ‘Yes’ or you come to the realization you are making a mistake (hence the ‘Uh Oh’).

It may take some creative thinking to figure out what the return on investment is. This is because the return for your time typically does not come in the form of time.


As an example, we can examine two different breakfast habits. In one situation, we have an individual who wakes up, rushes to work, and eats a cereal bar in the car during the commute. On the other hand, we have an individual who wakes up, prepares a hearty breakfast, and eats it while reading the newspaper. While the second individual may be late, studies indicate that he or she is likely to be more productive at work. The time spent having a full breakfast and preparing the mind for the day can be viewed as an investment. The return on investment in this case would be a productive work day.

Investing Wisely

Successful people are known for investing their money wisely. Typically, they also invest their time wisely. Many people, aiming to become successful, are diligent in their finances and think that is all they have to do. If your goal is to be wealthy, you should ask yourself the question “Is what I am doing right now going to bring me closer to my goal?” regularly, and try to make the answer be “Yes” as often as possible.

As a Web Developer

For example, my profession, web development, provides many situations where wise time investment can make a great impact. Time needs to be taken into consideration as much, if not more than, money when approach some types of work. If a project is not going to become a valuable part of your portfolio — something that will lead to more work in the future — or if it is not going to be a valuable learning experience, what value does it have? If the only value (ROI) the project has for you is “paying the bills”, then that is all it will do and all that it will ever do. Portfolio pieces and educational experiences are not the only types of returns you should require, just two common examples.

Keep in mind that successful people do not generally ‘waste’ their time on work that will only provide immediate return. Instead, they focus on investing their time into work that provides long-term, accumulating returns.

Invested Time Returned As Time

In some cases, the time invested can return time as profit. As an example, someone can build a widget that reduces the amount of time a certain task takes. Every time that widget is used, the creator gets back the time he or she would have otherwise spent. The saved time can then be reinvested into other things.


The idea, of course, is for the ROI to end up with monetary value. It does not always have to have a direct monetary return. In fact, it is quite the opposite. In the sense of investment, the value of time can change much more dramatically than money, since it is not tied to anything tangible. By investing your time wisely and reinvest it when possible, you will increase the profitability of your accumulated time investment.


This article is intended to illustrate how time can be invested as a currency to accumulate value and wealth, to give a fresh perspective on personal growth, and to motivate others to invest time, rather than waste it.

This article has also been published on

Does Digg Need a Pictures Section?

That is the first of a series of questions as we examine whether or not Digg needs a Pictures section.

The answer seems obvious. Thousands of Digg users have expressed their support for a Pictures section. Has the ‘wisdom of the crowd’ come up with the best solution?

People have been focusing on that answer, when they should have been analyzing the question. Does Digg — a ‘news‘ site — need a Pictures section? It does not seem like a proper fit. If Digg in fact does not need a Pictures section, then what is the alternative?

The solution can be approached by expanding on the question: Is it Digg — a ‘news‘ site — that needs a Pictures section, or Flickr that needs a Digg section? Flickr is, after all, a photo-sharing site. What better location for these popular photos than a photo-sharing site?

Of course, now we approach a key roadblock for this solution: Flickr Explore. Flickr Explore is like the Digg Front Page, but for popular photos, rather than news. Is Flickr Explore insufficient at presenting the best new photos? That cannot be the case. Flickr’s “Interestingness” algorithm actually does a great job of ranking photos by quality. You could say that it is just as good — if not better than — Digg’s vote-driven quality ranking.

If Flickr Explore is just as good at delivering quality content as Digg’s Front Page, then why are people demanding a Pictures section for Digg? Why not just use Flickr Explore?

By examining the differences between Digg and Flickr from another perspective, we will find that Flickr Explore is insufficient. It is not the quality of content, no. The quality is arguably as good or perhaps even better than Digg’s vote-driven ranking system. The critical flaw in Flickr’s “Interestingness” algorithm is that it does not deliver content that matches the taste of the user. Flickr Explore is glaringly insufficient because it is one giant list of all types of photos.

How successful would Digg be if it was only one category? Could we compare its success in that scenario with Flickr Explore’s success in the photo realm?

If Flickr Explore delivered popular photos of various types to the people who say they are interested in that genre, would Flickr Explore have the appeal of Digg?

I hope you enjoyed this one-man Platonic dialogue.

You Think You Know (JavaScript) But You Have No Idea

For those that don’t know who Douglas Crockford is, here’s a short bio via Wikipedia:

Douglas Crockford is a senior JavaScript Architect at Yahoo Inc.. He is well known for his work in introducing JavaScript Object Notation (JSON). He has also worked on the computerization of media at Atari, Lucasfilm Ltd., and Paramount. He is the founder of two startups, Electric Communities and State Software.

I recently stumbled upon a series of videos of Douglas Crockford talking about the JavaScript language.

JavaScript is not my favorite language. Since I mainly only use the web browser implementation of the language, I have had countless experiences struggling with cross-platform incompatibility issues. Besides that, the language is great. It’s flexible, powerful, easy, and support for it is extremely widespread.

In his videos, Crockford covers a wide range of topics, from JavaScript’s history to example syntax. Many advanced JSers might find some parts of it to be a little too rudimentary, but I think there is quite a bit to learn for JavaScript programmers of any level. I’ve been writing JavaScript for over 5 years, and learned quite a few things about JavaScript that I didn’t already know.

The videos are highly recommended for anyone that uses JavaScript. The videos are even MORE highly recommended for people who know another language and are thinking about learning JavaScript.

Writing Tools for Digg Users: The Inevitable Digg Effect is an ideal target for creating instant gratification content. You can come out of nowhere and have tens of thousands of new users in 24 hours. An inevitable woe is the Digg Effect — a sign of success and often the key to server failure.

How do you make 10,000 comparisons of Digg users to the rest of the community?

How do you display 600,000 links to relevant Digg stories in thousands of users’ browsers?

How do you tell 40,000 users where they are located on a map of 67,000 users?

How do you display 15,000,000 Diggs on that map?

How do you do it all on one shared hosted server?

Birth of a Digg Tinkerer

In December, I ran an experiment that required collecting a lot of data on thousands of users. Other parts of the experiment included measuring traffic and Google Adsense revenue during the Digg Effect. I created a little gadget, called “DiggStatus“, where Digg users could type in their user names to see how their Digg usage statistics stack up against the rest of the community. The experiment was much more successful than I had anticipated.

Weekend Projects

Every once in a while, it’s nice to get away from clients, meetings, deadlines, revisions, and product launches. Build something you want to build. Make your own deadlines. Change your mind — no deadlines. Finish it when and if you feel like it.

During the last few months, I have created a small collection of projects geared toward Digg users. Each is intended to be in itself a one-hit wonder. Get to the front page, get viewed by thousands, then recede into oblivion.

The Inevitable

Creating content for Digg is all or nothing. Either it hits the front page and you get blasted with thousands of visitors in a short period of time, or it passes through Digg’s upcoming stories section without a hint of interest.

Creating tools and gadgetry for the Digg front page puts a developer with limited resources in a sticky situation. You have to last through the Digg Effect, or nobody will see it.

Looking into a Broken Mirror

Digg users are accustomed to using mirror sites to view content after the target web server crumbles under the load. Unfortunately, mirrors are only useful for static content. Mirrors can’t learn your application’s recommendation algorithm. Mirrors don’t know the coordinates of users on the map you just made.

As a tool creator, it is imperative to withstand the Digg Effect.

Every K Counts

Look at the amount of data your web server will have to send for every visitor.

If your web site has a layout that utilizes images, jump ship. Set up your to-be-Dugg page outside of your layout. Add color with HTML. Structure your page with very light-weight HTML. A logo at the top of the page can be all it takes to push your web server over the edge. With links back to your site, only interested traffic will be directed to your normal site.

If you require images, find somewhere else to put it, so the bandwidth can be diffused between multiple locations.

Keep Quiet

With thousands of Digg users slamming your server in a very short period of time, even the simplest database call can be destructive to your server. If you use a framework for your site, make sure you have caching set up so you don’t ping the database for the same data thousands of times just to display the page.

In the tool itself, you need to optimize, optimize, optimize! Database queries add up faster than you may think.

Put Your Money Where Your Mouth Is

This week, I released two tools that utilize a map I generated last weekend of the Digg community.

The first tool allows visitors to search for a user name to find where that user is located on the map. This one required 3 database queries per request — one to find the location of the user, one to count the user’s friends, and one to count the user’s fans. While it was on Digg’s front page, about 40,000 users were requested. The database was therefore queried about 100,000 times. All of this and I didn’t receive any mention of downtime from users. If I had used one more database call, and taken the total up to 130,000 queries, the server might not have been able to handle the load.

The second tool I released this week displays Diggs (votes) on the map in real-time (with a small delay) and placed at the Digging users’ location on the map. In 24 hours, the tool has displayed 15,000,000 of those votes. Unfortunately, there were a few hours that users had intermittent access to my site. Contributing to the overload, the first tool was still getting quite a few hits from Digg, it was featured on the home page as a Daily Link, and there were quite a few StumbleUpon users.

However, despite a little bit of downtime, this one did quite well, thanks to some heavy optimization. It may appear like there are tons of queries going on, with all those icons popping up on thousands of screens around the world. The search functionality in the other tool required 3 queries per request. This tool only required one query per 100 Diggs (though, the tool may at times display over 1,000 Diggs per minute). The results were returned to the client in a compact comma-delimited list, where the Flash front-end would then break the results apart.

Moral of the Story

If you create content for Digg, take a close look at the your page and/or tool’s weight on the server. You need to save every byte you can. You should only contact the database when absolutely necessary.

The Digg Effect should be a sign of victory not a sign of defeat.

You are currently browsing the Brian Shaler blog archives for May, 2007.