Last year I accidentally became an expert on interviewing. I didn’t want to, but hey, we do what we need to do. I just published some things I learned in the process on A List Apart, in an article called How to Interview. Here’s one piece of advice on how to get companies to email you back…

Send separate, personal emails to each of the likely hiring managers you found. Make it really, really short. Don’t go on about how awesome you are—you’ll get a chance to do that later. Tell them you like their company, you like the role, you’re interested in talking. Link to stuff you’ve done: your LinkedIn profile, your portfolio, articles/books you’ve written, etc. Then ask them if they’d be willing to have a call, or forward your information on to the right person. The point is to not burden people. If they see a long email, the chances are high that they will delete it. But if they see a short email that’s respectful of their time and gives them the information they need to make a quick decision—that’s a different story.

I just finished Clive Thompson’s Smarter Than You Think: How Technology Is Changing Our Minds for the Better and really enjoyed it. So much of what we read about technology these days is doom and gloom that I wanted to spend time on something a little more positive. And turns out, there’s much to be positive about.

There are many stand-out moments in the book. One is the exploration of ambient awareness — how social media often makes our in-person connections stronger because we know so much about each other’s minutia that we can skip the small talk and jump straight to the important stuff when we see each other. But the part I want to elaborate on a little bit here is what historical events tell us about the important criteria to meet for collective thinking to be successful.

Clive points out four important aspects of successful online collaboration:

1. Collective thinking requires a focused problem to solve. One disastrous story Clive tells is when the LA Times create a wiki page on the Iraq War and encouraged people to edit it. No focused outcome = a rapid decline into the bottom half of the internet. But give people a common problem to solve — like “Which tent hospitals in Cairo need help, and what do they need?”, and people start to shine together.
2. Collective problem solving requires a mix of contributors. Specifically, it needs to have really big central contributors, and then a lot of people making small contributions to push the solution forward. As Clive puts it, “these hard-core and lightweight contributors form a symbiotic whole,” coming up with the best solution in the fastest possible way.
3. Collective thinking requires a culture of “good faith collaboration”. Contributors need to struggle constantly to remain polite to each other. And it is a struggle, but a necessary one. As Anil Dash once said, if your website’s full of assholes, it’s your fault.
4. To be really smart an online group can’t have too much contact with each other. This sounds counterintuitive, but the evidence supporting the point is pretty overwhelming. Clive goes over a few examples that shows that “traditional brainstorming simply doesn’t work as well as thinking alone, then pooling results.” This also explains why Design Studio is such an effective way to solve design problems. So one of the secrets of online collaboration is that it “inherently fits the model of people working together intimately but remotely,” as Clive puts it.

There’s much more to say about the book, but I think I’ll stop here and just encourage you again to read it. You’ll agree with a lot of it, disagree with some of it, and think about all of it for days after finishing it. That’s all we could ever ask of a book.

I wrote a story about jazz, coffee, and liner notes, and hopefully managed to turn it into something with a logical conclusion. But feel free to judge for yourself by reading Taking back the music:

We like things fast and disposable — I get that. I mean, no one even knew what the word “ephemeral” meant until Snapchat came along. But moving quickly from one thing to the next will just never be as satisfying as really spending time with something or someone, with no escape from the person or the artist’s intentions and successes and failures. We can all do with a little bit more of that.

Bill Selman wrote a great post on the importance of research triangulation. If you have trouble making the case for qualitative research in a company smitten with “big data”, show them Why Do We Conduct Qualitative User Research? (emphasis mine):

There is no one research method that satisfies answering all of our questions. If the questions we are asking about user behavior, attitudes, and beliefs are based solely on assumptions formed in our homophilic bubble, we will not generate accurate insights about our users no matter how large the dataset. In other words, we only know what we know and can only ask questions framed about what we know. If we are measuring, we can only measure what we know to ask. Quantitative user research needs qualitative user research methods in order to know what we should be measuring and to provide examples, theories, and explanations. Likewise, qualitative research needs quantitative research to measure and validate our work as well as to uncover larger patterns we cannot see.

Paul Ford knocks it out of the park again in What I learned about hatred from my tiny daughter, an essay about collective anger on the internet:

When you aggregate enough people and get them to talk about design they become, basically, a single giant toddler.

There are some wonderful and surprising stories in Ian Urbina’s The Secret Life of Passwords:

SEVERAL YEARS AGO I began asking my friends and family to tell me their passwords. I had come to believe that these tiny personalized codes get a bum rap. Yes, I understand why passwords are universally despised: the strains they put on our memory, the endless demand to update them, their sheer number. I hate them, too. But there is more to passwords than their annoyance. In our authorship of them, in the fact that we construct them so that we (and only we) will remember them, they take on secret lives. Many of our passwords are suffused with pathos, mischief, sometimes even poetry. Often they have rich back stories. A motivational mantra, a swipe at the boss, a hidden shrine to a lost love, an inside joke with ourselves, a defining emotional scar — these keepsake passwords, as I came to call them, are like tchotchkes of our inner lives. They derive from anything: Scripture, horoscopes, nicknames, lyrics, book passages. Like a tattoo on a private part of the body, they tend to be intimate, compact and expressive.

I now use 1Password to create unique passwords for each service, but the article did take me back to the one password story I do have. Back in college, when it was time to select a password I could remember easily, I remember leaning back in my chair and giving it some serious thought.

I had just seen Patch Adams and top of mind for me was part of a poem the character recited that really stuck with me (full version here):

I know it’s ridiculously syrupy, but I apparently used to be a romantic. Huh.

Anyway, my default password became two words from the poem, smashed together. Even though I don’t use the password any more I just can’t get myself to tell you which words, though. I guess some of this story needs to remain mine alone.

There are a few controversial ideas in Benjamin Sandofsky’s You Can’t Go Home Again, in which he basically says that Agile methodologies shouldn’t be used in mobile app development. I did find this perspective on QA interesting in our increasingly post-QA world:

Sit down with a software engineer from anywhere but the web, and ask them about QA. Tell a game developer you don’t need it, they’ll tell you you’re nuts. Maybe these agile people have been burned by bad QA, but a great QA team is far from a bunch of monkeys clicking buttons all day.

Formal QA provides a counterpoint to “move fast and break things.” Their job isn’t to say, “No.” It’s perfectly fine to ship bugs– otherwise software would never ship. You need someone who is aware of all the bugs, and help you make the decision if the risk is worth it.

Also see Michael Lopp’s The QA Mindset for some really good perspective.

Dan Lockton’s As we may understand is unnecessarily long and rambling at times, but it’s still worth it for the very interesting views on the Internet of Things and designing for behavior change:

Many of the issues with the ‘behaviour change’ phenomenon can be characterised as deficiencies in inclusion: the extent to which people who are the ‘targets’ of the behaviour change are included in the design process for those ‘interventions’ (this terminology itself is inappropriate), and the extent to which the diversity and complexity of real people’s lives is reflected and accommodated in the measures proposed and implemented. This suggests that a more participatory process, one in which people co-create whatever it is that is intended to help them change behaviour, is preferable to a top-down approach. Designing with people, rather than for people.

Again, it comes down to understanding people and their needs before embarking on a design. I wonder if we’ll ever fully learn this lesson.

Also see:

• Can Technology Really Change Your Habits? (Fast Company)
• There’s a backlash against nudging – but it was never meant to solve every problem (The Guardian)