Joshua Go

The reasoning behind Lumberjack

noreply@blogger.com (Joshua Go) — Wed, 16 Dec 2009 21:08:00 +0000

So why, in 2009, in a world of RIA frameworks, web-based applications, and a wide variety of blogging engines to choose from, would I write a desktop application in Java targeted exclusively for one company's proprietary blog platform?

First of all, it was tempting to write this as an Adobe AIR application. It would have fit my requirement that it be cross-platform and run as a desktop application, but I've never written anything with Adobe development tools before. Given the limited time I had on weekends to work on it, I wanted to get something written as quickly as possible rather than spending all my time learning a new platform. With Java, I could just hit the ground running, and it was just a matter of referencing the Swing-specific documentation. It boiled down to what was expedient and familiar because it would allow me to build something quickly.

With respect to the issue of making this application web-based, the main point is that I didn't want to start up a browser just to create new posts on Blogger. There's the Blogger Dashboard for that. Now, it's true that one could write a slimmer, lighter, faster-loading web-based client for Blogger without all the heavy clutter of the Blogger Dashboard, but it would still require that I start up a web browser; in the end, I wouldn't end up using it much. I wanted to build something that I would use and keep on using. (I have also been writing web applications for the past five years, and thought it would be fun to write something that ran on the desktop for once.)

Finally, there's the issue of this program being a client specifically for one company's proprietary blogging engine. Why not make it work for WordPress, TypePad, Posterous, and all the other major and popular blogging platforms? For that matter, why am I still using Blogger when there are so many newer, slicker platforms to choose from? I have to admit that I was tempted to switch out from Blogger — WordPress and Posterous in particular have impressed me the most — but when it comes down to it I'd rather have my blog on Google infrastructure than anywhere else. With that said, not everyone feels this way, so they choose newer, snazzier blogging software — which is how Blogger ended up neglected by hobbyist software developers. To this day, I still can't even log in to my Blogger account using Drivel, a desktop client with support for all sorts of blogging engines.

Introducing Lumberjack, a desktop client for Google Blogger

noreply@blogger.com (Joshua Go) — Wed, 16 Dec 2009 02:59:00 +0000

Earlier this year, I mentioned that I was working on a desktop application, a client for Google Blogger, written in Java with the Swing GUI toolkit.

I recently found some time to work on the enhancements that I said I wanted to do during my last update, and I'm ready to release the application to the world. Get a ready-to-run file at the Lumberjack download page. Just download the JAR file, save it, and run it; it will work as long as you have a Java runtime installed. If you're running Windows, Mac OS X, or Linux, you probably do.

If you have trouble logging in, you may have to solve a Google CAPTCHA first. You should only have to do it once.

If you're a developer, you'll find the source code at the Lumberjack GitHub repository. Simply run ant to build the application. (Yes, I put a lot of effort into getting this one-step build working.)

Patches, questions, and suggestions are most welcome. Just leave a comment on this post.

Idealism and retreat

noreply@blogger.com (Joshua Go) — Tue, 15 Dec 2009 02:58:00 +0000

When I'm by myself, when it's quiet with no distractions pulling me in a million directions, I automatically start to dream and envision great things. All of my scattered realizations and fleeting memories somehow just coalesce to give me more clarity about myself and what I'd like to do. It's as if a master blueprint is forming in my mind. It's not a time for questions about implementation or feasibility, but for consideration of what should be done simply because it's the right thing to do. There's no cacophony pressing from without, clamoring that it can't be done or that it's not worth the time, effort, or attention.

Organic thankfulness

noreply@blogger.com (Joshua Go) — Fri, 27 Nov 2009 20:10:00 +0000

I've always had trouble keeping my sentimental cycles synchronized with what the calendar officially sanctions. This year is no different. I got into a very thankful mood early — well before Thanksgiving Day rolled around. Days before Thanksgiving proper, I was working on writing the bulk of my post-wedding "Thank You" cards.

True to my high ideals and impractically grand ambitions, I didn't want to just write a generic, canned response to everyone; I wanted each card to be sincere and personalized for each recipient. For I follow the golden rule: "Do unto others as you would have them do unto you." If I am deeply insulted and take personal offense whenever someone sends me a generic message disguised as a customized one, why would I inflict the same on others?

Faced with the task of writing so many customized notes to so many people, it was hard to even get started — but good old engineering experience soon kicked in. Whenever I find it hard to get started on something, I try to build momentum by doing the easy part first. Then, to maintain that momentum and to keep my focus tight, I periodically stop and ask myself what the main objective is, and re-align accordingly.

So, I started with what was easy. I simply read the card that each person sent, so I could see what was written. That would give me something to riff off of. And sure enough, this worked in giving me something to start off with. But the unexpected (and much more helpful) side effect of reading these cards was that they just naturally made me feel thankful. Writing the response just seemed like the natural next step — in contrast to painfully extracting whatever random remnants of goodness I had left in me, or emotionally manufacturing shoddy imitations of good cheer for putting on paper.

The trouble with letting nature run her course and supply material for us is this: what she supplies seldom fits our purposes exactly.

And so, I had to rein in my overflowing thankfulness to keep it focused on thanking people specifically, rather than letting my responses meander all over the place.

I remember one specific instance of an older relative, widowed for a couple of years now, whose long and happy marriage had instilled in me a deep and lasting belief that marriage in this day and age could work. She and her late husband had so many excellent qualities that I could easily have filled her card by heaping random praise on them. But by focusing on thanking her first, I actually had the chance to keep the note shorter and more meaningful by zeroing in on how they inspired me through their marriage specifically, rather than listing their virtues as individuals.

I'm almost done writing these cards. Each card gives me a chance to take a natural sense of gratitude and then channel it in a way that renders it more meaningful by doing a better job of making it known.

Automated summaries and excerpts

noreply@blogger.com (Joshua Go) — Mon, 06 Jul 2009 06:45:00 +0000

You've seen them around the web: they're the blocks of text appearing under the headlines, giving you a little more information on what the linked article is about. If the headline didn't tell you enough, the summary or excerpt is supposed to serve as a sort of fall-back mechanism to tell you a little bit more.

The websites of such longtime print titans such as The New York Times, The Economist, and The Wall Street Journal tend to have good summaries beneath their headlines. They know how summaries should be written — by hand. They are, after all, the professional producers of such content and have a vested interest in getting that content viewed.

