My First Week with Automattic

My first week after joining Automattic as a mobile developer was among the most unusual new-hire experiences I’ve had. Instead of jumping into the code, I did customer support – and I’ll continue to do it for another two weeks.

No, doing support isn’t punishment for some naughty bit of code I submitted. Everyone who joins Automattic is expected to complete three weeks of support before moving on to their new role.

The fact that Automattic expects this is one of the things that made me so interested in working with them. I love knowing I’m working alongside people who have all experienced what it’s like doing support.

I’ve written before about how developers should do tech support because it forces us to see our software through the eyes of our customers. Directly communicating with your end users is the single best way to find out what the problems in your software are and what you can do to simplify it.

I won’t claim, though, that my support stint has been easy. You’d think it’d be a breeze since I supported my own software for years, but this is the first time I’ve supported software I didn’t create and it has been truly humbling to feel like such a newb. Luckily, Automattic’s Happiness Engineers have been, well, happy to provide help when I’ve needed it (thanks, folks).

PS: Be sure to read Jason Munro’s excellent post about his initial experience at Automattic if you want to hear more about what it’s like to start here.

Android’s Overblown Fragmentation Problem, Part 2

A couple of weeks ago I said that while Android’s fragmentation problem is real, it’s smaller than some make it out to be. That post generated a good discussion on Hacker News, and I was really glad to see that since I’ve recently had to disable comments here.

One thing that was pointed out is that fragmentation is a very real problem for game developers, and I certainly concede that. There are plenty of other legitimate reasons to complain about fragmentation.

But most of the time when I see someone complaining about Android fragmentation, it’s either because they’re struggling to get their app to look good on the many different sizes of Android displays, or they’re upset about having to support so many versions of Android.

I came to Android development after years of creating Windows software, so to me those just aren’t a big deal. I’ve always had to support multiple OS versions and a wide number of screen sizes. Web developers are in the same boat – they have to make their apps work on an almost baffling array of devices, browsers, operating systems and screen sizes.

I think part of the problem with Android is that wasn’t until relatively recently that it was deemed popular enough to develop for. That resulted in a boat load of iOS developers and designers having to create Android versions of their apps.

These folks were used to developing for a very limited number of OS versions, and most of their customers upgraded to the latest OS very quickly. They also had to design for a small number of display sizes, which often meant they simply created 1x and 2x fixed-size graphics for their apps.

Suddenly they were faced with developing an Android app, where 1x and 2x graphics just don’t cut it. And they could no longer assume that customers were using a recent version of the OS.

To these people, fragmentation must certainly be an enormous issue – especially if they continued trying to design Android apps the same way they designed iOS apps.

The obvious answer is that they should stop doing that. Just like developing for iOS had an initial adjustment period, it takes time to learn the Android way of doing things. Developers and designers who are unwilling to invest that time just end up creating crappy clones of their iPhone apps.

To those folks, I can only say: remember when you bristled at seeing second-rate Mac ports of popular Windows apps? Remember how you felt about companies that treated your choice of OS as an also-ran?

That’s how you’re making Android customers feel. It doesn’t endear you to them, so they’ll seek out alternatives. They’ll switch to competitors who treat their iOS apps and Android apps as equal citizens.

But regardless of whether you’re willing to do that, can you at least stop complaining about "Android’s fragmentation problem" just because you have to support different screen sizes and OS versions?

There are legitimate reasons to complain about fragmentation, but those two issues are something developers have faced for many years with other platforms (and continue to do so). The fact that we have to do so with Android shouldn’t be that big a deal.

Screw the Power Users

I designed HomeSite and TopStyle for power users. Only power users would want to edit HTML & CSS by hand, so I made sure to cater to them.

Those products were filled with features and tool buttons, and their settings dialogs contained dozens of geeky options. Customers liked them that way. I liked them that way, too.

But then I made FeedDemon. It’s still a pretty geeky product, but it’s not just for power users. FeedDemon users range from hardcore developers to computer newbies.

At first I built FeedDemon as though my customers were geeks like me, since that was what I was used to. Power users were happy with all the features and all the options, but the extra baggage made it harder for less technical people to use the product. It scared them away.

