Friday, March 08, 2013


My morning commute.
There's a magic in this city of millions
when I'm the only one.

Saturday, December 29, 2012

Thumbs will fall

I've been at a keyboard for several hours a day since I was 10. I take ergonomics very seriously and have spent a fair amount of time researching repetitive stress injuries and the prevention and rehabilitation thereof.

...which is why it comes as somewhat of an embarrassment to me that my smartphone caught me off guard. I've a repetitive stress injury. Turns out my injury has a name, and that name is BlackBerry thumb.

I came late to the cell phone game. My first smartphone was acquired a year ago. It has introduced me to a wonderful world of swiping and swishing and poking and pinching and let's not forget incredibly infuriating but sufficiently useful typing.

My injury is not severe. It is in its early stages and I can repair it by building the muscles on the outside of my thumbs... But only if I put down the phone.

I'm typing this on an iPad. The keyboard is pretty nice... Not great, but leaps and bounds ahead of smartphone keyboards. But I can feel my wrists and fingers complaining in their awkward crowded pose hovered above the tablet.

And you know... The ergonomics of these mobile devices are nightmarish! These brilliant little gadgets which are amazing in so many ways.. Are hurting people. And they're spreading. They're invading. Thumbs will fall.

Monday, September 24, 2012

For No One

Last Friday, I sought out some music to listen to while I wrote code. I opened up Google Music and chose the Revolver album. Shuffle was enabled from my previous session, so it began to play mid-album. That's fine, I wanted it to loop -- I quickly disabled shuffle, enabled repeat, and started coding. This was at 12:53PM.

At 5:00 pm, I stopped coding. (Lovely day!)
At this point I realized that For No One was still playing... Ah! I had mistakenly selected 'repeat 1'.

"For No One" is 2:03 long.
I listened to it for 4 hours and 7 minutes.
247 Minutes you see nothing
14820 Seconds behind the tears
120 Iterations cried for no one
a love that should have lasted years

Thursday, July 12, 2012

Please fix all the things

Every now and then I get to play with a piece of beta software.  The scope of the software can range from a prototype feature to an already-shipped MVP.

Software has bugs, it’s a thing that happens – no big deal.  When I find a bug, I decide what to do with it based on a state-of-readiness indication that I’m reading from the software.  I’m feeling for one of two things:

1. An indication that the product is still in-the-works and that bugs should be expected and ignored.


2. An indication that the product is expected to be working correctly and that any discovered bugs are probably unknown to the developers and should be reported.

There are lots of ways for a piece of software to hint at which of these two states (if either) it is currently trying to be in. 

My favorite subtle way to distinguish between the two (even on a component-by-component basis) is to leave poorly functional components in an unstyled state.  Joel goes into detail on this but the core of it is that pretty things are expected to work awesomely, and ugly things are expected to suck.

While subtlety is fun, there’s also nothing wrong with just coming out and saying it.  I’ve used plenty of software that’d had a big friendly “Click here to report bugs and give feedback” button, and that type of message very clearly communicates which camp we’re in.

Don’t get the two mixed up.  So long as you’re declaring yourself in camp #1, I’m not focusing on the bugs—the bugs are assumed to exist.  I’m focusing on what it *can* do and I’m ready to be delighted.

The moment you declare yourself in camp #2, you’re stating to me that this product will work as advertised.  I’m no longer scanning for things to be delighted by when they work,  I’m now assuming that things work and scanning for things to be upset about when they don’t.

teapotI’ve found that in general I can submit the lesser of about 25 detailed bug reports a day or about 5 reports per hour.  If I exceed that number, I go insane. I irrationally conclude that every aspect of the software is terrible, the person who made the software is clearly malicious, and that the fact that I’ve spent any time at all submitting bug reports is a travesty because clearly the developer knows about the bugs already and has irresponsibly chosen to inflict them on me rather than making their product halfway decent.

This is an overreaction.  It’s emotional, it’s cynical, and it’s not logically sound.  But I know that I’m not alone in having a bug-reporting fuse.  If you put a new piece of software in front of me and I start playing with it, I’ve got the energy to provide a certain amount of feedback before I stop caring.  At the moment I stop caring, I’ve come to accept what the software is and what I can expect from it.

