Why does the Valley want designers that can code? Because the Valley doesn’t understand what designers do.

Jared Spool recently posted about “Why the Valley wants designers that can code.” Basically, he makes the good point that hiring managers at startups are always looking for ways to get more value for their dollar. And so based on that understanding he recommends “If you’re a designer, you don’t have to learn to code. But if you do, and you get good at it, you’ll find more opportunities as time goes on.” And in this he’s right. But of course his comments would be just as valid if he wrote a post titled “Why the Valley Wants Marketers That Can Code.” Or Engineers that can write press releases. Or any other combination of useful skills.

Except… the Valley doesn’t want marketers to write code or engineers to write press releases. Because, they don’t trust marketers to write code, and they feel that writing press releases would be a waste of the engineers’ valuable time and skills.

So what’s the real reason that many companies look for designers who can code? Because fundamentally they don’t understand and therefore properly value what great software designers do.

Spool says: “If you’re in a room filled with designers, bring up the topic of whether it’s valuable for a designer to also code. Immediately, the room will divide faster than Moses split the Red Sea. One side will tell you coding is an essential skill, while the other will vehemently argue how it dilutes the designer’s value.” If I’m in a room full of designers and any of take either of these positions, then I’m in a room full of designers I would prefer never to work with.

High quality software designers are true singer-songwriters. They can deliver a combination of interaction and visual design that don’t just make a product shine, they make the product what it is. They create its essence, its DNA. Should they have deep empathy for the software development process? Yes. Should they understand technology and be “technical” to a degree? Yes. Should they have passion for software as their medium? Yes. Much like a designer focused on print projects should understand how various ink/paper/press combinations will impact their final product’s design as well as cost, software designers should understand the canvas on which they are painting. But do I want a true software designer spending time fighting the various inconsistencies between browser CSS implementations to get the UI perfect? Nope. It’s a waste of their time. They should be doing more designing.

(If you’re annoyed by the previous paragraphs, this next one will make you crazy.)

Are there true singer-songwriter software designers that can write high quality code? Yes. But they are the exception. Anecdotally, I’ve found that most (not all) “designers” who can code are in fact coders who have empathy and passion for design, and may even have some good interaction design chops. But often they are weak when it comes to visual design. In our left-brain dominated industry, visual design is often looked at as fluff. Often people will say things like “art is the last step” or “that’s the lipstick”. I believe that when you treat the visual elements as some sort of layer of paint, then all the visuals can be is a layer of paint. And I believe that most “designers that can code” aren’t really designers at all.

The worst part is that design schools are complicit in this misunderstanding of what software designers should do. They’re busy teaching HTML, CSS, and Flash (yes Flash) to art students as if these skills are mandatory for them to succeed as high end software designers. These potentially talented software designers have an allergic reaction to spending their careers writing markup instead of drawing and decide to focus on “print”! Print! Pardon the profanity, but… WHAT THE FUCK??? The most incredible canvas in the world for designers — software — exists, and needs them. It lets them combine text and images and video and audio and user interaction in incredible ways, but they want to go make business cards and annual reports. Our industry needs a fleet of talented software designers and design schools are failing to produce them.

At some point, we will have more than a smattering of true software designers in this industry. They won’t be employees either. They’ll be founders and co-founders. And their companies will produce beautiful usable products that stand out from their competitors. And some of these designers will even be able to code. But we won’t let them, because we’ll want them spend every minute designing beautiful software.

A note: I’m sure that some of you will take exception to this post. Many of you will be annoyed because you either subscribe to the notion that designers should code and that it’s a good thing, or that you are designer that writes code and you are annoyed that I question your visual skills. Understood. I hear you. Please know, just because someone doesn’t fit the model of the designer I think we should be replicating, doesn’t mean I think they aren’t a valuable contributor.

And finally, some of you may criticize me and say that it’s easy for me to lobby for this model for software designers when my co-founder Jenny Lam exemplifies it. And to that I will say… you’re right.

Does HTML5 mean the end of the native app? (In other news… Phillips head screwdrivers will kill flat head screwdrivers!)

I just happened upon an article by Matt Marshall on Venture Beat: “How HTML5 will kill the native app.”

Ugh.