So with each new version I tried to simplify the user interface, and dropped features & options that complicated the product. FeedDemon became more popular as a result, but you’d never know it if you visited my online support forums.

I’d come out with new versions that I thought dramatically improved the product, only to find my forums filled with complaints from power users who wanted the return of some obscure option, or were upset that I wasn’t adding the geeky features they wanted.

Sales went up, but positive feedback went down. I had built FeedDemon with the wrong customer in mind, and I paid for it by spending a ton of time defending each release.

Sure, if you’re building a product for power users, make sure to cater to them. Give them everything they need. Despite the rude title of this post, I actually love building stuff for power users because they make great customers.

But if you’re building a mainstream consumer product, then from day one you need to tell yourself, “screw the power users.”

That’s hard to do – after all, you’re a developer, so you’re one of the power users. You want to make people like yourself happy.

But I’d argue that’s one of the biggest problems that has plagued the software industry. We’ve all built stuff for ourselves, even though the vast majority of software users aren’t like us.

We’re the ones who made computers so hard to use. And we’ve done it by catering to power users – by building software for people like us instead of for people who don’t know and don’t care about all the geeky little details.

So if you’re just starting to build something, make your mantra “screw the power users.” Unless power users are your primary customers, catering to them will only hurt your product.

Old Farts Know How to Code

I turned 45 this month. In many professions that’s the prime age to be – and in others it’s considered young –  but in my line of work, some people think middle-aged coders are old farts. That’s especially true when it comes to startups.

The startup culture is similar to professional sports in that it requires a fleet of fresh-out-of-college kids to trade their lives and their health for the potential of short-term glory.

“Old farts” are often excluded from that culture, not because we’re lousy coders but because we won’t put up with that shit. We have lives, we have families, we have other things that are important to us. We’re not about to sleep at our desks and trade watching our kids grow up for the promise of striking it rich. Especially when the people who really strike it rich aren’t the ones writing code.

So many developers my age have had plenty of chances to ditch coding and move into management, but we’ve stuck with coding because it’s what we love to do. We’d earn more in management, but writing software is in our blood. We wouldn’t stop doing it for anything.

And because of the years we’ve spent creating software, we’ve learned what works and what doesn’t, regardless of the language or the platform. Operating systems rise and fall, development tools come and go, but through it all, old farts know how to write solid code.

Young Gamer Geek Nostalgia

Earlier this week I wrote about "Moon Runner," a TRS-80 game I created when I was 18. That was my first piece of commercial software, but I’d written dozens of other games before that.

The first game I remember writing was "Possum Run," a bloody takeoff on Frogger which was published in a magazine called Hot CoCo when I was 16. Back then I was a long-haired metalhead, and I remember my friends being absolutely shocked to discover that I was a published geek.

During the remainder of my high school years I published a number of other games in Rainbow Magazine, including a goofy platformer inspired by Bloom County which featured a penguin trying to find wings that would enable him to fly.

Writing those games wasn’t just a hobby: it was my great escape from the boredom of school. I remember countless days staring at the clock in class, just waiting for the final bell so I could go home and continue coding. And during class I’d often be scribbling code in my notebook instead of taking notes.

Every now and then I toy with the idea of getting back into writing games, and I’ve even considered creating Android versions of my old games. But I’m more of a news and communication junkie these days, so writing games doesn’t interest me the way it used to.

Although I have to admit, it sure was fun coding that Easter egg in FeedDemon :)

I Used to Write Video Games

Sometimes people ask me which program I enjoyed writing the most, usually expecting me to say either HomeSite or FeedDemon.


"Moon Runner" was the software I most enjoyed creating. It was a game for the TRS-80 Color Computer that I wrote in 1986, when I was 18 years old. Back then I was hopelessly addicted to video games, so being able to write one myself was an enormous thrill.

"Moon Runner" was loosely based on the arcade game Moon Patrol which I wasted countless quarters on as a kid. It was coded entirely in 6809E assembler and took me several months to create. I still have a printout of the source code on my bookshelf, but it’s gibberish to me now.

