Eee Pad Thoughts

A few days ago, I got my Eee Pad Transformer. I guess you could say I didn’t get the Transformer part, because I only got the tablet part without the accompanying keyboard. So far, I’m loving it. It’s a very convenient size, the screen is gorgeous, performance and battery life seem excellent. I’ve had to spend some time getting used to Android, but so far I like that too. There’s also something much more satisfying about interacting by touch than through a keyboard and/or mouse, but maybe that’s just novelty. Here are some of the apps I’ve been using.

  • Built-in mail client. Not bad, so far it seems much better than the one that’s on my (non-Snow Leopard) Mac.
  • Seesmic for Twitter. I tried a few others, but none offered the combination of features I want. Twimbow for Android would rock.
  • Mobo Player (plus codecs) for playing unconverted video. I’m never going back to watching video on my iPad Touch while I exercise. Having a screen this large, but flat enough to put on the elliptical’s console, is fantastic. Playback has been smooth as butter, too.
  • ConnectBot (ssh client), plus Hacker’s Keyboard so I can have control keys.
  • Dungeon Defender. Yeah, I got this for entertainment as well as work.
  • Google Reader, Calendar, etc. through the browser.

All of this software was easily installed from the app market, and cost me zero. The ASUS on-screen keyboard seems a little nicer than the stock Android one, and it seems to suffice for short messages, but I don’t think I’d want to sit through an extended session of trying to use bash and vi that way. If I wanted to take this as my sole computer on a trip, I’d definitely get the keyboard – not only for faster typing but for extended battery life as well. I’d probably want to get VPN and IRC clients as well, though to be honest I’ve gotten tired of VPN glitches so I’ve switched to doing everything through ssh tunnels and SOCKS proxies when I’m working from home (like now) so maybe I’d skip the VPN.

Overall, I’d say my initial impression has been very positive. Maybe I’ll check back in a month or two and tell people how it fares over the longer term.

Don’t Be a Jerk

Charles Hooper wrote an interesting article about Letting Tech People be Socially Inept, in response to a recent incident at ThisWebHost where a technical director got mad at a customer and deleted data. There’s so much wrong here that it’s hard to know where to begin. “Jules” at This* was totally in the wrong. Charles is also wrong when he says that every position is customer-facing. Some people can do really great work only interacting with one person – usually their boss – and referring to that one person as a “customer” seems rather facile to me. Most of all, though, the puntwits on Hacker News are wrong too.

Probably the most common theme in the HN responses is that high technical skill and eschewing social niceties are closely and necessarily related because they both involve pruning away extraneous detail to get to the heart of something complex. For example, the very first comment there refers to “seemingly-meaningless boilerplate and social grease that we call people skills” and sets the tone for many that follow. The problem I have with this is two-fold. First, a lot of the bad behavior I see from my colleagues has nothing to do with social niceties. Go look at How To Ruin a Project and you’ll see that many of the items listed there don’t have anything to do with social skills. You don’t need a fine understanding of social cues to realize it’s wrong to miss the point, focus on the trivial, or wage “guerilla warfare” against a decision you don’t like. Those things might well have social effects, but they’re wrong even for purely practical reasons as well.

My other objection to the “boilerplate and grease” meme is that social cues actually do serve a practical purpose. They help to identify how strongly someone holds a belief, and how much importance they attach to the subject. Without that information, it’s easy to waste enormous amounts of time fighting wars that didn’t really need to be fought, and sometimes that leaves little time or energy – or poisons the atmosphere – for the debates that really do need to occur. One of the real problems I see with my fellow techies is a general lack of perspective, proportion, or priority. People who fail to give or read cues regarding these three important factors are demonstrating a deficiency that can affect even the most purely technical decision making. Being socially inept is not just cosmetic; it has a real and tangible effect on overall competence.