This article reads like an HTML5 marketing document. There’s good reason to be excited about HTML5. But I believe there are a couple of key things missing from this discussion:

1. The value of cross-platform code to developers is a myth. — Yes, many people say they would love to standardize on one platform and write once and save “billions”. But in reality, developers like to learn new skills, platforms, and languages. And clearly having to rewrite code to a brand new platform hasn’t stopped hundreds of thousands of apps getting written for iOS. The best modern developers are well-versed in a variety of client and web-based technologies and platforms, and recognize that one solution doesn’t fit all. And ultimately they, and the businesses that employ them will flock to any platform that has a real promise of commercial success and novel functionality no matter how much new code they have to write. Do we really think iOS is the last time that a new platform will attract tens of thousands of developers to write hundreds of thousands of new apps from scratch? If that’s true the software industry is dead.

2. HTML5 has still not addressed a critical piece of the UX — responsiveness. – HTML5 and it’s predecessor Flash have are not focused on the degree of responsiveness we demand from really polished software. It’s true that in many cases, we don’t need instant responses. And with the advent of AJAX style development web-based apps have come a long way from needing to reload the page every time you make a state change. However, the fundamental value of an HTML page (and app) being able to load progressively is often counter to the type of rock-solid responsiveness that we need from many software experiences. I know that most user’s will live with little delays and not even be able to articulate that there’s a problem. But like the soft click of a door closing on a well-engineered luxury car, customers do know when something just “feels right” (and conversely… when it doesn’t). When I can load thousands of items in a list on a webpage without having to do pagination, when that loading feels instantaneous (even though there may be progressive loading of the data into memory), and when scrolling feels smooth as butter and super fast, then I’ll feel like web apps are getting closer. I don’t think there’s a technical limitation on this per se in HTML5, it’s just that it’s not optimized for these types of interactions. Responsiveness is one of the unsung heroes of a polished user experience, and even with all its innovations and AJAX goodness, GMail can still be frustrating to use for heavy mail users.

To be clear, I’m a fan of HTML5 and here at Jackson Fish Market we will use it as appropriate. It’s a tool, like many other tools in our toolbox. We’ll use it when it’s the right tool for the job. And we’ll use other tools when they are appropriate. The most rational and easy to work with developers I know share this philosophy. I’ve found that developers who like to spend lots of time arguing about which tool is the “end all be all” are doing me a favor by letting me know up front that I shouldn’t be working with them.

Management is the Disease

I’ve been management at various companies, and I’ve certainly been subjected to management at the same companies. I’ve been a victim of this disease and I’m not proud to say that I’ve also been a vector for it. That said, management is the disease in almost every fucked up company.

It comes down to management’s reason for existing. Management exists to make sure the people under them do a good job. This assumes that a) you’ve hired people who without management won’t do a good job, and b) that the people in management have any ability to identify what “doing a good job” looks like. But here’s the worst part. Let’s say that you have hired people who do a good job, and management actually knows what it looks like. It’s still against management’s best interest to let good people do their jobs well without intervention. Because if everyone’s doing well on their own, then management has nothing to do. And because management gets paid more than others, they have even more incentive to look busy and useful even at the expense of good people who just need to be left alone to do their jobs.

As a cherry on this shit sundae, if it’s understood that management’s role is to make sure that the people under them don’t make mistakes, then every decision has to be evaluated with a scrutiny that it often doesn’t require. After a screwup, why would any manager explain to their uber manager that the mistake was worth it because it was the most efficient way to learn the right path forward. The uber manager’s only logical response would be: “then why do I need you here if I can just let people find the right path through conscientious and thoughtful trial and error”?

And that after all is the exact right question to ask about almost every single manager in your organization. Why do we need them?

I say put ‘em to work.

Trade publishers need to get way better at selling their eBooks… to resellers.

As part of my job here at Jackson Fish Market when I’m working on our children’s book service, A Story Before Bed, is to license books for our library from children’s book publishers. (BTW, I recently read an article where Netflix has at least 80 people doing this job for them for movies. ;) ) Getting most publishers on the phone or to respond to e-mail is pretty hard in its own right when you’re a small reseller, much less getting an agreement with them. Despite that we have over a dozen publishers whose books we sell, and we have more lining up all the time. That said, it’s super hard.

