• "“coding” is not the only concrete skill required “to work at the crossover of creative and technology”. Especially if you want to make an actual thing that lives outside of a screen." I'll gladly concede Josh's point. This is very much worth reading; if anything, the only reason I focused on code was the original W+K focus on that, likely because that's the technology they're interested in. Good points all, though.
  • "Since I got my iPhone 4S, I’ve been intrigued, fascinated and alarmed by Siri’s fast-growing capabilities. I thought it would make sense to introduce her to my psychotherapist, Eliza." Now I think about it, surprised it's taken someone so long to do this (considering all the other Siri 'gags' floating around).
  • "Software development is not pure coding, engineering, architecture, management, or design. It is cross-disciplinary. Better yet, it is its own discipline. It is more akin to making a movie than to building automobiles on an assembly line. The studio revolves around talent. Great software talent means renaissance developers who have passion, creativity, discipline, domain knowledge, and user empathy. These traits are backed by architecture, design, and by technical know-how that spans just knowing the technology flavor of the day. Process is the studio; it has structure but is flexible enough to optimize talent and tools." This post is as dogmatic as what it rails against, but it's good at finding flaws in dogma and then pushing towards a more sympathetic view. And this paragraph is the best bit.

I was all ready to get really worked up about this post from Wieden + Kennedy, on “why we’re not hiring creative technologists any more; we’re hiring coders”.

Then I went and read it, and basically agreed with it all very fundamentally. In a nutshell: it’s not resisting the name, or the approach; it’s resisting the idea that it’s something you can pick up quickly on a course to teach you to become one. Which is, like so many similar things, nonsense; I hadn’t realised we’d hit that point on the sliding scale. When Igor says

“Only hire people to work at the crossover of creative and technology if they have strong, practical, current coding skills.”

I say: of course; why would you do otherwise? I thought that’s what that job title meant. I seriously didn’t realise that was happening, and I’m very concerned it does. This is worth taking very seriously: if you want people to think through software, they need to be able to make that software. Not wave their hands around and have ideas about technology. We think with our hands, be we artists, designers, developers, or writers. Having another layer of people to “have ideas” is not what you need. Ideas are free.

I still use that particular title to describe myself a lot, simply because I’m not best at being your average Joe Developer. I can; I have been; it’s just not my sweet spot. I’ve made reasonable scale projects that work well; I understand how to go from a fragile prototype and turn it into solid reality, and what making things work under load looks like: and yet the bit I’m good at, the bit I care about, is the going-from-nothing-to-something-working. How will you know what a thing is until you’ve held it in your hand? How fast can you change it as you learn from it? When’s it best to step away from vim and go back to pen and paper? That’s me.

So: I totally agree with Igor about the fact that whatever you call that role, it has to have solid, actual coding chops. Not a smattering of Processing here and some weak PHP there: actual, full-on, end-to-end skills. Code that’s live in the world.

But: the most interesting thing in the article wasn’t even the stuff about Creative Technology. It was about what it means to be an agency – or, being honest, a company – that wants to engage with technology through staff members like these.

While you don’t need to become an engineering company, you face some of their challenges. You need to understand, accept and embrace some of the nuts and bolts of software development, and take on board the work dedicated shops are doing on its processes. You need such a strong streak of code running through the atmosphere that coders want to come to you, and everyone else gets code spilling over them.

This is so true. You can’t just slap technologists or developers into a company to become a technology company. Technology has its own heartbeat, its own demands. You have to begin to wrestle with the processes of an engineering company, of an attitude that leads to better work. You have to learn how it’s going to shape your culture – by which I mean, how you want it to. You get to choose; you get to control these things. It will change it, that’s for certain, but you get to hae some control over it. And similarly: you have to resist it just enough to stop becoming nothing but a software house; to retain the “creative” streak you were trying to hang onto when you started hiring for that job title.

The article it ends in this nugget:

this is hard, and it’ll take time. It’s not just procedural, but cultural, so a big part of doing it comes down to who you hire and how you let them do their thing. But that’s exactly the point. That’s why it’s most important, way before you get all that fixed, and as the first major step on that road: just don’t hire “creative technologists” who aren’t strong coders.

Yep. That’s his real point: the headline is attention-grabbing, but here’s the meat, and the most important line here is this is hard and it’ll take time.

It’s a cracking post. It’s all true. I’m going to stick to my guns and say I’m a technologist, of some kind: what I am best at is not one thing, but a mish-mash of things, and I’m better for the diversity of them. But I’ll also stick my head up and say yes, at the end of the day, if you want the Whole Thing Just Made: I will do that. I can do that. That’s why I get to use the T-word.

My only other advice for filling these positions: you don’t just need people who can do these things; you need people who can’t not do these things. Their instinct when faced with problems ought to be “let’s see what works; let’s check the assumptions we’re making are true by Just Doing It.” It’s not about jumping the gun: it’s recognising when you need to feel something, rather than guess something. And you don’t want to have to train that: you want people who just have to know for themselves.

So yeah, if you’re in one of those places that isn’t a software company, but you increasingly need to be a software company because, as Igor says, we have to be – that’s what the modern world now looks like – then it’s a really, really sharp piece of writing. I went in sceptical, but really: it was telling me what I already believed, and confirming it, and that’s a good thing, because it’s a message that needs to be written, not just assumed we all know. Good stuff.

  • "All operating systems know when they were born. Their internal clocks start counting then, so they can calculate the date and time in the future. It is unclear whether it was Mr Ritchie or Mr Thompson who set the so-called start Unix time at January 1st, 1970. That moment came to be known as the epoch. Mr Ritchie helped bring it about. And with it, he ushered in a new era." Which is as poetic a way as any of expressing how deeply rooted K&R are in the modern world.