Those who are a few steps removed from the production of such content, on the other hand, make it readily apparent that they just don't care. Two of the most surprising offenders are Google and Apple — ironically, two media darlings who appear regularly in feature articles.

A quick jaunt over to Google Finance gives us an example of their automated summary text. If news articles could get circumcised, then Google Finance summaries would be the equivalent of the unwanted foreskins.

decades of dollar ..." id="BLOGGER_PHOTO_ID_5355221299523276386" />

Where do we even begin when trying to enumerate what's wrong with this? First of all, the summary text is much too long to reasonably hold the attention of the typical reader who is scanning the page; it's unreasonable to even call it a summary.

And even if you read the entire thing, it doesn't make sense because it trails off. Decades of dollar what?

And then there's the extraneous information: the name of the author, the location where the article was wired from, and the name of the wire service. I'm sure the author is a swell guy, that Paris is a lovely city, and that Reuters is excellent at what it does, but what is all that doing in the summary text?

Oh, but Google is all about automating stuff, even if it turns out a little ugly. Let's look at what Apple does; we know they've got a better sense of design than anyone around.

Sorry to be the one to tell you this, but the headlines on the Apple start page don't fare much better. Here's just one entry from the entire embarrassing list.

Well, if anything could be called an improvement, I suppose we can give this one a little bit of credit. The summary is at least short enough to read and doesn't contain extra cruft. But it still doesn't make sense when considered as a self-contained sentence. Barbecue Glazed Alaska Salmon with what? Why should I click “Learn more” when you can't even bother taking the time to edit the summary to give me a coherent sentence up front? Is this entire article made up of sentences that are going to trail off and leave me hanging just like the summary did?

Why, in the middle of 2009, do we still see these amateur-looking automated excerpts on websites run by widely respected technology companies?

I'm not the one making decisions inside the conference rooms in these companies, so I can't say for sure. But I can venture a guess. These two companies are highly respected, to a large extent, because they're also highly profitable. Assuming that people don't really care whether the summaries are readable or not, it certainly makes sense to cut costs and forgo hand-editing of summaries. And being technology companies, of course they'd want an automated, technological solution; when all you have is a hammer, everything looks like a nail.

So these world-class companies knowingly produce these barely passable, poor excuses for excerpts. What does that mean? What's the implication? From this, we can conclude that these excerpts aren't meant to be read. If they aren't meant to be read, then they aren't meant to be taken seriously. They're merely filler text, a cheap imitation of what big-boy news organizations have done for years. Maybe in the age of continuous partial attention, this makes sense for a new kind of audience.

As for me, I'm going to remain stubborn and demand only the best from my news sources — including summaries and excerpts. Is it really too much to ask for a complete sentence these days?

Finely tuned collective effort

noreply@blogger.com (Joshua Go) — Wed, 15 Apr 2009 07:50:00 +0000

As someone who is rabidly individualistic, working with other people isn't something that's hard-wired into me. For this, I've been chided by friends and family members who hold collective effort up as a sacred cow. They cannot possibly fathom why anyone would question the merits of working together.

I remember reading (probably in the Harvard Business Review) that this teamwork mindset is prevalent especially among my generation, which grew up playing team sports and doing group projects in school. Contrast this with the modus operandi of previous generations of workers, who were much more individualistic: put your nose to the grindstone, pull your weight in the organization, and let your merits stand on their own.

In this sense, I am very much a traditionalist.

But I've been through some fiery projects in school and during my consulting days working with clients. Massive requirements and short deadlines have a way of focusing the mind and forcing the casting aside of closely held ideology. I've seen teams coming together to accomplish something that was more than the sum of the parts, and seeing that in action made me more open to the idea.

Still, I maintain what I consider a healthy skepticism towards a widespread and blind allegiance to the nebulous concept of collective effort.

I acknowledge that it produces tremendous benefits as many sets of eyes and differing perspectives hammer away to solve problems, and that work can be parceled out and done in parallel, resulting in undeniable time savings. Knowledge can be shared to increase the human capital of everyone involved; it makes everyone better off by increasing the raw capability of the team so that the team's maximum output doesn't merely hold constant.

But reaping these benefits does not come automatically.

Any time you pool resources to exert greater leverage, you also put yourself at risk of exercising power in the wrong direction or of misallocating those resources so that all you're left with is a colossal heap of waste. Capital intensive industries such as auto manufacturing earn billions in profit in good times, but when crisis strikes, the cost of all that unused capacity is crippling.

I don't want to come off sounding alarmist or overly pessimistic about teamwork gone wrong. Truth be told, it rarely ends in a blazing mess. Even the most dysfunctional team is just a misconfigured engine that nonetheless manages to sputter along, misfiring occasionally, but still operational. I'd guess that this is how most haphazardly assembled teams manage to get by.

If you choose to go it alone, it's like pedaling along on a bike: you can get in and out of places, but even the car with the misfiring engine can go faster than you can. Working alone feels much more elegant and affords the independent worker more agility. This is where the continued appeal of individual effort arises from. But for most undertakings worth their salt these days? A team effort is the smart choice, just like you need a car to really enjoy all that Southern California has to offer.

But again, let's be honest. Driving a car with a misfiring engine isn't very much fun. It's nerve-wracking, and the only people amused by it are the people who are laughing at you from a safe distance.

What can you do to pull off collective effort like a finely tuned engine?

Share knowledge. This makes you better equipped for the future.

Exploit different strengths and don't strive for homogeneity. This is where differing viewpoints and other sets of eyes can really come in handy.

Implement systems of coordination and common convention to maintain coherence. It's ridiculously easy for everyone to start doing things their own way.

Know the difference between parallel and serial tasks. As tasks in this knowledge-based economy become increasingly complex, it's not as easy as painting a room and asking everyone to take one wall.

Gather the right people for what you want to do. It does you no good to get an excellent tax accountant when what you need is a good plumber. No offense to tax accountants.

Question your assumptions: do you really need a team for what you're trying to do? Do you really need a large one, or would a small one suffice? And are you prepared to put in the hard work for everyone involved to get the maximum benefit out of the experience?

Enough with civility: confronting line cutters and queue jumpers

noreply@blogger.com (Joshua Go) — Sun, 29 Mar 2009 00:41:00 +0000

Last Saturday, Sophia and I went to Disneyland to celebrate my birthday and to spend some time together, since our work schedules haven't really overlapped favorably in recent weeks.

