Read the full post at Boxes & Arrows.

I’ve spent the last six weeks using a combination of Android’s built-in keyboard and SwiftKey, and it’s been an interesting opportunity to think about the nuances of keyboard design. Of course there’s room for Apple to improve; but I believe they still have the best keyboard in the business.

Defending QWERTY

Lomas writes,

Qwerty keyboards owe their letter layout to early mechanical typewriters…Qwerty letter order made sense when the metal legs arranged around the typewriter’s amphitheatre needed to be positioned to avoid clashing with one another as they can-canned their letters up and over to stamp on the ink-soaked ribbon…Such mechanical thinking is clearly redundant in today’s digital word [sic].

QWERTY was, indeed, devised to avoid jamming typewriters. But a digital world doesn’t eliminate the need for mechanical thinking; it just changes the machines we think about – in this case, our hands.

QWERTY’s design kept keys apart that were likely to be pressed in quick succession. Think about how we operate our mobile keyboards when we want to type fast: two hands on the phone, thumbs tapping. Repeatedly tapping one thumb is slower and less comfortable than alternating thumbs. A design like QWERTY’s that maximizes the distance between successive taps increases the frequency of thumb alternation, arguably improving both typing speed and ergonomics.

Next Word Prediction and Cognitive Load

Next word prediction, for starters, has broken the traditional letter by letter rhythm carried down from the days of mechanical typing. It’s a big step up from auto correction (which, yes, the iPhone has).

For those who haven’t tried it, next word prediction (which most Android keyboards have) provides the user with a set of possible completions for whatever she’s typed so far. The most common implementation is a horizontal bar, just above the keyboard, containing three completions. It may not even require that you start a word: it can predict based on the context you’re in and the words you’ve already typed.

Which is great, right? Every time it guesses your word you can avoid typing it. Except that it’s not that simple. Typing efficiency is about more than the number of taps required. It’s about decision-making or cognitive load. Looking at a set of three words takes time and brainpower. How many taps’ worth? I don’t know. But there’s a cost to pausing whatever you’re typing, looking at a set of choices, and picking one.

And that’s not the only decision involved. With autocorrect, you have either zero choices (no suggestion is present) or a simple binary choice in the context of your current thought process: is the word in your head best represented by whatever you’ve typed, or by the thing that’s popped up next to it? With next word prediction, you’re faced with a constant, less contextual decision: do I keep typing what I’m typing, or do I take a look at the choices the keyboard is offering me (which, for some reason, tend to appear in a location I wouldn’t otherwise look at)? That, in turn, can be further broken down into several decisions: Am I typing the word correctly? If so, is it long enough that it’s worth checking to see if there’s a completion available? Or if not, do I think it’s worth looking for the correct word amongst my choices?

This isn’t just theoretical stuff: when I’m typing on Android I honestly feel like I’m constantly interrupting myself to use the completion feature.

Quiet Improvement

The iPhone’s keyboard is a relic of the past in more ways than one. It has barely changed since the phone was first introduced, way back in 2007 — the proverbial ice age in technology terms.

The iPhone keyboard’s UI hasn’t changed much, but it’s improved tremendously – which is sort of ideal, since users didn’t have to adapt to anything new. I celebrated the day it stopped autocorrecting “for” to “fir.”

I can think of one UI change since the original iPhone: when you backspace after typing a word, you get a popup with alternate completions, including whatever you originally typed. I’ve never gotten the hang of using it, and I think it’s the exact problem I described above: it’s easier to correct manually than to make the decision to use the popup.

Swype

In the touchscreen era, the most disruptive text input technique that has gained significant traction was devised by Swype…Instead of tapping, the Swype keyboard lets the user drag a finger to chain letters together to form words.

While whole-word gestures are conceptually intriguing, I have some fundamental usability issues with Swype:

• Traditional tap keyboards provide feedback for each tap above the key itself. Swype  draws your gesture as you move, but that drawing is largely obscured by your finger.
• The atomic nature of a word gesture can be problematic. Swype corrects for missed keys just as a tap keyboard does, but you don’t have any way of knowing what it’ll come up with until you’re done with the word. It’s up to you to decide if it’s worth bailing mid-gesture – at which point it’s two taps to get rid of your mistake.
• Lengthy drag gestures can be awkward when operating a phone with one hand. But Swype’s word gestures don’t support two-handed operation: whatever hand isn’t gesturing is just idle.

Cargo Cult Design

