Friday, March 08, 2013

Footprints



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.

or

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.

Sunday, March 04, 2012

Reliving sunsets

Taking everything you know now,  if you could go back in time to the final days of your first meaningful relationship, how would you behave? What would you do differently?  Could you act the same as before if you tried?

Here’s my response.

 

Last night I dreamt of the final two days of my first relationship, lived in reverse, augmented with everything I know now.

The second day I had less control over.  I became aware as I stood in the airport security line.  As it truly happened, we had one of those Meet-Joe-Black moments of both repeatedly walking away, stopping, looking back, and seeing the other person walking away.   I knew better this time… I just stood there. I put my hand on the glass and waited for her to turn around. I caught a final smile.

Then time skipped back again.  It was the day before,  our final real day together, and I was aware.  My first priority was to prolong it—I wanted her to stay with me that night instead of going home:  I had too much to talk about and not enough time to talk about it.  If we could talk for the next 30 hours until my flight came, that would be best.

That was hard to do, but I succeeded. …and then I fell silent.  I hugged her and started pondering.  I ran though a monologue in my head:

“This is ok.  We’re watching a sunset now, and it’s about to go very dark.  But it’s ok, because things are so beautiful. Darkness holds monsters and scary sounds, but there are a lot of other people wandering around in it, and those people are good.  You’re going to go on to find someone who suits you better than me.  I’m going to go on to do things that I really need to do.  The next person I find will be in a lot of pain, like me, and we’ll make things better.  You’re stronger now than she will be, so ultimately it’s more important that I go on to be with her.  She’ll eventually leave me for an upstanding Christian fellow, but that’s fine.  Someone more suited to me will find me soon.

In time we’ll both leave flowers on the mandala at Strawberry Fields, just not at quite the same moment. We’ve created lights in the darkness for each other. We’ll both go on to find sunshine, but if either of us face another sunset it won’t be quite as scary.”

…  And then I edited.   I’m talking about myself too much, and that needn’t happen.  I’m trying to explain, but this is future-me talking to teenage-her.  Teenage-me would love to hear my spiel, but that’s not what’s up here.  Edit it down…

“This will be ok.  We are going to lose each other, but I promise you’ll be better for it.  We’ll both go on to be amazed at how small the world is, and we’ll both go on to exist in it.”

… Another pass…

“This will be ok.”

… And another…

“…”

And so I stood in my dream.  I convinced her to stay up all night with me so we could talk, and then I just held her silently. 

 

I woke then, and I started analyzing.  Perhaps “Buy Apple now, sell it all to buy as much Google as you can when they IPO,  sell Google at $600 and go back to Apple, and when you start hearing the words “housing crisis” take everything you have and short the banks.”   I considered that my reasons for leaving her at all were moot now that I have my current technical skills.  I don’t really need to go through college again, but there’s people that I feel obliged to go meet. I suppose I could go on to meet a different batch of people… that might be ok.  But gosh, what if I stayed and we went on to learn that we’re not compatible in a household?  I mean, we’ll get into stupid arguments about dishes and laundry….

I concluded that life has sunsets.  Each is unique, each has its own beauty, and each might hurt.  They’re important.  They herald the darkness in which we all learn to be nightwalkers.  You get better at navigating by stars, and you get better at greeting the dawn.