We were in line for the Matterhorn, and as decent, upstanding Disneyland patrons, we took our places at the back of the snaking line.

It was a long line, but it was what one would expect for a Saturday at Disneyland. It was moving at a good clip — faster than the 405 near Santa Monica during rush hour, anyway.

About halfway through, a suspicious looking Asian guy wearing sunglasses sidled up next to me from out of nowhere. For a good three seconds, he stood there without saying a word. I thought that he was expecting to be recognized, but upon closer inspection I could recall no previous association with him.

When he finally said something, he said, "Hey man, you mind if I get behind you? The line is really long and I don't want to wait in the back."

Flabbergasted at the audacity of the request, my verbal faculties sputtered, and the first thing to come up was, "No."

As I realized that I had actually issued an unintentionally affirmative and welcoming response, I stepped in to clarify. "I mean, yes, I do mind. And I mean that no, it is not fine with me if you get behind me."

He responded, "Oh, come on. Why not?"

"Because we began at the back of the line, like everyone else, and so should you," I said with an annoyed and furrowed brow. (At this point, it was only one brow. That's how annoyed I was: unibrow annoyed.) I gestured to the very back of the line. "You should start heading over there. You shouldn't be here."

He kept a straight face. "Oh, alright." And that was that.

Or so I thought. I turned around five minutes later, and he was just standing there — right behind me!

I looked at the people right behind him to see if they were upset in any way. It was a wholesome-looking white American family, and they didn't seem bothered by anything at all. It looked like they were having a good time.

I am certain that the scumbag probably chose to ask me because white people would be more likely to think we were together since we were Asian — which is a reasonable assumption to make. But the guy was alone, and I felt a little sorry for him; maybe someone close to him died. You never know what the story is with people, I figured, so I decided to forget about it.

But five minutes later, the scumbag's wench joined him. At this point, I was fuming, and was very close to causing a scene. Sophia told me to just forget about it since we were there to have a good time, and I knew that anger tends to make me act irrationally, so I just fumed for a while and hoped it would pass.

It has been a week, and it has not passed.

While writing this up, I found out that queue jumpers get away with it most of the time. In the future, please do everyone a favor and cause a scene, and I will do the same.

Now, I understand that it may be difficult to think quickly of what to do. If you need some ideas, here are a few things you can do to people who cut in line.

Wait until you get to the front of the line and then tell the people in charge. Make the cutters return to the back of the line all over again.

Loudly and clearly proclaim to everyone behind the cutters of what they have done. Populist outrage is a powerful force, and public humiliation is a long neglected tool. Put them together and you've got a great combination.

Take a picture of the cutters. If they cut in pretending to know you, why not play along? Say loudly, "Oh, hey, what does your new driver's license picture look like?" Remember their names, and then post their names, their pictures, and what they did, so that employers can find them when they perform background checks. (Make the page SEO friendly so these dirtbags are easier to find.)

Get physical. The line cutters don't belong there, so you're just righting a wrong and putting things back as they should be. A simple shove should do the trick, but be prepared for some pugilism should you go this route. This is particularly well-suited for those of you who don't resort to violence — because it's your first choice, not a last resort.

It's about time these scoundrels get what they deserve. If it helps, just bottle up whatever road rage you have, and instead dish it out to someone who actually deserves it. Disneyland may be the happiest place on earth, but happiness will remain incomplete as long as we remain complacent about people who blithely dismiss the ideals of justice and fairness.

Vision and chaos

noreply@blogger.com (Joshua Go) — Fri, 27 Mar 2009 19:39:00 +0000

Among the key elements of my father's network of enterprises are the fixer-upper houses which he rents out. As soon as my brother and I were old enough to be of use on these construction sites, Dad would take us along.

I hated the messiness of the building process. The floor would typically be littered with drywall chunks. Shattered roof tiles sat in piles on the front yard, and sawdust was sprinkled over everything.

When it was all done, though, with everything cleaned up, I felt accomplished for having been a part of bringing about the final outcome. It was more than easy to forget the messy process that brought about the end result: forgetting was automatic. It actually took me conscious effort to remember what it took to get there.

While I was in the thick of it, it was discouraging to see the mess in front of me, because it just didn't seem possible that everything could be made right again. All I saw was a seemingly intractable mess. My father, on the other hand, never seemed fazed by it. His vision of the end result was not clouded by temporary worry because he was certain of what we were working toward. He saw things not as they were, but as they should be.

Over the years, I learned to embrace the temporary mess, provided there was a plan and a vision for building something beautiful from it. Still, this sort of unflinching confidence doesn't just come at the flip of a switch. It took many messes and subsequent turnarounds to deeply ingrain this kind of optimism in myself. Even now, I need a conscious and intentional self-reminder not to be overwhelmed when confronted with a seemingly insurmountable task.

The boy knows he is a man when he can see not only what is in front of him, but what he's going to make of it.

My automobile's cooling system and its plastic parts

noreply@blogger.com (Joshua Go) — Tue, 10 Mar 2009 08:22:00 +0000

I've learned a lot about my car's cooling system over the past couple of weeks. There's nothing like the prospect of a melted engine to focus the mind. Typically, I would be content to leave it to the mechanic, but the cooling system has many moving parts, and I'm the one who sees firsthand all the symptoms when driving it in various situations.

At the very least, anyone in my position would have to take careful note of which circumstances triggered certain events. Such diagnostic tips can help the mechanic narrow things down so that he won't charge you as much for diagnosing the problem. Ideally, we'd also prefer that he fix everything that's wrong with a component as vital as the cooling system.

I've had to watch the reading on the temperature sensor, for one. The key is to never let the needle hit the red zone at the top of the temperature gauge. If it does, your engine's head gasket and other crucial parts are in critical danger of melting, distorting, or breaking. The repairs for those problems are much more expensive than those to the cooling system.

When I went to the mechanic this morning, I took in various observations that would help him narrow down the problem and know where to look. I noticed that the fans were going full speed because of the higher running temperature, so I told him that the fans were extremely loud after a short drive. From various sources online, I made sure to observe any difference between city driving and high speed freeway driving, but there was none, so this meant there was one less option to consider.

With the cooling system in my car, things have been failing left and right in a sort of chain reaction as the increased running temperature of the car's engine puts a lot of parts under extra stress. Whatever parts failed and needed replacing were just worn out and should have been replaced long ago. Rubber rings had become as hard as plastic. One plastic pipe had become so brittle from age that it broke off; I had to re-fasten the hose clamp just to keep the engine running cool enough to drive to the mechanic. Metal parts such as the thermostat housing and the water pump showed signs of corrosion; in the case of the thermostat, it wouldn't open to let coolant flow as it should.

The mechanic told me some interesting tidbits while we were ruminating aloud on the absurdity of car makers — including Daimler and BMW — using so many plastic parts all over the cooling system. According to him, the move towards plastic parts is justified by lower cost of materials and making the car lighter so the engine doesn't have to pull as much weight. One thing he observed was the increasing failure rate of newer cars — and he said it wasn't unusual for people with new cars still under warranty to come to his shop with worn out plastic parts.

Suffice it to say, that made me very hesitant about paying a premium for a newer model Mercedes-Benz or a BMW. If I end up buying a new car soon, it may well be a Hyundai, a Honda, or a Toyota. If everyone's using plastic parts, I may as well pay less.

In any case, I'm surprised that my old car has lasted this long, considering the long distances I drive on a regular basis. It's a 1996 Mercedes-Benz C220. I've been very fortunate to have the car running within its prescribed temperature limits, despite all the hand-wringing and pulling over to the side of the road, fraught with worry.

Feisty Ford Focus

noreply@blogger.com (Joshua Go) — Fri, 27 Feb 2009 07:58:00 +0000

People who drive small cars sure have colorful personalities. Yesterday, on the way to work, I saw a Ford Focus with a license plate frame that said, "Don't laugh. It's paid for." It was refreshing to see someone being flashy about their financial responsibility — a quality which is rarely flaunted.

Lessons from refactoring

noreply@blogger.com (Joshua Go) — Wed, 25 Feb 2009 08:15:00 +0000

I enjoy the process of refactoring software — especially software that was written by other people. It forces me to understand things inside and out (which is a tough point to arrive at when all you do on that code is the occasional drive-by bug fix). On top of that, since the desired functionality is known already, it's all redesigning of the data model and writing code. There are fewer product-level questions that come up. The specification is pretty much set.

For this particular project, though, I have the unique challenge of making the new design pass muster with multiple parties. People are picky and they always have something to say, so I took special care this time to anticipate any objections and address them so they'd get a better sense of my thought process. I've still had to make changes — and I make them gladly — but I've found that having to explain each decision I'm making generally serves to clarify my thought process.

It certainly helps to have some time to think hard about these changes, too. It's a healthy thing to let a data model sit for a bit and soak into the minds of all stakeholders while their input is incorporated. It also helps when people are interested enough to give detailed and insightful feedback. Sure, it generally doesn't hurt to have more sets of eyes looking at a plan, but having a team of people analyzing it harnesses collective historical memory — great for backward compatibility — and makes the plan more bulletproof by ensuring that it addresses concerns from many points of view.

Blogger client as a Java Swing desktop application

noreply@blogger.com (Joshua Go) — Sat, 14 Feb 2009 11:06:00 +0000

Ever since I started using Blogger, I've been looking for a decent, no-nonsense desktop client to write my posts. I personally find it to be a lot of hassle to load up a big, heavy web browser and log in to Blogger to make my posts. (To be fair, Drivel was quite excellent in the past, but doesn't look like it's maintained anymore.)

After a little poking around at Google's API documentation, I am pleased to announce that I'm writing this post from a desktop application of my own making. It's a Java desktop application using Swing, so it will run on Windows, Mac OS X, Linux, and any other major desktop platform with a Java runtime.

So far, I can select from a list of blogs, write in post titles (to be friendly to those search engines), write post content, and submit new posts. It's really basic, but it's quite a milestone and a major motivator for me to at least have gotten this far.

Soon to come on the feature front, I'm aiming for loading old posts to update, deleting posts, and smoothing out the user experience. (Right now, the app looks and feels like the weekend side project that it is. It doesn't even scroll when the text is too long.)

