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.

Are You Paying Attention to Facebook?

Way back in 2004 I wrote about how a scrappy young Google was replacing an increasingly stodgy Microsoft as the predominant tech company. A year later I wrote about how Google hoped to benefit from knowing what you're paying attention to.

These days Google is turning into the stodgy company and Facebook is the scrappy upstart. And now Facebook is the one hoping to benefit from what you're paying attention to.

Frictionless sharing is Facebook's latest attempt to find out what you're paying attention to. They want to know what sites you're visiting, what songs you're listening to, and pretty much everything else about you, so they can surface more relevant content in your newsfeed and show you more relevant ads. They also want to build a more thorough profile of you in order to enable up-and-coming features like timeline, and to open up more possibilities for those who develop apps on their platform.

But if Facebook wants to collect this information, they need to do it in a way that doesn't lead customers to believe their privacy is being violated. And based on the reaction to frictionless sharing, it appears they've failed to do that. They're gathering – and exposing – all this attention data in way that scares an awful lot of people and will surely invite increased government investigation. That could backfire on them in a big way (remember how diminished Microsoft was following their wrangling with the DOJ?).

All of this makes me more confident of our decision to make privacy the focus in Glassboard. When we created Glassboard, we anticipated an eventual backlash against popular social networking services that violate your privacy. And based on the news we read every day, it seems like that backlash may come even sooner than expected.

In Defense of Android’s Hardware Buttons

Lately I've seen a few posts criticizing the Android hardware buttons. I get where they're coming from – especially regarding the sometimes confusing way the back button is handled – but now that I've switched to Android, these buttons are among the things that make it so hard for me to use an iPhone again.

As an Android developer, I love that I can tuck actions into the menu button instead of having to use precious screen real estate for icons that perform those actions, as iPhone developers are forced to do.

Seriously, how many iPhone developers would love to stop fretting over where to place their settings icon, or their accounts icon, or their mark all read icon, etc.? Wouldn't it be nice to have a common place to put all those things so you didn't have to clutter your UI with them?

I'm also a fan of the much-maligned Android back button. Yes, some apps intercept the back button and make it act weird. I hate that, too – which is why I don't use those apps. Those crappy apps  aside, I like having an easy, consistent way to navigate between activities and apps.

Now, by this point iPhone users may have written me off as an Android fanboy, but that's not the case. There are plenty of things the iPhone does better than Android – most importantly the iPhone wins on overall UI consistency and attention to detail. But as both a developer and an end user, the hardware buttons make Android easier and simpler for me.

The Long-Term Failure of Web APIs

Years ago, when developers such as myself started the transition away from OS-specific APIs to web APIs, we believed that doing so would empower our software and save it from the confines of the desktop.

And we were right.

But we've also learned that while web APIs enable us to tap into a wealth of data, they can only be relied upon in the short term. The expiration date of software we create has been shortened due to the whims of those who create the web APIs we rely on.

I wrote the first version of HomeSite back in 1994, and seventeen years later I can still run it on the latest version of Windows.

I created FeedDemon 1.0 in 2003, and it was the first app I wrote that relied on web APIs. Now those APIs no longer exist, and almost every version of FeedDemon since then has required massive changes due to the shifting sands of the web APIs I've relied on.

You might think you're immune to this problem if you only integrate with APIs created by large players such as Twitter, Facebook and Google. But in recent years we've seen Twitter switch to a new authentication system, Facebook deprecate FBML, and Google discontinue several APIs. All of these changes have broken, or will break, existing apps.

The end result is that developers are spending more time upgrading their software to ensure that it continues to work with web APIs they've integrated with, and less time adding the features and refinements that would really benefit their customers.

That's a long-term failure, any way you look at it.

Anti-social FeedDemon (Killing Features, Part II)

Last night the changes to Google Reader went live, and as promised, they've removed the sharing features. This means that the sharing features in FeedDemon which rely on Google Reader will eventually stop working, so I'm forced to remove them.

A few years ago I wrote about the pain and pleasure of killing features, but deleting sharing from FeedDemon has been all pain and no pleasure. Those features took a long time to create, and I relied on them every day. Seeing what my friends are sharing, and sharing back with them, has become part of my daily routine.

I don't fault the Reader team for removing those features – it makes sense for Reader to integrate more tightly with Google+. And I certainly don't fault them for eventually removing those features from their unofficial API. If anything, I want to thank them for letting developers such as myself use their API for free for so long.