Where I really should be spending my time is in selling their books by making sure we have the absolute best possible experience on our service. But instead, I’m making phone calls, bugging publishers, and sending contracts back and forth.

Since I come from a software background I keep thinking about the web services I use. What if much like Amazon’s web services, or services like Heroku, iStockPhoto, or even Amazon’s Associates program I could just go to a website, fill out a form, and start selling trade publishers’ books on my service?

I recognize that publishers have traditionally worried about the context in which their books are sold. And that they may still believe that the digital book marketplace will narrow down to just a couple of players that they need to deal with. This seems so fundamentally backwards to me. If Amazon is worried that I’ll host a site they don’t approve of using their back end they put it in their terms of service. And if IP protection is the issue, iStockPhoto also puts the guidelines in their license to the material. I’ve even heard… “you won’t sell enough books for us this year to justify how much it will cost us to assign lawyers to review your agreement.” Maybe the right answer is not for each reseller to sell some larger number of books, but for the publisher to lower their own costs of letting smaller resellers sell their books. After all, how can small resellers become bigger resellers without being able to sell the publisher’s books?

I understand that a publisher could give me a long list of the challenges in doing this.

However, I believe that today’s book publishers should believe that the scenario where they can let a thousand resellers bloom is the one they want to enable in a friction-free fashion. I am convinced that once they focus on that scenario, the problems they need to solve in order to make friction free relationships with resellers will be eliminated.

Today at Digital Book World in New York City, Michael Shatzkin said that he thinks the thing that separates trade publishers from other publishers is that they depend on others to sell their books. He added that it’s a good thing for many publishers as they infrastructure and expertise necessary to sell directly to consumers is non-trivial. So if a trade publisher’s only customers are its resellers, why would their infrastructure be designed to exclude most of their potential salespeople?

Yahoo learned this lesson the hard way with overture. They designed their ad system to focus on the largest part of the market – the advertisers with the biggest budget. Google took the exact same ad placement concepts and opened them up to everyone – even mom and pop dry cleaners. We know what happened here.

I’m happy to say that our publishing partners, all fundamentally understand this to some degree. They work every day to lower the barriers for more resellers to be able to carry their books. They don’t focus on whether their reseller partners will sell 1 or 1000 books for them that year because they know that the more resellers they work with, the more books they’ll sell. And isn’t that the point?

‘More Features’ Won’t Save a Dying Business Model

I love being in the software industry. So many things are being reshaped right now and I get to participate in my own small way. Here’s a vision piece from some European newspapers describing the newspaper of the future.

News+ concept live from Bonnier from Bonnier on Vimeo.

The problem is, there’s really nothing new here. Yes, this seems great. Basically go down the checklist of every feature that the internet and sexy hardware devices have, and leverage them all to make a digital newspaper. Tablet? Check. Roaming across devices? Check. Video. Check. Photography? Check. Discussion with the writers? Check. Alerts? Check.

I get it. I get it.

I’ve been on many projects where my team’s job was to come up with videos and prototypes exactly like this one.

Here’s the problem. Maybe a better newspaper, a digital newspaper, a newspaper that leverages all of the features that are sexy on the web and touch devices today isn’t what anyone wants. Or certainly isn’t what anyone is willing to pay for to the point that would support the infrastructure necessary to create this kind of production. Maybe the problem that newspapers are facing is intractable. Maybe there simply is no solution and they have no choice but to die.

It’s not the news business that’s dying. It’s the newspaper business.

The same seems true of record labels. Their economics just couldn’t last in this new world. People still love music. People still pay for music. It’s just the economic structure of record labels that is becoming extinct.

Adding more features is easy. I get asked to do it all the time. Unfortunately, I’ve never seen a situation where even the greatest collection of features can overcome the fact that the core of the experience isn’t something people want (or want to pay for).

I’m not saying that finding those core experiences is easy. It’s not. I just feel bad for all the effort and resources that went into this video and countless other visions like it. The blogs and websites I read, the google alerts I use, the social networks I frequent, all give me this experience already today. I don’t need a newspaper to deliver it to me in one package.