On the code quality front before I release this thing out into the wild, I'd like to do some release engineering, automate the build process, and just separate the various concerns (like GUI drawing code, network connections, and application logic.)

In any case, it feels good to have my software development methodology validated: get a dirty prototype up and running, and count on the morale boost to spur further development. So far, it feels pretty good. The hardest part is done and the challenge from now on is just finding spare moments to work on refining this thing.

Update 02/20/2009: I've implemented updating existing posts, and I'm updating from the improved client right now. Of course, to get to that point, it had to load up old posts. A cleanup of the code base before proceeding is probably in order, because I'm kind of going nuts trying to figure out where everything is and where new things should go.

Update 02/22/2009: I've created the build system to use Ant and package the app into a neat little .jar file. I also fixed a minor usability bug to make the app more pleasant to post with and give you feedback when a post has been submitted. The refactoring into a better architecture will have to wait; my mind's capacity for refactoring is mostly taken up by a big refactoring proposal I'm putting together at work.

Update 12/16/2009: It's open to the public! Please see the Lumberjack release announcement. The code has been cleaned up, made more maintainable, and a few features have even been added to make the application more pleasant to use.

The trouble with budget surpluses

noreply@blogger.com (Joshua Go) — Tue, 23 Dec 2008 09:17:00 +0000

The trouble with a government (or any big organization) running a budget surplus and sitting on a big pile of cash is that people start asking questions like, "Why don't we do something with that money, especially since there's so much to fix?" At that scale, having some cash ready for a rainy day is not an excuse that people are able to handle, especially when the quoted figure is in the billions of dollars. Surpluses may seem like a lot of money, although when divided on a per-person basis, they seldom amount to much at all.

In this deficit-infested time, it's easy to rail against profligacy in our budgets. I'm not trying to engage in what-ifs here. I'm suggesting a way we can avoid this same problem in the future.

We've been told that it's wise to save up for the future, to have some cash on hand just in case — folk wisdom that was reinforced by the big collapses this year. We also know that it's hard for most people to hear about a surplus in the billions of dollars without wanting to spend it on something.

If an even moderately sized government were wise and careful in its spending, it would quickly accumulate a large surplus. That large surplus would then get people dreaming about capital improvements, social services, and other goodies that drain the public purse.

Those who advocate for smaller governments would say that the problem could be solved by striking the problem at the root — shrinking the government and therefore its potential to accumulate large sums of money. But pools of large capital certainly have their advantages, and whether by conscious choice or mere political expediency a large government must stay large, it could do better to quote the figures based on the population of the governed; that is, on a per-person basis. This might make billion-dollar surpluses less distasteful to the vast majority of us, whose visceral reaction to large dollar amounts placed before us is to spend imprudently.