But I'm surprised that the Reader team didn't make the transition to Google+ an easy one. I realize that Reader users are a dwindling bunch, and most of them never used the sharing features. But many of those who relied on sharing are influencers, including well-known tech journalists, bloggers and developers. It strikes me as a bad idea to leave these people with a sour first impression of Google+, yet that will be the result of the painful transition from Reader sharing to Google+ sharing.

As far as FeedDemon goes, in a few days I'll have a build ready which removes the sharing features. But I'm going to hold off releasing this build for a little while since sharing still works at the API level. In other words, right now you can still use the Reader sharing features in third-party apps like FeedDemon even though those features aren't available in Reader itself.

Before the end of the year, though, there will be a new FeedDemon release which does away with sharing, and every FeedDemon customer will need to upgrade. That pains me, because like every developer, I'm used to having new releases improve upon previous ones. For some this release will feel like a downgrade, and I know I'll take some heat for it since many customers won't be aware of the reasons for the loss of sharing.

What the Upcoming Google Reader Changes Mean for FeedDemon

Yesterday Google announced some big changes to Google Reader which will impact FeedDemon (and every other application that uses the unofficial Google Reader API).

In an effort to better integrate with Google+, Reader is retiring friending, following and shared link blogs. That means the social features in FeedDemon that rely on Google Reader will eventually stop working.