That brings me to the second most common theme in the HN responses: Asperger’s Syndrome. I’ve known quite a few real Aspies. I’ve known even more people who self-diagnose or self-identify that way as an excuse for being lazy about social interaction, so I won’t claim that I’m that way myself, but I will say I’m close enough (as is visibly the case for most of the other males in my family) to understand the challenges they face. I understand the “gravity” that always pulls one’s thoughts inward, and I know the pain of having to pull one’s attention away to deal with the “noise” that other people can generate. I will gladly do everything I can to accommodate people for whom these burdens truly are greater. I’ll teach them coping strategies I’ve learned from others, act as interpreter, run interference for them, whatever. However, there’s a difference here. It’s one thing to have a hard time understanding social cues. It’s another thing to understand those cues perfectly well and use that knowledge to troll more effectively. It’s really not that hard to tell the difference between an Aspie and an asshole; those who throw spitballs from behind a shield meant for others are not only jerks but cowards as well.

My conclusion is that Charles was wrong about everyone being customer facing, but right about the more fundamental reality that we techies in general need to stop being such jerks. We need to stop enabling the jerks by applauding when they act in deliberately offensive ways on HN, on Twitter, in conference presentations, etc. We need to stop pretending that the combative style prevalent on HN or LKML is the best way to facilitate progress; there’s no empirical evidence that “culling the herd” or “honing one’s weapons” or other such bloody metaphors really apply. We need to stop encouraging young techies to expend their energy emulating those styles instead of developing real people skills. Social skills really do serve a useful purpose, and anyone can improve them. That doesn’t make you less technical; it makes you more adult.

Running an Open Source Project

I think a lot of medium-to-senior programmers think it would be cool to run their open-source project, particularly if they have chafed under the leadership of someone else on another project. I’m not going to say it’s not fun, but after having done this for a while I think a word of warning is in order. You’re going to spend a lot of your time, for long stretches practically all of it, doing things besides the design/code/test cycle that individual contributors get to focus on. Here’s an assuredly partial list.

  • Be your own IT staff. Set up a source code repository, mailing list, bug tracker, website, etc. Sure, there are distros and forges that will be glad to help with some of this, and it’s definitely better than having to set up every bit of software and keep up with every security issue on your own leased machines yourself, but even then you get to deal with someone else’s infrastructure team and release schedule.
  • Be your own release engineer. The second biggest time-suck in your life is going to be managing branches and shepherding patches. As much as you might hate rigid coding standards and checkin policies, you’re almost certainly going to be the one defining and enforcing those for any project with more than (in my experience) two developers because otherwise things very quickly get out of control. On top of that, you get to deal with packaging as well and packaging issues can often take more time to resolve than almost any technical issue.
  • Be your own HR department. Whether you’re actually hiring or just attracting developers for your project, you’re going to have to spend some time recruiting others’ participation. It’s actually harder for pure open source, because you can neither offer money nor do a proper interview. Some people who work in easy/popular specialties act as though interviews are passe anyway, but that’s total BS. There are still fields where most of the advanced work is still being done behind closed doors. If you relied on GitHub profiles to hire people for work on distributed replication, SSD tiering, or especially de-duplication, you’d practically guarantee that you’re getting the wannabes instead of the true experts (not that the “GitHub or git out” crowd is qualified to tell the difference). You’re going to end up interviewing and evaluating people either before they go through the door or after. Since it’s really hard to get rid of an incompetent or toxic person after, you owe it to yourself and the other members of your team to do the filtering before.
  • Be your own marketing department. If you work at an actual company, whether startup or established, you might have full-time marketing folks to attract business interest, but they’ll be all but totally useless (and disinterested) when it comes to attracting technical interest so this is going to be the biggest expenditure of your time. Blog, tweet, attend conferences, respond to inquiries in email and IRC. Lather, rinse, repeat. If you’re lucky, you’ll get to spend time presenting to customers/partners as well, which means even more time away from the code but is obviously worth it. “Evangelism” is necessary partly as part of your recruiting strategy – see above – but also so that when you do talk to people about deploying your code you don’t find yourself taking a torpedo in the side from some techie who’s either unfamiliar with your project or already inclined to use something else.
  • Write your own documentation. Developers hate writing documentation. They even hate reviewing documentation. However, if you’re running your own project you probably won’t have any trained and dedicated doc writers until very late in the game if ever, so you get to provide not only technical documentation but user documentation as well. No, a wiki doesn’t cut it, and neither does a FAQ on your website. If you’re really serious about letting your users figure things out for themselves instead of bugging you on mailing lists or IRC (which is even more time away from coding) then you’ll need to write not just technical documentation but end-user documentation as well. Writing man pages in nroff might seem like chipping flakes off a piece of flint, but you’ll still have to do it.
  • Deal with legal issues. If you’re lucky you can avoid patents, but – as I’ve found out – you can’t avoid trademarks. You might also deal with contributor agreements and such where your project relates to others, even if you eschew them on your own.