Small business owners: don't be a jerk

noreply@blogger.com (Joshua Go) — Fri, 12 Dec 2008 07:59:00 +0000

My girlfriend Sophia is an assistant manager at Abercrombie and Fitch, and is thus bombarded with more than her fair share of rude customers. One story she told me this week was about a woman who went ballistic after asking to try on one of the mannequins' jackets and being told no.

Now, people are just crazy, and Sophia has told me many stories like this before. What was so different this time?

Well, the crazy lady played the business owner card: if it were her store, she would have gladly taken the jackets off the display mannequins. This know-it-all "business owner" then proceeded to hound Sophia for her full name and pressed her for her employee ID so she could file a formal complaint, and refused to go through the normal channels.

It is precisely this self-serving arrogance and provincial, narrow-minded ignorance that keeps small business owners from being taken seriously. As a former small business owner myself, I know that the burden is heavy: you've got to worry about employees, customers and growing your business. On top of that, you have the responsibility to make sure any legal paperwork is in order and that taxes are taken care of. But just because you're able to handle this does not mean that you know all there is to know, and that your way of doing things is the only way.

In response to this growing sense of self-importance, here are three things to keep in mind. (I use these reminders to keep myself in check, too.)

a) Rules and processes have a place, even if you choose to forgo them. As a small business owner, you can get by with fewer rules and processes in place. In fact, in most cases you do much better when you're flexible. But larger businesses have a much harder time being flexible; it's not impossible, just much harder. They have to manage everything more strictly in order to hold together the larger whole. A little sloppiness in your store can be passed off as "charming." In a national chain where customers expect extreme tidiness and consistency, that sloppiness is not charm. It is chaotic, and it is poor business.

b) Not everyone enjoys the same latitude to call the shots as you do. You may be your own boss, but most people have someone else to answer to. I've found that being a business owner, seeing the bigger picture, and having the power to remedy things has turbocharged my ability to take the initiative, even after going back to working for someone else. Still, despite having passion for my line of work and understanding its larger implications, I have much less scope to make important decisions. In large companies, even CEOs don't wield absolute power, because they have a board of directors and shareholders to please.

c) You are not special, so don't expect special treatment. A couple of years ago, I received a parking ticket by mistake. I knew that I had moved my car in time, and so I decided that I would write in to contest it. One of my co-owners suggested that I take a tough stance and mention that I was a business owner — as if that had anything to do with my guilt or innocence. I mentioned it anyway, thinking that a little reminder about my contribution to the community wouldn't hurt. Still, I didn't want to rely on that mostly irrelevant fact, so I put much more effort into stating the facts of the case. I drew a diagram of where I had parked, when I had moved my car, when I had been ticketed, and why it was a mistake. In the end I got the ticket waived, but I have a good hunch it had more to do with stating the facts than mentioning that I was a "business owner."

Conceptual tools for allocating finite resources

noreply@blogger.com (Joshua Go) — Sun, 07 Dec 2008 03:39:00 +0000

I have lived and worked in Greater Los Angeles for over a year now. Since the area is one of the world's major population centers, it only makes sense that I'd come across plenty of opportunities to observe the interplay between two forces: lots of people and limited resources.

It's a common problem, but always a multifaceted one. Coming up with a solution means that planners (who could be church volunteers, business managers, or software engineers) must consider various factors. Having to stop and think about this can slow down decision making, and even when there's time to ponder and plan, thinking of a solution from scratch is more error-prone than referring to a proven set of guidelines and rules.

Pricing
Consider the situation when lots of people are elbowing each other to buy concert tickets. There's no increasing the supply of these tickets since a concert hall or stadium can only hold a set amount of people without the Los Angeles Fire Department throwing a hissy fit.

Many eager economics students and libertarians automatically want to apply the law of supply and demand here: why not just raise the prices? In fact, that's what some organizations have done: Britney Spears concert tickets for Staples Center start at $150.00. (How do I know this? My girlfriend told me. Really.)

As the purveyor of tickets, you can do that when you have some idea of how much demand there will be. But what if demand shoots up while your supply stays the same? When it looks like you're about to sell all your inventory and are hours away from turning away your customers and disappointing them, you could double your prices. But then, your customers would be angry that you're gouging them. Your company would appear disreputable for "arbitrarily" changing prices on consumers.

If you're looking at it from an economist's point of view, there's no problem there: you're just changing the price to meet demand. But from a public relations vantage point, you run a very real risk of alienating your customers. It'll look like you're exploiting them, when all you're doing is ensuring availability (while making a few extra bucks).

On top of that potential PR nightmare, there's a downside that even economists must acknowledge. It's the phenomenon that economists call "sacrificing equity for the sake of efficiency." That's all fine and high-sounding, but what does that mean? It means, "It's not fair." And the customer will feel this way. Your costs haven't changed: it still costs you the same to make it, doesn't it? This gives your customers a reason not to trust you, and therefore not to come back.

Changing your prices is certainly an effective tool to curb or increase demand, but raising them is an extremely delicate matter in the age of consumers who expect posted prices to stay the same.

Waiting list: first come, first served
A common alternative to raising prices is to let people buy stuff on a first come, first served basis. The folks at Ticketmaster do this, in case the $150.00 concert tickets sell out (which they often do).

As you may recall from your economics class, this is considered more equitable, but not as efficient: the people selling tickets could make a lot more money just by raising the prices. (If you do not recall from your economics class, shame on you for not paying attention. But hey, now you know. Trust me on this one.)

As far as fairness is concerned, lower prices with waiting lists are an improvement over simply raising the price. But if you're not one of the first served, you probably won't feel like it was very fair. Maybe you had to be at work that time of day, or don't have time to wait in line.

Lottery
A different spin on fairness is to let people enter a lottery to let them buy what they want at lower prices. If you were to enter such a lottery and your number got drawn, you could then buy what you're after. Typically, submissions to this lottery are accepted during a specified time window. So if you have to be at work when the lottery first opens, that's not a problem. You have just as good of a chance as the first person who entered that lottery.

This was part of Saddleback Church's approach when they hosted the Saddleback Civil Forum with Barack Obama and John McCain during the presidential campaign. Since Saddleback Church is very high-profile, it was important that a purely pricing-based model was avoided. Taking an exclusively pricing-based allocation of tickets to see the candidates would have looked too much like favoritism towards the rich, a Biblical no-no.