While I’m setting those expectations, you get the chance to set up a lens through which I start viewing all of my interactions with your software.  If you manage to delight me, then your actions will have a rosy glow and I’ll give you the benefit of the doubt where I can.  If you frustrate me,  I will curse your software every single time I get a paper cut.  You’ll get reports from me that the “text highlighting of timeline events doesn’t match standard browser behavior” in spite of the fact that nobody could ever possibly care about this…  but hey look it’s another instance of something you did wrong and you’re going to know about it. I’m going to tell you about it because I want you to know that you hurt my feelings.

…But your software isn’t terrible, I’ve just hit more than 5 bugs in the last hour and my fuse is burnt out.  The software is actually pretty good.  Too bad I’m going to avoid it.

I have an alternate solution to all of this that I’d like to learn how to use.  I’d like for it to be acceptable for me to send you a bug report that says “Please fix all the things.” 

I understand that this bug report sounds like it’s perhaps the most general and useless of all possible reports you can receive,  but what I want it to mean is “Please step back from whatever you’re doing and just take a few moments to use your software.  It’s kind of busted.  You’ve reverted from #2 to #1, but you’re still advertising a #2.  Please let me know once you can use it for a solid minute without encountering a bug and we can move forward again.”

Wednesday, June 06, 2012

the glory of mobile

I've been hesitant to commit for a long time. Typing into a smartphone is hell. Editing is hell. Speed is hell. Typos will exist. I resisted composing more than one-liners because doing so was hell. But sometimes hell can be better. Angry birds is less hell than writing email, but nothing comes of it. Phones can help recover those stolen moments. Use them to produce. I have a 3 minute subway commute. Every day, i spend those minutes writing email to my friends. They're short. They have typos. But they outproduce GLTron. Reclaim your stolen moments with something meaningful, no matter how small. If a smile can come of it, you succeed. Sometimes a blog post will come of it instead.

Tuesday, March 06, 2012

Decomposing problems

Task decomposition is a very useful skill. I realize that I've been explicitly taught to use it in many different contexts by many different sources over the course of my life.

Large iron skillet over low heat, splash of oil (olive is fine, sesame is best)

The earliest examples I can think of all had to do with solving puzzles in video games. I remember figuring out that if you could understand some small part of the system, like Towers of Hanoi, the other parts of the system would rapidly become less daunting. Further, if you could internalize some small parts of a system so that you could just accept their function, you could think about the other components at higher level of abstraction.

Crack two eggs into the skillet, scramble them.

I think some part of me has been slowly learning how to generalize my problem decomposition skills, but in general each new context presents its new set of unintuitive challenges. Taxes, for instance, I haven't internalized how to decompose. It's obvious at some level: Complete part of the tax return now. Complete a different part later. Keep doing this, and soon you'll be done. But I'm not ready to start yet-- If I receive any additional bits of tax info in the mail, I'll need to repeat some work. It'll be easier for me to wait to the last minute and do it all at once.

Remove eggs from skillet, set aside.

I'm generalizing a bit, but what I'm getting at is that I don't have an intuitive understanding of the best way to do my taxes. There is no small component of my tax return that I can work on which I can be confident that I won't have to rework later... As such, I'd rather just do the thing as a whole.

Medium heat, splash of oil.

There's a refrigerator in my office which needs to be transported to my apartment. I find that I'm paralyzed in a similar manner-- I don't see any incremental step I can take. At some point, I'll rent a vehicle or call a person with a vehicle and hope that all of the events that could take place between my office door and my apartment door will work out in my favor. I can't really predict them, so I need to do this on a day when I'm able to devote myself to handling contingencies. That's a greater-than-bite-sized hurdle.

Dice half-block tofu, fry and stir until all sides are goldening.

My approach is totally different when it comes to software. If you give me a feature to implement, no matter how small, I'm going to start by writing a spec. Yup, I just said that. The spec might just be a sentence. Or a paragraph. Or a few paragraphs with pictures. If it's bigger than that, I'm going to first see if it's actually worth the time to write this spec. When I've finished the spec, I now know if the current design actually solves what it's trying to, if it handles everything it needs to, and if I should even bother implementing it. More often than not, after writing out the spec I end up with a design that's both more functional, makes more sense, and took less time to implement.

Remove tofu from skillet, set aside.

...So why do I write specs before writing software, but not before moving refrigerators or filing taxes? Some might argue that software tends to be more complicated than moving refrigerators or filing taxes, but that's not really the case for me. I'm less intimidated by writing software than moving refrigerators.

Repeat with other core ingredients, such as onions or chicken.. set them aside.