They won't stop working right away, though. Google will continue to support those features in its API even after they disappear from Reader's UI. But at some point (I don't know when yet) they will cease to function, and you'll be unable to share articles in FeedDemon or follow the shared articles of other users.

Before that happens, I'll release a new version of FeedDemon that removes those features. But I won't do that until the new Reader goes live and I have a chance to test against it, which will likely take a few weeks.

I am, of course, disappointed to see those features disappear. I know a lot of FeedDemon customers will miss them, and I'll personally mourn the loss of shared articles since that's something I use every day.

Tiny Apps are Hard

When I started writing mobile apps, I figured, how hard can it be? Apps look dinky on the small screen, so it must be easy to create them.

But holy shit is it hard.

It's hard on Android, on iOS, on WP7. And from what I hear, it's even harder on Blackberry.

It's almost like the MS-DOS days when you had to figure out how to squeeze every last ounce out of the machine to get your stuff to work. Except now you also have to make your app look good.

But you know what? I'm loving the challenge. I've been developing desktop apps for so long that I just assumed I could keep adding feature after feature and option after option without worrying that I'd tax the system.

Now that I'm a mobile developer, I'm finding it strangely wonderful to have to consider things like battery life, reduced screen real estate and limited storage space. I'm forced to make sure that anything I add to my app is important, because if it's not important then it's not worth the trade-offs.

Regardless of whether I stick with mobile development, the lessons I've learned from it are ones I'll apply to everything I create in the future. Keep it simple, keep it uncluttered, and keep it focused. That's how you create great apps for any platform.

Privacy is Important

“You have zero privacy anyway. Get over it.” – Scott McNealy, former CEO of Sun Microsystems.

When I was invited to join Sepia Labs and create the Android version of Glassboard, I stressed that privacy was the key to our success. Companies like Facebook and Google are trying to convince millions of us that we can trust them with our privacy, but millions of us remain unconvinced.

These companies make the majority of their revenue from advertising, and advertisers are willing to pay more when they know exactly who their ads will be shown to. We’re expected to trust our private conversations with companies that don’t benefit from keeping our conversations private. Red flag, anyone?

“If you have something that you don’t want anyone to know, maybe you shouldn’t be doing it in the first place.” – Eric Schmidt, Google’s executive chairman and former CEO.

It’s not that we fear saying things that we don’t want anyone to know, it’s that we fear saying something without knowing who will hear it.

We want to be able to say something online without fearing that a future employer may see it and count it against us. We want to complain about the country we live in without fear of reprisal. We want to share pictures of our kids without wondering who else will see them. We want to share with only the people we choose to share with.

When we know a conversation is private, we’re more willing to share ourselves. It feels good to share who we are, to open up to the people we trust. When we don’t know who will hear us, we censor ourselves and hide the rough edges of who we are. But those rough edges help define us. It’s impossible to feel truly loved if you have to hide parts of who you are.

It’s time for us to say, “No, I won’t get over it. Privacy is important, and I won’t give it up.” Today’s software developers need to look at privacy the same way they’ve learned to look at security: it’s not an add-on or a feature that customers have to turn on, it’s something built-in that shouldn’t be turned off.

I hope more companies follow our lead and take the same approach to privacy that Glassboard has. I think the web is headed in the wrong direction, and the more that participate in trying to change that direction, the more likely it is to change.

From Windows to Android with Glassboard

Earlier this year I got an offer I couldn't refuse. Several friends and former co-workers of mine were forming a company named Sepia Labs, and they asked me to join them. They planned to create a mobile group sharing app, and they wanted me to develop the Android version.

I've been itching to get into mobile development for a long time, but I didn't even own an Android, let alone know how to develop for one. Yet there was no way I could turn down the chance to learn mobile development while working with people I know and respect.

So I joined Sepia Labs, and we immediately set out to design a different kind of mobile group sharing app, one that values privacy above all else. The end result is Glassboard, which we launched today for Android and iPhone, and will soon be available for Windows Phone 7. I'm really proud of what we accomplished with Glassboard, and I hope you'll give it a try (and after you get it, this post will help you get started).

Now, I can tell you that switching to Android wasn't easy after almost two decades of Windows development. I had to learn a new language (Java), a new IDE (Eclipse), a new platform (Android) and a new programming mindset (mobile) in a very short time. Oh, and just to make it harder, I decided to do it all on a Mac. I guess you could say I was looking for a challenge :)

And a challenge it definitely was.

The first challenge was trading my iPhone for an Android. I've used an iPhone for several years, and my new Android felt unpolished and geeky by comparison. But I slowly warmed to it, and now I love my Android so much that on the rare occasion I pick up my iPhone I curse it for not having a back button.

The second challenge was learning Java. My usual approach to learning new things is to just jump in and get my hands dirty, but I decided not to do that with Java. Instead, before I wrote any code I read a ton of books on the language (my favorites were this one and this one). I had Java books all over the place – on my desk, next to my bed, in my car, and in every bathroom of the house. I wanted to really understand the language before I used it so I could design Glassboard correctly (and not have to redesign it a dozen times as I learned more about Java). Surprisingly, I liked Java right away. It does feel a little too object-oriented sometimes, and it was hard getting used to garbage collection and the C-like syntax, but it made sense to me. It's a very well thought out programming language.

Next I had to figure my way around Eclipse so I could actually write some Java code. Like Nick Farina, I absolutely hated Eclipse at first. I despised its strange, overloaded user-interface. I made up new swear words as I stumbled around trying to decipher its overwhelming array of menu items. But I've definitely grown to appreciate Eclipse. It has some incredibly powerful features that I haven't seen elsewhere, and it rarely gets in my way – in fact, it actually helps me write better code. And funny thing is, when I work on FeedDemon now, I wish that Delphi had the features I've gotten used to in Eclipse.

I thought my biggest challenge would be switching to the mindset of a mobile developer, but that hasn't been nearly as hard as I expected. I've written for years about simplicity, killing features and doing away with options, all of which are requirements for mobile development. Mobile development forces you to focus on exactly what your software needs to do, and I really enjoy that.

But developing specifically for Android has been a huge challenge. There's an awful lot to learn – intents, activities, AsyncTasks, XML layouts, services, BroadcastReceivers and on and on and on. Once you wrap your head around everything it all makes sense and fits together well, but getting to that point doesn't come quickly. And as is always the case, the thing that takes the most time is learning your way around all the gotchas. If you're just getting started with Android development, be prepared to spend a lot of time on StackOverflow!

Of course, I can't write my first post about Android without mentioning its supposed "fragmentation" problem. It is a problem, but it's mostly blown out of proportion. Desktop developers have always had to create software that works across different OS versions, different devices and different screen sizes, so the fact that you have to do that on Android isn't a big deal. But it is a big deal when different Android devices handle things differently – video playback and recording, for example, are challenging due to device differences, and getting video streaming to work reliably across devices feels impossible (as Netflix discovered).

All in all, learning so much new stuff in such a short time has been both thrilling and exhausting. I'm finally doing mobile development, something I've wanted to do for years. But take it from me: if someone offers you a job that requires switching from Windows to Android development and learning it all in a few months, stock up on the caffeine – you're going to need it!

PS: Hopefully this post explains why it's been so long since there was a new build of FeedDemon. I am still working on FeedDemon, and a new release is already underway.