Then again, Saddleback Church also had to cover its costs, so it actually opted for a brilliant hybrid approach that consisted of various tiers, each with a different price. It was a multi-tiered lottery. Higher-priced tiers would likely yield a smaller pool and a higher chance of being selected. You can't please everybody, but such a creative and enlightened approach likely pleased quite a few free market die-hards while at the same time placating those who were concerned about equality. If only governments and businesses were as wise.

Look where you're baby stepping

noreply@blogger.com (Joshua Go) — Sat, 25 Oct 2008 22:59:00 +0000

When you're starting out from scratch, it's hard to predict what you're going to need. I just moved into a new apartment, and my kitchen cupboards are empty because I've decided that I'm not going to even try to predict what I might need in the future. The way I intend to re-acquire the supplies I'll need is by doing stuff.

I mean, sure, there's cooking oil, salt, and pepper. But for a little more exotic Chinese cooking, I'll need some sesame oil or star anise. Beyond the basics that I'm certain I'm going to actually use, it's impossible to predict what other odds and ends I will personally end up using. And soliciting advice from others in the past hasn't been good for me: what works for other people often does not work for me.

For me, the only way I have been able to know — with certainty — what I'll need is to actually start trying to do things. If I'm trying to figure out which ingredients I'll need to cook a meal, I just start trying to cook. If anything is missing, its absence becomes readily apparent.

These are kind of like kitchen use cases, if we're going to resort to software development parlance. It's like I'm going agile, or adopting Test Driven Development with my cooking processes. I could theoretically start out with nothing at all — to illustrate the method theoretically, I actually should start from nothing. I would soon find that I need a cutting board, a knife, and whatever ingredients my recipe calls for. For a basic meal I would also find that cooking oil, salt, and pepper come in handy.

After cooking a basic meal, I know with confidence that I have everything I need to cook — wait for it — a basic meal. That common use case is taken care of and I can cook basic meals in the future with confidence. Now, what if I were to go ethnic? I'd soon run into some cases where I'd need to stop and get some more ingredients.

The idea is that, after a while, I would eventually be able to confidently prepare a broad range of meals. This confidence is rooted in the knowledge that I have verified that I have everything needed — by actually having done it in the past.

Of course, it's possible to carry out this kind of method to absurd extremes. If you know for sure you're going to need it, then make a note and take care of it. Be reasonable in what decisions you leave for later and which ones you can make now. In the cooking example, it's great for didactic purposes to start from scratch, but in practice it's dumb not to have the basics like cooking oil or a cutting board.

What about when developing software? You can leave scalability concerns for later if you're just starting to write a web application, but no matter what, you are going to need a machine and a relational database. (If you're writing something, like an offload server, because it needs to be scalable, then you damn well better take scalability into account.) To maintain your sanity, it might even help to sketch out a data model. Take baby steps, but know where each step will end. Don't be content with merely knowing that your foot will be in the air and then end up somewhere on the ground at some point. After all, this nebulous "goal" can just as easily be achieved by tripping and falling.

Getting more out of a sentence

noreply@blogger.com (Joshua Go) — Fri, 19 Sep 2008 06:18:00 +0000

There's a very simple, effective, and systematic way to amp up the amount of insight you get from the things that you read.

It's probably best to explain with an example. The following is from Ed Catmull's article for the Harvard Business Review, "How Pixar Fosters Collective Creativity."

We must constantly challenge all of our assumptions and search for the flaws that could destroy our culture.

How much thought can this spark in your mind?

If we just read this sentence several times, each time with an emphasis on only one word, we get a new angle on the general idea being conveyed. Something different is emphasized.

We must constantly challenge all of our assumptions and search for the flaws that could destroy our culture.

The emphasis is on the we. This tells me that whatever this sentence is talking about involves a team effort. Everyone on the team must be involved. It's a "we" rather than a "me." But does that necessarily have to be the case? It starts with somebody, right? Why not with individuals?

It's okay — a good sign, even — to ask questions about the truth or applicability of a passage. If you're a reader with a healthy sense of skepticism, those kinds of questions immediately arise. A lot of the same questions will come up: is it necessarily so? Is it true all the time? The more you ask these kinds of questions, the more you hash things out and figure them out for yourself.

Let's look at another word.

We must constantly challenge all of our assumptions and search for the flaws that could destroy our culture.

This time, the emphasis is on the word "search." This tells me that the flaws are often hidden; otherwise, they wouldn't require searching. Now, I'm an imaginative guy, so then I imagine myself searching frantically and then getting tired or discouraged. When I'm tired or discouraged, I ask questions. Why am I searching, anyway? What exactly am I searching for, again? How do I really know when I've found it?

That's only two words, and I could go on for a while, but I think the general method has been made clear. The biggest plus going for this method is that it is systematic; I can just emphasize each word until I'm plumb out of new thoughts. When I'm done with all the words in the sentence, I know I'm done.

Personally, I've found that this process also helps me internalize ideas. Even if I don't remember the exact wording of a sentence, the dance of thoughts anchored around a single idea tends to leave a lasting impression. I imagine this is because the thoughts that come to mind immediately tend to be those of the most concern to me. When it comes to things that truly concern me, I have an easy time remembering.

Ruby on Rails: optimizing a slow-rendering page

noreply@blogger.com (Joshua Go) — Thu, 18 Sep 2008 05:27:00 +0000

Recently at work, I was faced with the problem of fixing a slow-rendering page. The page is part of an internal content management system, where the content includes video, images, and text. We have over a thousand pieces of content being managed with this tool and the slow page was a listing of all the content along with key overview-type information for each content package.

Everyone was fine with this page loading slowly, since we knew that there was a lot of content. The problem arose when the page would only show around 50 items and then stop loading; the server configuration was set to automatically stop requests that took too long to process.

I knew that the best course of action would be to start measuring. I took a look at the logs to see how long the request was taking and the approximate tasks where time was being spent. At JibJab, we take pride in caching the hell out of everything. Only a tiny fraction of time was spent hitting memcached. And it looked as though memcached was doing its job: almost no time was spent hitting the database. But a ridiculous percentage of the time was spent "rendering" the page.

That meant the onus was on my code to speed things up. Since the slowdown had become more and more apparent as we added more content, my guess was that the loop was the main source of the problem. Anything that would be only a tiny bit slow on its own would lead to a delay over a thousand times greater.

