Joshua Go

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 ...

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 memcache...

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 effec...

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.

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 co...