Again, there’s obviously room for Apple to improve – and for others to leapfrog the iPhone. But like so much in the tech industry these days, this feels like an example of cargo cult design. Innovators come up with great ideas but often don’t seem to analyze their competitors’ solutions on a detailed, task-driven level; to dig in and ask, “Why is this the way it is?” As a result, they eliminate or misinterpret areas of the product where they’re not innovating. The result is often one step forward, two steps back. And that’s a shame.

By way of disclosure: I have not tried every product Lomas brings up. This is intended as a general critique, not a comprehensive multi-product review.

iPhone keyboard image by djenan via Flickr.

But that’s changing. Each version of iPhoto is buggier, slower, and more confusing than the last. iOS interactions like Launchpad get shoehorned into the Mac without real integration. Arcane checkboxes and popups proliferate. More and more details slip through the cracks.

iTunes 11 may be the most prominent evidence of this yet. MG Siegler and Walt Mossberg have written about superbly-executed details; but the fundamental information architecture of the product is flawed.

History

iTunes debuted in 2001 as a music player. In the intervening decade it pioneered the podcast; added movies, music, movie trailers, and online education; introduced the iTunes Store for purchase, download, and streaming; became the center of a digital hub for devices that extend far beyond playing media; and further expanded the Store to include apps. (Oddly, the Mac App Store is separate: on your Mac, you buy iPhone apps in iTunes and Mac apps in the App Store; on your iPhone you buy iPhone apps in the App Store and don’t buy Mac apps at all.)

The result is a giant, bloated product. I don’t necessarily blame Apple for that: each individual addition made sense on its own. But it also made sense to step back, look at what iTunes had become eleven years after its launch, and find a way to simplify.

Navigation, the Old Way

Sidebars in the Finder and iPhoto.

Broadly speaking, iTunes’ functionality falls into three categories: media player, store, and device manager. Each has subcategories: for instance, the media player includes several types of media as well as playlists and Genius recommendations. Prior to version 11, you navigated these categories and subcategories via a sidebar. Such sidebars are straightforward and ubiquitous; Mac users encounter them in the Finder, Mail, iPhoto, and other Apple apps. Third-party developers have copied Apple, further reinforcing the pattern.

But sidebars have limitations. As the number of items grows, it becomes more and more difficult to find what you’re looking for. Apple’s visual design makes this worse: dimming the category labels and drawing them in capital letters makes the top-level category far less prominent – and thus easier to miss in a quick scan – than its subcategories. An earlier attempt to simplify by desaturating the icons eliminated the ability to scan by color, arguably doing more harm than good.

New and Broken

Upon upgrading to iTunes 11, I was greeted with this welcome/hint screen:

iTunes 11′s welcome screen: hints for three big tabs.

Uh-oh. Hints and tutorials have their place – explaining novel interactions and concepts – but when Apple feels the need to display one for what are effectively three big tabs it can’t be good. But OK, now I know where my top-level navigation is: media on the left, devices and store on the right. (I still don’t know what that little cloud next to the media popup is, but it is cute.)

So let’s open the iTunes Store. Everything changes:

iTunes 11 in Store mode – where did my navigation go?

The tutorial has already failed us. Our media is gone, our devices are gone, and the Back button is disabled. Eventually we discover that the new Library button is a toggle that takes us back to media. Oddly, Apple missed the opportunity to borrow its iOS convention for this sort of thing, wherein a flip animation preserves context by making each mode the back side of the other.

Having created a toggle convention for Library and iTunes Store, Apple breaks it for device management. Clicking the device button (only accessible from the media side) yields the following:

Device management: No navigation at all, just a Done button.

There’s no Library, no iTunes Store. You’re in a modal view, akin to a dialog box – though that modality is not visually distinguished as such, making it difficult to recognize. You’re also forced to commit any changes before leaving this view, meaning you can’t monkey with your playlists in the midst of managing a device. The buttons at the bottom change to reflect unsaved changes but the Done button at the top does not – and if you do click it with your choices don’t include the ability to cancel.

The result of all this? An iTunes that looks simpler, but is actually confusing to use. Its inconsistency with other Mac apps misses the opportunity to reinforce behavior patterns and to generate expectations that are predictably met; and its internal inconsistency is especially problematic, because it results in a situation where the app itself is creating expectations that are almost immediately broken again.

But come on, you ask. Is this really a big deal, or is this the kind of overanalysis that prevents designers from getting any work done? You’re right: it’s not a big deal. Users will adjust. They’ll figure it out, or they won’t and they’ll find workarounds that get the job done. But these little annoyances and complexities add up. And the more central they are to the app, the faster they accumulate.