The first thing I removed was a call to cycle(), which I was using to zebra-stripe the table display for easier reading. In its place, I put in an index variable that would be modulo-two to determine its index into an array of two choices (even row or odd row). To keep the same feature, I had to dirty up my code if I wanted it to run more quickly. And indeed that shaved off about one-fourth of the rendering time.

But the page was still taking over ten seconds to render, so I continued my hunt. A pattern I saw many times within each iteration of the loop was an old friend, link_to. I am not terribly attached to this particular friend, however, so I got rid of it and replaced it with some good old <a> tags, which bought me a good second or two.

So far, I felt pretty good about what I had been able to do to extract render-time savings. But there was still room to shave the time down, and luckily for me, Inflector.humanize was being called in each iteration like there was no tomorrow. I decided that there indeed would be no tomorrow for these expensive-looking helpers, and after removing all five calls inside the loop, I got total render time down to a very respectable two-second neighborhood.

The lesson learned? Sometimes code has to be a little messier so it can be fast enough to be used. Specifically, watch out for those beautiful-seeming Rails helper functions; they do a lot of work for you, but sometimes you're just better off doing the work yourself.

Bilateral versus multilateral trade agreements

noreply@blogger.com (Joshua Go) — Wed, 17 Sep 2008 06:14:00 +0000

News sources everywhere seem to lament the collapse of the Doha round of trade talks because countries would then have to resort to bilateral or regional trade agreements. For any supporter of free trade this would be understandable, but if we acknowledge the short term havoc wreaked by rapid changes to trade flows that do not give workers and business owners time to adjust, a gradual and stepwise approach to the opening up of markets seems to be a more prudent way to go.

One of the major problems cited by those who favor a broad trade policy is the inconvenience of having to keep track of different rules for different countries. I would go about solving this by building a hash table of trade rules. Basically it would mean that given a country and a product as input, we would get the policies regarding that product as output. This would be a large table, but we would ask and receive only what we are interested in.

There's also the advantage of isolated policies having limited effects, rather than opening up to the entire world in one go. Maybe there is something I'm overlooking, but I don't consider the use of bilateral agreements to be an indicator of failure. I see great potential for reaping the benefits of free trade with less of the shock typically expected by any opening up.

The collapse of grand schemes for international trade deals is really a familiar scenario that just happens to be playing out on a macro level: a project's planners have decided that they have bitten off more than they can chew, and decide to reduce the scope of the project. Everyone does this, and while we may feel disappointed at envisioning the results of the grand project and having to instead settle for something less, we eventually resign ourselves to the reality that we are doing all that we can, and it is a whole lot better than nothing at all.

Colored bash prompt

noreply@blogger.com (Joshua Go) — Thu, 04 Sep 2008 23:53:00 +0000

The following will set a bash prompt to highlight the name of the directory in yellow, and in bold.

export PS1="[\u@\h \[\033[1;33m\]\w\[\033[0m\]]$ "

This will also work:

export PS1='[\u@\h \[\e[1;33m\]\w\[\e[0m\]]$ '

The escapes have to be in single quotes, however.

During a previous attempt, I wasn't terminating everything correctly, and so when my command exceeded the length of the row, it wouldn't wrap around and start a new line. It was not just a Mac OS X Terminal problem; I tried it in rxvt (installed via MacPorts) as well as the xterm that came standard with Leopard's X11.

Doctors and programmers

noreply@blogger.com (Joshua Go) — Thu, 04 Sep 2008 06:15:00 +0000

One evening, I was watching Mystery Diagnosis on the Discovery Health Channel with my brother. The show is about people who have strange ailments, but doctors can't figure them out.

It got me to thinking about how people in my profession approach problem solving. The approach that computer programmers take is up to us, and it's pretty open-ended, but it's widely agreed that we use measuring tools — debuggers and profilers — to examine whether each little step is doing what it's supposed to be doing. It's also a widely accepted quip that one should never try to guess where a slowdown or a bug is happening, because one is usually wrong about it.

But that sort of guessing without detailed measuring seemed to be exactly what the doctors were doing. For one guy, they drew blood sample after blood sample, but it turned out to be a problem on the genetic level.

I wonder if there's some level of professional ego that keeps doctors from doing what would otherwise be considered sensible. If it took a lot of lobbying to get them to use checklists, I wouldn't be surprised if they think they've gone through too much training to actually rely on detailed measurements.

To be fair, though, doctors probably don't have much scope to apply deductive reasoning on the entirety of the systems they're working on. There are no "development" or "testing" patients where it's okay to mess up and start over. Everything they work on is in live production mode.

Freeways that trick you

noreply@blogger.com (Joshua Go) — Fri, 29 Aug 2008 07:54:00 +0000

I don't like it when freeways trick me.

There's I-10 west into downtown LA, when it splits off to US-101 and I-5. Six lanes of I-10 turn into a single pathetic lane if you want to stay on it to keep going to Santa Monica. Most of the rest goes to US-101. Context over consistency, to serve the massive hordes going to Hollywood? Perhaps. But this is the mighty I-10 freeway, encompassing the width of the country and passing through Phoenix, San Antonio, Houston, New Orleans, and Jacksonville. It's not some little country road in the middle of nowhere. Someone should tell this freeway, "Hey, you're not done yet. You reached LA, but the real end is Santa Monica."

And then there's I-5 north to SR22 west in Santa Ana. When you're driving on I-5 and you choose the "Exit Only" lane to switch freeways, you should be rewarded for your dedication. But it is not like that at all. It really does mean "Exit Only" — and not to switch freeways. It takes you off the freeway and you have to switch into the other lane if you want to get on SR22 west to Long Beach. Well, you must be saying, it does say "Exit Only" so what were you expecting? Well, says I, it's clearly marked SR22 west to Long Beach, while it should really be marked as a regular exit, not a way to switch freeways.

Meetings are not always toxic

noreply@blogger.com (Joshua Go) — Thu, 28 Aug 2008 05:14:00 +0000

I'm a big fan of 37signals in general, but I remember a time when I went a little overboard with youthful zealotry for one of their philosophical tenets: meetings are toxic.

Back then, my business partner Steve and I had just landed our first major client, and this client asked for a kick-off meeting.

I curtly dismissed it, telling them I didn't need a meeting — leaving them baffled with my strange behavior (and Steve smacking his forehead).

