Jason Z. Resnikoff’s Seeing the Sixties and Seventies Through 2001 and Alien is a wonderful essay about his father’s experiences as a computer scientist growing up in the era of 2001: A Space Odyssey and Alien. Here’s a taste:

My father was so buried in computers that when he saw 2001 he very much liked HAL, the spaceship Discovery’s villainous central computer. To this day, he enjoys quoting the part of the movie where HAL tries to explain away his own mistake—the supposed fault in the AE35 unit—by saying, “This kind of thing has cropped up before, and it has always been due, to human error,” an excuse that more or less sums up my father’s considerably erudite understanding of computers. According to my father’s interpretation of the film, HAL wanted to become something more than he was. Becoming, always and ever becoming, is in my father’s eyes a worthy, nay, a noble way to go through life, always trying finally to be yourself, that most elusive of goals. The mission to Jupiter was a mission to take the next step in evolution, and HAL wanted to be the one to evolve. My father made this sound like a very reasonable desire, one that makes HAL the hero of the movie.

It’s a story about two iconic movies, but also about how we used to see the future. Turns out we won’t be space babies after all.

So I guess it’s quarterly “Designers should learn to code” day on Twitter. This appears to be the crux:

Good discussion today w/ friends who are "designers that code." It's no longer even a question of "Should designers learn to code?"

— Nathan Smith (@nathansmith) January 20, 2015

Because that ship has sailed. It's more like… If you're a designer that doesn't code, you'll just be left behind. Not even a debate anymore.

— Nathan Smith (@nathansmith) January 20, 2015

I have two questions.

1. What is a “designer”?

I don’t mean that in the metaphorical sense. I mean literally, how do you define design in this context? Is it visual design? User experience design? Product design? Content strategy, or any or all of the other things that make up well-rounded design?

Because here are the things I’m currently trying to get better at by reading books and practicing and writing and working it into projects:

• Usability testing and ethnography
• Information architecture across multi-platform experiences
• iOS native app design

I’m a little busy right now, so I’d like to know: which of these things should I drop to learn to code?

2. What does “left behind” mean?

Does it mean designers who don’t code won’t get hired in The Future? I don’t know about that. I spend a lot of time with designers. Some of them code, some don’t. Those who don’t specialize in something else that those who code aren’t good at, and that makes for stronger teams where work can be distributed more evenly and more effectively.

Let me put this another way: once every designer can code (since it’s “not even a debate any more”), who’s going to make sure we build the right things? Who’s going to discover user needs, create IAs that work for target personas, and design scalable holistic systems that work across devices and contexts?

What I mean to say is this:

• Heaven help us if we become a community of executors at the expense of all the planners out there. We need both.
• It’s really, really dangerous to tell people they’ll be “left behind” if they don’t become part of a homogenous group of people all focused on the same thing. That has never worked out well for anyone, in the history of mankind.

So go forth, follow the design thing you’re most interested in. If that’s coding, awesome. If it’s how to best understand user needs and translate that into design systems, go do that. As long as you do it well, you won’t be left behind.

The Economist tries to answer the question Why is everyone so busy? and it doesn’t tell a pretty story about ourselves. It starts with the economics of it:

When people are paid more to work, they tend to work longer hours, because working becomes a more profitable use of time. So the rising value of work time puts pressure on all time. Leisure time starts to seem more stressful, as people feel compelled to use it wisely or not at all.

This part makes us sound like terrible human beings, but it’s hard to disagree with:

The explosion of available goods has only made time feel more crunched, as the struggle to choose what to buy or watch or eat or do raises the opportunity cost of leisure (ie, choosing one thing comes at the expense of choosing another) and contributes to feelings of stress. The endless possibilities afforded by a simple internet connection boggle the mind. When there are so many ways to fill one’s time, it is only natural to crave more of it. And pleasures always feel fleeting.

And of course we tell ourselves that one day it will be different:

Writing in the first century, Seneca was startled by how little people seemed to value their lives as they were living them—how busy, terribly busy, everyone seemed to be, mortal in their fears, immortal in their desires and wasteful of their time. He noticed how even wealthy people hustled their lives along, ruing their fortune, anticipating a time in the future when they would rest. “People are frugal in guarding their personal property; but as soon as it comes to squandering time they are most wasteful of the one thing in which it is right to be stingy,” he observed in “On the Shortness of Life”, perhaps the very first time-management self-help book.