Every moment of hesitation is a delay, a distraction from the task at hand. And at some point, a great product with a few rough edges becomes a rough product with a few great details that, perhaps, no longer make up for the overall pain of using it. Historically, Apple has known this, sweated the details, and created products that “just work.” Lately, though, they seem to be confusing products that look simple and polished with those that actually are. Great UX and information architecture can’t overcome ugly design, but neither can great visual design overcome sloppy UX and IA. Apple’s strength was never in removing buttons, but in including only the buttons that mattered.

The baffling thing with iTunes is how easy it would’ve been to create a simple, easily-understood top-level navigation that avoided the sidebar and didn’t require a tutorial:

Tabbed navigation for iTunes.

I can only assume that in their attempt to combine traditional Mac conventions with newer iOS ones, Apple ended up with the worst of both worlds.

Digging Deeper

Great design starts with a search for the most fundamental question, and all this discussion of navigation begs the question: should these three areas be in an app together at all? Apple themselves have answered this with a resounding no on iOS, where you buy media in iTunes and apps in the App Store, manage podcasts in Podcasts, and consume music, videos, and educational videos in Music, Videos, and iTunes U respectively. Arguably they’ve gone too far; but building single-purpose, focused apps allows Apple to avoid bloat and keep things simple.

By pursuing such different strategies on its two platforms Apple is also punishing its multi-device users. Every device switch requires a moment of adjustment: wait, I’m on my iPad? OK, right: here iTunes is a media store, I listen to stuff in Music, and if I want to buy apps I open App Store.

Desktop apps can handle a bit more complexity than mobile ones, so duplicating every detail of the iOS approach might not make sense. But iTunes functions could be split into 2-3 apps:

1. A media app named iTunes, with store and player serving as flip sides of each other. (Or, this could be further split into two apps: iTunes the store, and Music & Videos the player.)
2. A device management tool, probably not named Pods ‘n’ Stuff. If Apple had delivered on the promise of iCloud, this could be an infrequently-accessed preference pane, but as it is iDevice management is too labor-intensive, finicky, and sync-centric for that.
3. iOS apps would join their Mac brethren in the existing App Store. This might be better from a marketing standpoint too: wading through iPhone apps while trying to find an album is irritating; discovering my favorite Mac software has an iPad version would be nice.

One could argue iTunes’ features are too interdependent to separate: why shouldn’t I buy, listen to, and sync my music and other content in one place? But Apple crossed that bridge a long time ago with photos: you manage your photos in iPhoto, but sync them in iTunes. Photo sharing options are split between iTunes’ and iPhoto’s preferences. Splitting iTunes up could clarify this situation and create a consistent pattern.

Epilogue: Bringing Back the Sidebar

All that complaining aside, there is good news: you can re-enable the sidebar by selecting Show Sidebar from in iTunes’ View menu. What’s more, Apple has restored the sidebar’s colorful icons, making it easier to distinguish different types of item at a glance.

Did I say good news? I meant bad news. If there’s one thing worse than making a bold but misguided UX change, it’s giving everyone the ability to roll it back. Because any change upsets users. Show Sidebar is a page straight out of Microsoft’s old playbook. Most users who find it will use and cling to it (myself included). So now Apple has to support it. That means more to test, more bugs to find, more edge cases to understand.

It’s also disturbing for its un-Apple-like quality; after all, this is the company that omitted cut-and-paste from the first iPhone, that unilaterally flipped our scrollbars, and whose aggressively conservative attitude toward backward compatibility has carried it through three chip architectures and two operating systems in fifteen years.

Of course, most of my music consumption happens via Spotify anyway. But that’s a product strategy discussion for a different day…

“Fits just the way I get organized in the morning.”

“The concept behind Stky is ingenious and the execution is beautiful.”

“Really like it, and I like the little sounds too. They make me happy.”

Stky’s been covered in TechCrunch and named one of E-Junkie’s best apps of 2012.

It’s been especially gratifying to see how well such a simple concept works for so many people. But of course, there’s always room for improvement. With that in mind I’m pleased to announce Stky version 1.1! With this update I’m lowering the price to 99¢ USD and adding:

• Much-improved iPhone 5 support.
• Bump tasks to the top of your list using the arrow button in the swipe menu. Shake to undo.
• The home screen icon now shows the number of tasks left on today’s sticky.
• Bug fixes, look & feel tweaks, whatnot.

Get it while it’s hot!