Since then, I've found kick-off meetings with partner companies and clients to be crucial for greasing the wheels of personal exchange. It gets people talking to each other, which is worth pursuing because cross-company communication is a tricky thing. Plus, the stakes are higher: if you have to coordinate with another company, chances are that you're working on something pretty important. I've found in the vast majority of cases that it doesn't take extensive preparation to the standard I would expect of myself if I were to prepare for an intra-company meeting. People just like to talk and get a feel for each other. If meetings and conference calls are good for anything, they at least open up the communications channels.

After thinking about it for a bit, I realized that I initially learned to conduct business in a contrarian way, since I got most of my tips from the Web. But since then I've begun incorporating more traditional business practices because that's how most people still do business. I have a hunch that most people still do business "the old way" because it works.

Am I anxious that I could be blindly following new ideologies or anything that remotely seems to make sense, to my detriment? Would I have been better off doing business the traditional way and then finding out about these counter-cultural methods? I don't think so. Whichever end of the spectrum I may have started on, the important thing is to continually evaluate the merits of each idea I encounter, whether old or new, and knowing why I do things the way I do. The truth lies somewhere in the middle, and it's reachable starting from either side.

The introverted leader

noreply@blogger.com (Joshua Go) — Sun, 24 Aug 2008 20:27:00 +0000

During the course of my two years attending Discovery Christian Church in Davis, I had the chance on several occasions to eat lunch with the pastors, namely Aaron Brockett and John Richert.

I still remember the most surprising thing that Aaron ever mentioned to me. He said that a lot of the leaders at Discovery, himself and John included, were natural introverts. From the outside, it seemed that they were anything but.

They greeted people left and right, confidently gave their sermons, and coordinated the big picture very smoothly. One of the things that caught my attention at the beginning, and subsequently hooked me in to attending regularly, was how the services on Sunday were so well-run.

As for me, I have found that I am quite happy to be a follower, unless there is a leadership vacuum — either no leadership at all, or very poor leadership. To be fair, I've found that very poor leadership can come from both extroverts and introverts.

In extroverts, the leadership pitfalls have to do with the tendency to make decisions without thinking very hard about them; not being aware of how everyone else feels; or not stopping to ask what everyone else thinks.

With introverts, what I've observed includes the lack of dynamism to keep everyone interested; indecisiveness while trying too hard or too long to build a consensus; and a lack of forcefulness.

Being the introvert that I am, I naturally got to thinking. What, I asked myself, can I do to leverage my natural strengths while avoiding the pitfalls of my natural weaknesses?

My natural strengths are things which come easily to me: thoroughness in exploring issues; attention to detail and a concern for total correctness; and having a passion for learning new things on my own, which makes it easy to become knowledgeable in various areas. I see these kinds of traits as "hard-wired" where my thirst for knowledge or obsession with detail give rise to good things. Like a microprocessor is hard-wired to perform basic operations like addition and subtraction, I'm hard-wired to do certain things because I'm comfortable with them and I know how to do them.

But the desirable traits that extroverts possess that I don't have — outspokenness, dynamism, gregariousness, forcefulness — I have to run them in emulation mode. I have to figure out some software to run on what's hard-wired in me so that I can do pretty much the same thing. Software operations are slower and require more instructions than hardware-level instructions. If we're going to continue carrying our analogy over to people, this means that I've got to put more effort into expressing qualities that are generally characteristic of natural extroverts.

But it's possible to do so, and this is good news.

For the introvert, it just takes a lot of piecing together. For example, the extrovert can just "be forceful," while the introvert has several mental steps to take. First, he must recognize that forcefulness will be necessary to avoid wasting everyone's time, and it's better for everyone. Then, he must double-check that the position he is strongly advocating is correct, because he knows his confidence in a position relies on knowing that it is as correct as can be, given all the data. Then there's recognizing that the best that anybody can do is make a decision based on all available information, and that's really the most that we can do. There is no sense in second-guessing since more information is not available. Finally, there's actually saying what needs to be said, or acting out what needs to be done. This requires a conscious mental step for the natural introvert.

As anyone can see, it can be much more involved for an introvert to display extroverted qualities, but it is possible. Over time, the basic behaviors can be optimized and moved a little closer to being hard-wired, just as software can be extracted into microcode to sit somewhere between software and hardware. This way it runs more quickly and more readily, with less effort.

There's one last thing before I completely beat the dead horse of this analogy: even though things done in hardware run much more quickly than those which are run at the software level, the software level allows for much more richness and flexibility. What does this mean for natural introverts who are looking to be effective leaders?

My very introverted answer is that I don't know; I'm still trying to find out.

Where software developers fear to tread, or why open source fails

noreply@blogger.com (Joshua Go) — Sat, 09 Aug 2008 06:08:00 +0000

Open source has had its triumphs and failures.

The most notable wins include Eclipse, Linux, Apache HTTP server, MySQL, and Mozilla Firefox. Developer tools and server software are generally areas of strength for open source. I wouldn't say that Mozilla Firefox is an anomaly. Rather, it shares something in common with developer tools and server software: the programmers who work on it are also its users.

Unfortunately, this is not the case with the gaps that open source has so far failed to close. A friend of mine recently asked me about my choice of spreadsheet software. We talked about it for a bit, and agreed that OpenOffice.org Calc is still clunky. I suggested Gnumeric, but I don't really hear anything notable going on with it these days. In short, I don't see an Excel killer in either of these. It's not for lack of vision that these spreadsheet projects have stagnated. It's for lack of sustained passion and developer interest in making these products world-class. Rather than get deep into using these spreadsheet packages, I often just resort to SQL queries and image generation libraries if I need a chart. And I'm guessing that other developers have also resorted to what was more familiar and efficient, given their esoteric knowledge of more powerful tools.

It's obvious to many of us that successful open source projects are characterized by programmers who are also users, but I would go a step further and say that the programmers must not merely be users; they must be the power users. There are two ways that a programmer could be a power user of his own software: out of enjoyment or out of necessity.

Open source software developers should be the power users of their own software. This sustains the passion to "scratch the itch" and fix bugs to produce polish. With proprietary software, programmers have the benefit of separate QA teams or product managers. In open source, it's overwhelmingly the case that they do not.

It's been said that with enough eyes, all bugs are shallow, but it's quite often the case that not all of the mouths will bother to report what the eyes are seeing.