I formed my first company ("D & N Software" – my Dad was the "D" and I was the "N") to sell the game, and had wild dreams of striking it rich. But despite receiving rave reviews in popular TRS-80 publications, "Moon Runner" was a flop. It barely earned enough to keep me stocked with peanut butter and Ramen Noodle Soup for a week.

But you know what? I didn’t care about that. I just loved the fact that I created something good enough for others to use. To this day, nothing has compared to the rush I got at age 18 when I saw "Moon Runner" reviewed alongside software written by professional software developers.

I imagine that’s similar to the thrill so many young coders feel today when they contribute to an open source project or post something that ends up on the front page of Hacker News.

That thrill is why "Moon Runner" will always be the software I most enjoyed creating.

Wireframing and the Reformed Cowboy Coder

Wireframing – sketching out the interface of your software with a focus on what it does rather than how it looks – was something I used to avoid.

I figured I’d end up laying out the interface in my programming IDE anyway, so why make extra work for myself? Just skip the wireframes and go straight to the IDE.

Besides, weren’t wireframes only used by teams in order to collaborate on design? I was a one-person company when I created HomeSite, TopStyle and FeedDemon, so wireframes seemed pointless.

But I was recently tasked with designing the next version of Glassboard, and I’m not the only one working on that so wireframes suddenly made sense.

And you know what? I should’ve relied on wireframes all along.

Sure, it’s extra work. And it can be pretty tiresome, too. It took me a lot longer to wireframe the app than I thought it would.

But once I was done, seeing an overview of every screen turned out to be enormously helpful. I better understand the relationships between those screens than I would have if I stuck with my "cowboy coder" ways and designed in the IDE.

Plus, writing out the purpose of every major area helped me clarify the UI and UX. I ended up re-thinking a lot of initial design decisions after I had trouble explaining them.

So consider me a reformed cowboy coder. I was wrong to think that only teams need to wireframe their software. The primary benefits I got from wireframing would’ve helped me even when I developed alone.

PS: I’ll probably be asked which wireframing tool I use, so I’ll say here that after trying a number of tools I chose Balsamiq Mockups. I like how its "lo-fi" approach reinforces the idea that you’re sketching out your design rather than deciding every last detail.

Hateful Hiring

This post on the 37signals blog struck a chord with me.

Interviewing programmers by requiring them to tackle problems on a white board is a lousy way to find successful developers, yet this practice has existed for years.

I’ve experienced it myself a few times, and each time I failed. Badly.

On one occasion I was interviewed by four separate people during a single day, all of whom expected me to answer on a white board. None of them asked any questions about previous experience. One of them hadn’t even read my résumé prior to the interview.

I’ve also been asked to tackle problems way outside my area of expertise. Perhaps the silliest was when I was expected to answer a problem which required knowledge of graphic chip architecture even though I was being interviewed for a front-end programming position that had nothing to do with graphics.

Yes, despite the fact that I’ve written several very successful programs, I wasn’t asked back for a second interview because I suck at answering irrelevant technical problems on a white board.

I agree with 37signals that the best way to gauge the potential success of a programmer is to see what they’ve already done, even if it’s just side projects they worked on in college. Interviewing via a white board is like deciding how good a musician is by asking them to write tablature instead of listening to them play.

Immobile Apps

Many of my favorite mobile apps are immobile. I can't take them with me.

At least not if I'm going somewhere that doesn't offer a fast internet connection. Like the small town I recently visited for five days.

I couldn't use Twitter there because it kept timing out before downloading the latest tweets. And Facebook was completely useless – it wouldn't even let me view stuff that had been previously downloaded.

Almost all the apps I use – including some games that shouldn't even need a connection – became immobile.

It reminded me of the early days of desktop development, when too many developers assumed that everyone had a computer as fast as theirs. These days too many developers assume that everyone has a connection as fast as theirs.

One of the most painful things we did when developing Glassboard was ban ourselves from Wi-Fi for a week. I live in an area where cell coverage is really spotty, and using our app without a fast connection was eye-opening and humbling. I spent the next week rewriting huge chunks of the app so it would better handle poor (or non-existent) network connectivity.

If you're a mobile developer, I urge you to do the same. Spend several days using your software without a fast connection, and chances are you'll find – as I did – that you've unwittingly built an immobile app.