So now you’re spending 30% of your time on recruiting and evangelism, 25% of your time playing release engineer, 20% of your time doing all these other things. What do you do with the other 25% of your time that you actually get to spend on code? Probably more than half of that time will be spent on “peripheral” pieces of the code – selecting libraries and debugging their problems, writing config/argument parsers, running static code analysis (including memory-leak analysis) tools, or generally filling in wherever there are gaps. Maybe you’ll get to spend 10% of your time doing the things that you started the project to do. Maybe not.

I don’t mean to seem like a total downer. Even spending 10% of your time on the parts you really enjoy can be worth it if that allows you to prove a point or make the world a better place. It’s better than working on someone else’s dream (or merely lining their pockets) during the day, and getting to spend only tiny scraps of your “spare” time pursuing your own dream. I’m just trying to sound a note of caution here. Be aware that when you turn your tinkering into an actual project you lose a lot of control over both its direction and your own involvement. Personally I don’t subscribe to the open-source mantra that you should start inviting others to participate as soon as you have an idea. That’s great for the kibitzers, but it’s not so great for the players who might actually be better off keeping an idea to themselves for a while before giving up the chance to work on it the way they want to.

(Yes, I’m playing devil’s advocate a bit here. There’s enough “big happy family” rah-rah out there already. Average that with the deliberately negative view I present here, and you might end up somewhere near reality.)

Eleventh Anniversary

Yesterday was this blog’s eleventh birthday. Actually I’m not quite sure when I created it, but that’s the date of the earliest “log entry” I could find; this was before the term “blog” was in common use, so I weren’t calling them posts yet. Just for fun, here’s a quick overview of how the blog has evolved over time.

Month Host Software Notable/Typical Post
August 2000 NameZero Static HTML Programmers’ Lifestyles
December 2000 The Mythical Linux Month
October 2001 JTLnet Home grown Multithreading vs. Event-Based Programming
February 2002 Home grown with comments (“PlatSpot”) Freenet Thought Experiment
August 2002 Server Design
February 2003 Burton The Whole Sad Story
April 2003 Ruin Dissed
March 2004 Total Choice Stack the Ripper
May 2004 pMachine Silly Assertions
June 2004 We Interrupt This Weblog…
October 2004 WordPress Waiting for GODOT_RESP
March 2006 Site5 Amazon S3
June 2006 eMax Net Neutrality
September 2006 Verizon’s DNS Sucks
January 2008 InMotion Linux Pointer Types
September 2008 GlowHost Aspire One Wireless
August 2009 Amazon vs. Rackspace vs. Flexiscale
November 2009 Availability and Partition Tolerance
July 2010 It’s Faster Because It’s C

Thanks to all who have inspired posts, commented on posts, sent email, replied elsewhere, or generally helped to make this a useful place to collect my thoughts.

And Now For Something Totally Random

I was talking about an XKCD comic with my wife, and realized I could do a little experiment myself. Because I’m lazy, I didn’t install gnuplot on my Mac but instead searched for an online graph generator. The first one I came up with was this one which I’m linking here mainly because I might want to point Amy at it some day. Anyway, here’s the graph I came up with.

'I got fired' vs. 'I quit my job' by day of week

I found the difference in Monday:Friday ratios amusing. At first I was also very intrigued by the fact that more people seemed to be quitting on Saturday than Wednesday, but you won’t see that on the graph because I realized that people were quitting other things besides jobs on Saturday so I changed my search from “I quit” to “I quit my job” and the anomaly went away. That’s an interesting illustration of how subtle changes in wording can affect experimental results. Anyway, it kept me amused for a few minutes. What’s your favorite XKCD-style Google experiment?