Parts of Lean Startup made sense to me, and indeed echoed what UX practitioners have been saying for years. Gather data. Make sure you’re building something your target customers will actually use. Test early and often. So I did something I rarely do: I read the book, Eric Ries’ The Lean Startup.

By and large I like Lean Startup, especially once you recognize how it’s been misunderstood by the industry at large:

• A minimum viable product isn’t a minimal version of your product. Every product idea is based on assumptions. Incorrect assumptions can lead a startup down an unsuccessful path, so a big part of Lean Startup involves identifying assumptions and turning them into testable hypotheses. Your minimum viable product is your tool: the simplest, easiest test you can construct for a particular hypothesis. It may or may not be your actual product, and isn’t intended to be thrown at users wholesale. In particular this means Lean Startup does not advocate releasing half-finished products to the world, nor should it be confused with a “build something fast and see if it sticks” philosophy.
• Lean Startup is not a substitute for product vision. Many have interpreted Lean Startup to mean you needn’t have a big, long-term vision. But the best products do have that vision to guide and constrain their efforts. What you learn along the way will change the path you take and might scrap the vision entirely; but that doesn’t mean you don’t need it.
• Lean Startup eliminates the risk associated with trusting your gut. Not exactly. Lean Startup reduces risk and provides an efficient method for vetting your gut, a.k.a. verifying your hypotheses. But while you can reduce the unpredictable role creativity and intuition play, you can’t completely replace them with a system.

So you’ve got your vision, you’ve created a hypothesis, and you’re ready to craft an MVP. What should it be? There are examples throughout the book: landing pages and sign-up forms to gauge user interest, “concierge” products that use people to simulate algorithms, etc. Put something together, test it, draw conclusions. Except it’s not that simple.

Suppose that in 2001, Apple had asked people whether they’d use an iPod. iTunes was brand new. The iTunes Store didn’t exist yet: digital music was all about tedious CD-ripping or equally tedious searching and downloading from Napster. MP3 players were inexpensive but limited-capacity and hard to use. Understanding the appeal of a $399 iPod required an intuitive grasp of a world that didn’t exist yet. I don’t know how our fictional focus group would’ve reacted, but I can easily see them laughing at the price and asking for longer battery life in their Nomads. Or better skip protection in their Discmen.

You can’t just ask users what they think of your product. Imagining your world with that product in it is hard, even for experienced product designers. Is there a need? Will there be in six months? Does this particular product address the need in a way that recognizes how you’ll actually approach the task in question? Is there a latent human tendency for which a product doesn’t yet exist? Are there details of the final design that will make the difference between a decent product and an addictive one?

Different hypotheses require different MVPs, each carefully constructed to avoid pitfalls. Some examples:

• A survey can give you a window into the user’s mind but everything is filtered through layers of bias. Is the user second-guessing the question? Does he like the idea of himself using the product? Is he answering honestly but without a detailed understanding of his own needs? A little cleverness can give you greater insight by coming at things sideways but it takes care and skill to compose, and can still only illuminate certain types of hypothesis.
• A landing page can answer questions about positioning. Is the product you’ve described something the viewer thinks she wants? Does it fill a need she can identify? But it won’t tell you much about engagement, retention, or usability. And it can be risky in the case of products that create entirely new categories.
• Usability testing – officially in a lab, or unofficially in a cafe – will help you find aspects of your product that are confusing, but won’t tell you whether people will adopt, use, or like it. One researcher I worked with would ask participants to rate a feature on a scale of one to seven – and then throw out the response. The self-reported number wasn’t reliable data; he just wanted to hear them defend their answer so he could understand their perception of the product. As with all these methods, success is highly dependent on how the test is constructed.

I could go on. Indeed, whole books have been written on this and whole careers built on doing it well. My point is not to scare you away from testing – or to reject Lean Startup – but to point out an omission. You can test, and if you can’t afford an expert you can do it yourself. But think carefully, take some time to construct your test, and try to answer questions like these:

• Given your hypothesis, what method might help you get the data you need? What might cut through as much bias as possible?
• Once you’ve chosen a method, what are its limitations? What are all the ways the information you get back might be flawed?
• What “insights” will you need to throw out because they can’t be trusted?

A great test will save you time and money. A poorly-conceived or poorly-constructed test will not only fail to give you the answers you need, it might even send you spinning off in the wrong direction entirely.

Happy testing.

Thanks to Todd Hausman and Cass Sapir for their help in editing this post.