My favorite idea right now is to buy a handcart and wheel the fridge home over the Brooklyn Bridge. Sure, it'd be tiring and hard, but it'd be a grand adventure. People would take pictures of me wheeling a refrigerator over the Brooklyn Bridge. The thing I like most about this idea is that I can decompose it really easily: 1. buy hand cart, 2., put refrigerator on hand cart, 3., walk it over the Brooklyn Bridge. I realize that's a little bit like "Turn left at Bayfront Hwy, Turn right at Waianuenue Ave., kayak across the pacific ocean..", but it's very conceptually comfortable.

Big splash of oil, give it a minute.

I suppose with software, it's easy for me to logically separate different components in my head. The blorker can be trusted to blork, the flnger can be trusted to flng, and the dolber is just a flngerblorker then a blorkerflnger, so clearly the dolberblorker is what we want here. That was a totally meaningless and whimsical-only-to-me example, but that's alright.

Spread precooked rice over bottom of skillet.

Lots of tasks that I've found daunting, I've eventually solved by figuring out how to tear them apart. Once I could do that, I could work on components in isolation and not worry about oh-dear-god-how-the-hell-will-I-ever-finish-this-thesis as I played with the graphs in one section. "Did you work on your thesis tonight?", "Yes! I finished that graph."

Stir rice, collect into large mound, then spread over bottom of skillet. Repeat until rice starts to brown and crispify.

When I was in college, I posed the question to my game development group: "How can we make a mundane task such as loading and unloading the dishwasher into a compelling, fun, interesting game?" I was quickly told that that was a stupid idea and it was largely dismissed. One person googled it and was quick to tell me that actually dishwasher loading/unloading is a serious sport in some particularly dull countries. Google isn't finding similar gems for me, so I can only assume that this was the sport he had in mind.

Add 2 tbsp shoyu, 1 tbsp rice vinegar, diced garlic, minced ginger, peas, carrots, corn, chives.

I challenge their skepticism. I think that I could gameify dishwasher loading/unloading. I'm not so sure I could make it a meaningful game-- that is, it probably wouldn't enhance your life outside of the scope of loading and unloading dishwashers. Thinking of the over-the-top dishwasher gameification elements that could exist, though.... Achievement Unlocked: Five-Finger Fillet

Fry and stir until all ingredients hot, remove from heat and serve.

I find that I'm consistently astonished by how seemingly unconquerable things become simple once the decompositional trick is figured out. One of my favorite things to cook nowadays involves combining a large collection of ingredients which all have very different cooking needs. I'm usually able to cook whatever I want by progressively adding ingredients to my recipe at appropriate timings so that they all receive the amount of time in heat that they need. That doesn't work for all recipes, though-- you really need to scramble the eggs and fry the tofu independently and add them back in later if you want it to taste right.

Add additional shoyu to taste.

Tuesday, February 07, 2012

Hard software problems

Lately I’ve been thinking a lot about how I could build software to solve really hard problems.

Recently Y Combinator put out a call to kill Hollywood.  I agree with the principle…  but this is not a particularly hard problem.

Let’s talk about something hard.

Let’s use software to stop rape.

I don’t know how to do this, but we can do better.

I think I can write a mobile app which can detect when someone is being assaulted and automatically phone for help. 

I think I can write buddy-system-like app which can connect solo girls with trustworthy strangers at bars who can walk them home. 

Let’s use software to stop suicide.

I don’t know how to do this, but we can do better.

Reddit has created a beautiful thing.  Go there now.  If you don’t come back, that’s fine… it happens.

I searched for Suicide Hotline in the Android App Market.  The offerings are weak. How about a decent Suicide Hotline app?  It’s really simple:  Your app’s icon says “help”, and when you push it you get to a screen that says “You’re ok. We’re here for you.” and there’s a single button which calls your local suicide hotline.

Let’s use software to stop child abduction.

I don’t know how to do this, but we can do better.

More and more kids today have cell phones.  Let’s make an app which works like this:  Every 30 seconds, your phone will chirp to other phones in the area.  If someone goes missing,  track the last known locations of the person and contact all of the witnesses.



My ideas so far are all just attacking the low-hanging fruit.  They’re mobile-centric because that’s what I happened to come up with. There are better solutions and bigger things to investigate.  These are hard problems, and let’s be honest- my ideas suck.  But even though they suck, they could make a difference.  I find that both sad and inspiring.  It’s feasible that a weekend project could save a life.  There’s no need to get Orwellian, let’s just work on these.  What are you doing next weekend?