This is a long article and I know you’re busy, but try to make time for it…

Sticking with the theme of remote work, Steven Sinofsky wrote a great post called Why Remote Engineering Is So Difficult!? There’s a lot of food for thought, but here’s the main issue:

The core challenge with remote work is not how it is defined right here and now. In fact that is often very easy. It usually only takes a single in person meeting to define how things should be split up. Then the collaboration tools can help to nurture the work and project. It is often the case that this work is very successful for the initial run of the project. The challenge is not the short term, but what happens next. […]

If I had to sum up all of these in one challenge, it is that however you find you can divide the work across geography at a point in time, it simply isn’t sustainable. The very model you use to keep work geographically efficient are globally sub-optimal for the evolution of your code. It is a constraint that creates unnecessary tradeoffs.

Projects often start off ok, but then start to unravel as every small miscommunication and missed messages add up to a much bigger problem. I find this stuff fascinating not just because I work at Jive (where we don’t use email at all), but because we’re seeing such an explosion of remote work everywhere as our tools keep getting better and better.

Steph Yiu’s post Still figuring it out: communicating remotely with lots of people is another good one to read, since she walks through all the tools they use to get their work done. Our setup at Jive is very similar, except that we use our own tool where they use P2 (their WordPress intranet theme).

Adam Greenfield reminds us that the “smartness” of technologies comes from the people who use it, not the technology itself. From The smartest cities rely on citizen cunning and unglamorous technology:

It’s simply that in both these cases, the sustaining interactivity was for the most part founded on the use of mature technologies, long deglamorised and long settled into what the technology-consulting practice Gartner refers to as the “trough of disillusionment”.

The true enablers of participation turn out to be nothing more exciting than cheap commodity devices, reliable access to sufficiently high-bandwidth connectivity, and generic cloud services. These implications should be carefully mulled over by developers, those responsible for crafting municipal and national policy, and funding bodies in the philanthropic sector.

I like the term “deglamorised” very much. It’s a reminder that our goal as designers isn’t to make cool stuff—it’s to help people do great things with the stuff me make.

I really enjoyed Eddie Smith’s The ascent of failure, a post on the many ways our technology can fail us. He starts off with a parenting story that’s infinitely relatable, and goes on to make some good points about how fiddly we’ve become with our technology:

With Yosemite and iOS 8, we have even more interdependence through features like Handoff. Now, a MacBook, iPhone, and iPad are no longer three things but a system of things—an ecosystem with an even higher chance of failure by virtue of sitting atop an ever-rising house of cards.

I think it’s worth pondering the time we spend fixing our tools and toys versus the time we spend solving problems and actually getting to play.

I’m not convinced that having complex tools is a necessary condition for achieving remarkable results.

Maybe this non-complexity is another reason why vinyl is seeing such a revival. Or why paper notebooks are making a strong comeback, spurred on by brands like Field Notes, Moleskine, and the one I personally use (and love): Baron Fig.

There are lots of great points in Chris Hardie’s Distributed vs. In-Person Teams, an article on the challenges and opportunities of remote work. But this part, in particular, stood out because I’ve experienced it myself:

Having some remote workers is harder than being fully local or fully distributed. […] This dual approach is probably a recipe for disaster when it comes to building shared vision and common culture in an organization. If there are team members who have a daily experience of being in the same space together and sharing all of the quirks and benefits of that, remote workers will almost always feel excluded in some way, culturally, logistically or both. When only part of the team is forced to consider the implications of having a distributed group, an unfair burden falls to the remote worker to keep their needs in front of everyone else. At best it adds a weird kind of tension to team relationships, and without incredible discipline and initiative, it probably won’t work in the long run.

This gets even worse when the remote workers are in different time zones. The remote workers are almost always the ones who have to give up their evenings to do Skype calls.

I just posted another excerpt from Making It Right to Medium. It’s called How to avoid building products that fail, and it’s all about starting the product development process at the right place:

When it comes to building products, the starting point is — always—needs. Not what we assume would be cool, but what users or the business need to be successful. […] One of the biggest mistakes we can make in product development is jumping to execution before an appropriate planning cycle has been completed, so we need to give planning the attention it deserves.