Not a week goes by in which I don’t fantasize about going back to work at a big company. That’s OK: in unfamiliar, uncomfortable terrain it’s inevitable I’ll want to retreat to the familiar. It would be just that: a retreat. I’ve chosen this path because I want to start something myself, because I want to build a company. And as I said, I knew it was going to be hard.

But I’m equipped to do it, in no small part because I’ve spent the last five years at big tech companies – first Yahoo!, then AOL. I was thrilled to be there, surrounded by talented, passionate people who knew more than I did. There were fascinating design reviews, brown bag talks, hallway conversations. There was so much to learn, and I loved it.

As a result I became a better product person, a better designer, a better developer, a better reader of the industry. I learned some of what works and doesn’t work inside an organization. I learned how to manage a team. I found mentors and advisors. And I built up the network I needed to get started on my own. I don’t want to go back to it, but I also wouldn’t trade it.

There’s a debate going on right now about acqui-hires and whether they’re good for the industry. I’ll leave that to folks who know what they’re talking about, but something struck me as I read through the posts so far.

In her criticism of acqui-hires Sarah Lacy wrote, “Not enough people moving to the Valley or coming out of school want to work at companies other people are starting, because it’s so easy to start their own.” In his response Mike Arrington said, “The article that needs to be written is how many entrepreneurs today expect an automatic Hollywood ending to their startup.” Too many young techies are becoming founders because it seems easy and romantic. When, in fact, it’s really hard. (I may have mentioned that already.)

In December I described tech entrepreneurship as “the Bay Area version of the American Dream.” But there are models of American success other than a white picket fence in the suburbs…and there are models of tech success other than Instagram.

If you’re just graduating college, founding a startup might be your least attractive option because you’re explicitly discarding some of the best opportunities to learn from others before striking out on your own.

If you’ve got a product idea burning a hole in your brain and it’s too big to fit into a side project sure, found a startup. But if you want to jump into the fray, work with great people, work on products that affect millions of users, and make a decent living the process – then update your LinkedIn and start interviewing. You’ll probably enjoy it, and you’ll find yourself better equipped to do your own thing in a few years as a result.

And what do you do? Grab a sticky note. Write down the five things you’ll do today, slap it on your monitor, done. Your life is under control again.

There’s a fundamental flaw in today’s productivity apps: the assumption that with a well-organized tool we can keep our lives under control. For most of us that’s just not true. (One glance at my desk should convince anyone of that.) You put ten things on your list and do five. You probably won’t do the others tomorrow, but you can’t bring yourself to delete them…so the list grows. And grows. Until it’s more than you can bear to look at.

Stky is a simple to-do list inspired by that sticky note on your monitor. By anyone who’s ever put a credit card in the freezer. Or taken change out of the vacation jar to pay the babysitter. Sure, it’s about getting things done. But it’s also about the satisfaction you get from crossing off everything on your list; and the freedom of waking up to a blank slate in the morning.

Stky is available now for iPhone and iPod Touch. I hope you enjoy it.

By way of example I’ll pick on Apple again. (They’re fun to pick on in part because they’ve got the basics down.) iOS’s popup “WiFi window” is convenient: it prompts me to join a WiFi network when one is available. I end up disabling it in Settings because it gets in my way: the number of times it interrupts a task far exceeds the number of times I appreciate its convenience.

I don’t even know what a holistic, simple solution would look like. But I suspect introducing a few heuristics would make things a lot better:

• Don’t display the window within one second of a keyboard press. This should take care of the vast majority of cases in which it interrupts typing. If it doesn’t, take it further: don’t show the window when the keyboard is onscreen.
• Don’t display the window within half a second of a tap or other gesture.
• Don’t display the window if the device is moving, e.g. if I’m on a train. This can either be determined via GPS (with possible battery consequences) or by how quickly the lineup of WiFi networks changes.
• Don’t display the window (or decrease the likelihood of displaying it) if the available WiFi networks are ones the user has declined to join in the past.
• Don’t display the window when I’m already in a modal state (slide-up menu, application tray, etc.).
• Do display the window if the user takes an action that requires WiFi. (I think Apple has already implemented this.)

There are probably others, but you get the idea. When designing a potentially annoying behavior, the question to ask is: are there edge cases that can simply be handled via a clever heuristic? Could that make the difference between providing a handy feature and annoying the user?

Atwood writes, “Can you explain to me how Michael Bloomberg would be better at his day to day job of leading the largest city in the USA if he woke up one morning as a crack Java coder?” And of course Mr. Bloomberg wouldn’t. But there’s an implicit assumption that learning to code is the same as becoming an engineer. It isn’t.

Learning to code can mean a lot of things. On one end of the spectrum is the designer or PM who, over time and via trial and error, learns to copy and paste bits of jQuery in order to assemble simple prototypes. On the other is a fundamental grounding in basic concepts – variables, functions, objects, pointers, etc. – provided by an introductory computer science course or equivalent. The former is useful and can be a solid first step. The latter is critical for anyone seeking a career in software development. But it’s also valuable to anyone – far more so than the cut-and-paste stuff.

Mental Models

Like most of us in the software industry, I serve as tech support for friends and family. Why? They’re perfectly computer-literate. Some of them install their own hard drives. My dad just fixed his own motherboard. To borrow Atwood’s analogy, they can “recognize plumbing problems when they see them.”

No, friends turn to me because I have a deeper, more complete mental model of what goes on inside a computer. I can look at the problem and infer whether it’s hardware or software, whether it’s a particular application or the OS. I can suggest a course of action with greater accuracy than they can. How did I get this knowledge? By learning to code.

I don’t know how to change the oil on my car. I should, for exactly the same reason you should learn to code. Sadly, I don’t – I take it to the Subaru place instead. But computers are still in the awkward teenage years between their birth as business and hobbyist devices and their future as fully-serviceable task-centric appliances. The computer equivalents of auto mechanics and plumbers haven’t fully evolved yet, and the devices themselves aren’t as reliable as your car. (It’s acceptable for your computer to crash of its own accord.) Learning the fundamentals of programming gives you the insight you need to maintain your computer in a world that still lacks solid infrastructure to do it for you.

Personal Automation

There’s a poster on my wall full of “Dave-isms” that my team made when I left Yahoo!. One is, “I wrote a script for that.” See, I don’t like doing repetitive tasks. Instead, I stop and write little scripts to do them for me. With luck it saves me time and energy. And even if it’s a wash, writing the script is far more interesting than pressing the same six keys two hundred times.

Computers have tremendous potential to automate our lives. In learning Excel or Photoshop, in signing up for MailChimp, in shopping on Amazon we tap into that potential – but only to the extent that the developers of those apps and services anticipated our needs.

There have been attempts to address this: Apple with Automator, Microsoft with Visual Basic. And if you haven’t tried iftt you absolutely should. But even these tools can be tough to understand if you don’t have some background in programming. And those of us who do know that at some point it’s quicker and easier just to whip up a shell script. Doing so doesn’t require advanced computer science knowledge, or code that scales and performs and localizes to twelve different countries. It just requires a little logic.

Tech Industry Professionals

I’m also thrilled to see so many of my non-engineer colleagues learning to code; if I had my way every designer and product manager would have some programming ability. Not because they should be building the products – there’s a huge difference between being able to code and being a great developer, just as there is between being able to fix your leaky sink and being a great plumber – but because the best teams are built on mutual respect and understanding. Things go better when everyone knows just enough of everyone else’s job to collaborate effectively, to understand what the others are doing and why it’s actually hard.

For designers there’s another reason. A designer’s fundamental job is to communicate. Sometimes the best form of communication is a prototype. And sometimes the best way to prototype a particular interaction is by writing code. Further, sometimes the quickest way to move that button 1px to the left is to edit the CSS or JS yourself.

Give a Man a Fish, and Other Idioms

Atwood writes, “Software developers tend to be software addicts who think their job is to write code. But it’s not. Their job is to solve problems. Don’t celebrate the creation of code, celebrate the creation of solutions.” And he’s absolutely right.

Everything looks like a nail to someone with a hammer; developers run the risk of seeking programmatic solutions to problems that don’t need them. But nothing looks like a nail to someone who’s never seen a hammer. Learning to code puts a powerful tool in your toolbox; you needn’t be a plumber to benefit from owning a wrench.

But perhaps Atwood is simply concerned about a world full of “naive, novice, not-even-sure-they-like-this-whole-programming-thing coders” getting in the way of truly skilled developers, assuming they know best despite all evidence to the contrary. And I’ll grant him, it’s a risk. Ask any designer: they’ve been dealing with it for years.

I got to know Mike and MG while product-managing the redesign of TechCrunch.com as part of my role on Matte Scheinker’s Consumer Experience team at AOL. Mike and I kept in touch after I left AOL to enter the chaotic startup world, and he’s been extremely helpful in helping me find my way. Even as I continue that process I’m thrilled to be able to lend a hand at CrunchFund via my perspectives as product manager, designer, and developer.

For more detail check out Mike’s post over at Uncrunched.