I'm a long-time fan of Brian Eno. Not only his music and art, but also his approach to the creative process and creative problem solving.
As I was watching a recent interview of Eno from the Red Bull Music Academy, it struck me how many of the things he said had relevance to software development - as I'm sure they do to most creative endeavours.
What follows are my reflections as a programmer on some of the points Eno made during the interview.
Lecture: Brian Eno (New York, 2013) from Red Bull Music Academy on Vimeo.
1. Realize The Reach of Your Work
Because we come from a culture that wants to create heroes and champions, we tend to do that in the expense of realizing that nobody comes out of nothing, that we're all borne out of complicated scenes, which of course in the case of music involve technology a great deal.
Whoever invented and wrote the code for Logic — which I know was a lot of people — is their musical contribution less significant than, say, Coldplay, or any other group you can mention? So much music is made out of the possibilities of that particular system. So you can't look at what is happening in music now, without looking at the technology that gives rise to it.
Just like the programmers behind Logic are contributors to all the music that's made with Logic, you're a contributor to everything that's done with the software you write. I think we too often lose sight of this fact — especially when there's a separation between us and the users.
This effect is perhaps largest with open source software. A contribution you make may affect the lives of people you've never heard of, in places you've never been to. To take a couple of extreme examples, I don't think John Resig was thinking jQuery would be deployed on 20,000,000 websites when he was making this commit. People who have committed to Linux have their code running everywhere from the server running this blog to the Large Hadron Collider and the International Space Station.
Of course, the same effect happens on smaller scales too: Even if you're writing the most inconsequential internal enterprise system for 20 people, what you do makes a difference to those 20 people. Say, if you get the user experience right in something, you'll make someone's day that much better, even if they use it only once. It's a powerful thought.
2. Be Part of A Sound
When talking about an a cappella choir he has in London, Eno says:
The most interesting thing that happens is that occasionally I'll have a friend drop in who's a famous singer, or other. And they are the ones who find it most difficult to join in, because the point about being a choral singer is that you don't stand out. You become part of the sound, you don't try to stick out.
Whenever we have classically trained singers come in, they always have to hold the note a little bit longer than everyone else, as if to show you that they can. Whenever we have good lead singers, they always kind of wobble about all over the place and dive through the other singers, and so on. It's like having an unruly parrot in.
The singers that really seem to work well are people who just want to be part of a sound. They don't want to present themselves in particular. And that's a kind of stepping back from individualism in favour of a community sound.
In most professional settings, software development is a team effort. We do most of our work with other people. And since we're social animals, the quality of the interactions we have with the people we work with matters a whole lot. All the most enjoyable work seems to happen in settings where there is a cohesive team focusing on a common goal together.
Working in a team seems awfully similar to singing in a choir. In both cases, individual efforts are combined to form an end result that's larger than the sum of its parts. While everyone is putting their best efforts into it, the results suffer when someone tries to dominate over the others too much.
There's a long standing discussion in the community on whether hiring only "superstar programmers" is the way to go, or whether you should be optimizing for the balance of skills and personalities in a team. In any case, for each of us individually it's probably a good idea to try to be the best programmer you can be as an individual, and then use those skills to help other people out whenever you can. This second-order contribution improves the overall sound much more than your individual voice alone ever could.
3. Misuse Technologies
You have to find out how you can fuck up new technologies, and that usually takes a few years, because technologies are always invented for a historical reason.
For instance, if you think about multitrack recording, that wasn't invented so that Phil Spector could create walls of sound, it wasn't invented so that myself and Shuggie Otis and Prince, and so on could build up pieces of music over a series of months. It wasn't invented so that any of you could sing a 40 piece choir. It was invented so that recording engineers could balance the voice against the rest of the music. That was the modest and simple idea that gave rise to multitrack recording. It was just a convenience for engineers.
What always happens, I think, is that technology appears, it does something historical — and historical can mean it does a job we could already do but it does it quicker or cheaper or more portably or anything else — but it's basically a job that we already knew about. But as soon as the technology sits there, then some person comes along, and thinks “you know, you could do something else with that that nobody's ever done before.”
We shouldn't be afraid to use technologies for purposes they weren't designed for, or "clearly aren't suitable" for. If you look at the history of software (or the history of any technology really), it's full of cases exactly like the ones Eno describes: A technology was created for a historical purpose, but then its invention gave rise to something completely different.
Java was designed to be embedded in digital televisions, but now it's serving much of the Internet. Linus Torvalds wrote Git for the purposes of the Linux kernel team, and now it's used by 40% of the enterprises - whose code collaboration practices are usually nothing like the Kernel team's. This has given rise to products like ours. John McCarthy designed Lisp as a mathematical notation for software, but then Steve Russell went ahead and wrote and interpreter for it, and here we are. Facebook has stretched PHP to lengths no one had imagined. At Netscape in 1995, Brendan Eich was not deliberately writing a language that would be possibly the most deployed language in the world 20 years later.
Take your favourite technology and use it for something totally inappropriate. "Fuck it up." You might discover something new. At the very least, you'll learn something new.
4. Prefer Simple Tools
With modern technology, one of the biggest difficulties is cutting out options. So actually that's the problem with digital technology. Because options keep proliferating.
Doesn't it strike you as interesting that here we are, in the second decade of the 21st century and a lot of the most interesting music is still being made by people playing very primitive instruments like electric guitars and drums? Compared to all the fabulous possibilities of software synths, and so on, that we have in a program like Logic. Well, the reason is because it's hopelessly limited.
The reason is you very quickly can understand what you can do with an electric guitar or a violin, or a set of drums, and you stop looking for more options and you start grappling with it. You say "OK, this is what it does, so what do I do?" The problem with software based work is that you can never exhaust what it does, basically, so you can always cover the fact that you haven't got an idea by trying another option in the tools.
If you have a lot of options, you don't usually have a lot of rapport with the instrument. If you have a few options, your rapport keeps increasing because you understand the options better and better. And this is why people still make good music with crude instruments, simple instruments. Because they understand them better than us software people understand our instruments.
There's something appealing in simple tools in favor of complex ones.
To me, this is most pronounced in programming languages. Clojure, for example, is a simple language. It is so simple that you definitely start feeling you're building rapport with it, as soon as you've grokked the syntax and the central concepts.
In some sense I'm still not as comfortable with Ruby as I am with Clojure, even though I've been using Ruby for far longer. I suspect this has something to do with the fact that Ruby is a decidedly non-simple language with its Perl legacy. Python on the other hand does seem to share this philosophy of language simplicity with its "there's only one way to do it" motto.
Simplicity is also a nice attribute to have in libraries and tools: Unix is the canonical example of this, with its pipes and filters architecture.
It is also much easier to reason about a system that has, say, persistence and message brokering as separate components, rather than one component that attempts to do some of both. Rich Hickey has recently given some excellent talks on simplicity in software architectures.
5. Flex Your Creative Muscle
When I'm working with other people, one of the things I spend quite a lot of time doing is banning options. For instance, one day in the studio I said "today there will be no multiplication of any kind."
Now, if you think about that, that cuts out most of the things you do in the studio. It doesn't only mean no double tracking, it means no echo, no repeats, it means no process by which you synthetically duplicate things. So if you want to echo, then you have to find some other way of doing it.
Another kind of option-cancelling device is to say "let's not use anything on that side of the room." Or, one that I particularly favour is to take away all the cymbals from the drums, for example. They're totally redundant things most of the time anyway.
When you get stuck on a problem, see if you can get somewhere by deliberately limiting your options by, for example, saying you won't use any conditional statements in your code. You might not get the best possible results, but you will force your brain to approach the problem from an angle it otherwise would not have.
There's a similar technique you can use when learning something new: Identify a characteristic of the new thing that seems difficult to you, and take it to the extreme in order to force yourself to learn it. If you're learning object-oriented design, try Object Calisthenics. If you're learning functional programming, do it in a purely functional language like Haskell instead of a hybrid like Scala. If you're getting into iOS programming, do it in Objective-C and XCode instead of trying to take a shortcut with something like RubyMotion. Push for a steeper but shorter learning curve and you'll start reaping the benefits sooner. (Then you can take RubyMotion for a spin.)
6. Don't obsess about doing things Properly™
The reason we like The Velvet Underground is not for their gloss. It's for their roughness, for the feeling we have that this was really just breaking out and they didn't know how to make it better. Because when something is new you don't know how to make it better. In fact, you don't even consider that you could make it better, you just go "Jesus, this is amazing". The newness is such a big thrill, that it's not even relevant to you to clean up all the edges.
All the bureaucrats come into the process later on, when everybody sort of understands it, they look back and they say, "The Velvet Underground, they were great, but a bit out of tune, and now we'll do the popular version of The Velvet Underground, the commercial version. We'll get everyone in tune, get some decent sessions musicians in, get a proper drummer instead of that woman from New Jersey."
Much of the remarkable software in the world wasn't done Properly™. Much of it was done by people who didn't know what they were doing, often with tools that weren't designed for their purpose (see 3). Just ask the Reddit guys.
Rails got a lot of attention like this early on. There were a lot of those "it can't possibly work because it doesn't even have..." arguments flying around. And Rails didn't have a lot of things. It didn't even support composite primary keys. Or dependency management. It even kept leaking memory all over the place. But people were building things anyway. Somehow they made it work. The rough edges didn't matter, because it was such a big thrill working with something that felt actually productive.
Twitter, for example, was initially built with Rails. They actually built it as a fairly standard MySQL-backed Rails application. Then they got millions of users, and had to migrate to technologies better suited for building a real-time messaging system. But they had shipped something and succeeded, even though the technology didn't turn out to be Proper™ for them in the long term.
By now much of the things that Rails brought in for developers have spread across all the major technologies: Things like convention over configuration, database schema versioning, first-class testing support, and deployment automation are everywhere. Even in Proper™ technologies. What's going to be the next "can't possibly work because it doesn't even have..." thing? Meteor, perhaps?
I've always thought that two things that really make for good records are deadlines and small budgets. The things that make for bad records are no deadlines and endless budgets, cause you can piss around forever with that.
I remember working with one famous band. I had heard something they'd done in the past and I thought they just spent too much time on it. You all know what that sounds like, when something has been sort of beaten to death, basically. Every detail has been finessed so many times that there's no life left in it. It's a little bit like British cooking before 1970.
I took this band to a very good Italian restaurant in London, and I had already arranged with the manager that I could take them into the kitchen. So this is a fantastic restaurant, very famous, very cool, with impeccably dressed waiters and good service. It's all very chic. And you go into the kitchen and it's like a scene from hell. There's people dashing around and swearing and food flying everywhere and it's incredible, watching something being cooked there. It's like, great ingredients, as little as possible time spent in the pan, and then it's on the plate. This food tastes like it's fresh and exciting and thrilling. You can feel the speed of the preparation, actually. You can feel the life in the whole thing.
And so I said this is how we should make records. It worked for a few days.
Having hard deadlines can be stressful, but it's also useful if you actually want to get things done. As software developers, we have a tendency to keep polishing our designs in the search for the perfect abstraction or the algorithm that gives that last 4% performance increase. And there is certainly value in trying to find the best possible solution. The thing is though, software that isn't being used has zero value. Until that code has shipped, it is dead weight. It's waste of inventory.
This is why it's good to have deadlines. When you have to ship, you can't keep messing around. You will need to make some compromises, but that's ok – perfect is the enemy of good. If you're not quite happy with the results, you can keep improving them after you've shipped (though often you'll need to convince your customer first to pay for that improvement).
What's been interesting for me when moving to a startup is that while budgets are certainly limited, there are often no hard deadlines, because there's no Customer to set them. The users of your product don't usually do that. In this situation, I've found it useful is to set arbitrary deadlines for myself, to force myself to ship early and ship often.
8. Embrace The Connected World
When one used to use studios, you'd shut all the doors, it would be very much a sealed closet, you were inside the music and you didn't want to hear anything else.
But what I've noticed now with most of the young musicians that I work with, is that they are constantly listening to other things. So James Blake, for example, a little thing came up and I asked "Have you ever heard Peace Be Still by James Cleveland? It's an amazing experience", and we'd listen to that and we didn't then go and copy it, but it changed what we did afterwards. Because it has this amazing moment in it, there's nothing else like it in music as far as I know. This moment where an absence is incredibly powerful, there's only a huge hole where the music falls into.
People never used to do that in the studio. It was the old idea of the artist who's working entirely from his own mind and it all comes out of there and nothing else in the world is relevant. Of course that's never been true with music, but now it's often more acknowledged in the studio that you're working in a scenius, basically.
We often have this idea of programming as a solitary activity. You disappear to your basement, cut all contacts to the outside world, and spend a few months submerged in deep thought. Finally you emerge with a meticulously crafted, beautiful piece of software. There's something appealing in that idea.
But we don't really work like that, do we? In particular, we're continuously connected online, not only at home, but also at work. And since most of the software development problems we face are problems that other people have had before, we spend a lot of time looking for answers to them online. Google has long been one of the most useful tools of a working programmer. In recent years, Stack Overflow has become a possibly even more important one.
There's still the category of problems that you do have to solve all by yourself, because there are no answers to similar problems or they're too hard to find. Those are often just the problems that are the most interesting and rewarding to solve. But not nearly all of our problems are like that, so we might as well embrace the fact that we're part of a scenius.
What I mean by surrender is a sort of active choice not to take control. So it's an active choice to be part of the flow of something.
What you see when you watch someone surfing is, they take control momentarily, to situate themselves on a wave, and then they surrender, they're carried along by it and then they take control again, and they surrender. I think that's a very good analogy of what we do throughout our lives, actually. We're constantly moving between the control phase and the surrender phase.
The only thing is that we tend to dignify the control side of the spectrum, the repertoire of our behaviour, more than the surrender phase. We tend to dignify people who are good at control as well, we think those are the masters of the universe. And we don't particularly pay attention to people who are good at surrender, but if you think that the control part of our being is really quite recently evolved, you know, if you think of the 99,8% of human existence, until 2000 years ago, most of the time one was surrendering gracefully and trying to stay afloat, trying to use what little bit of control you had in a mostly surrendering environment. So we're good at surrendering, actually, we evolved to do it. And I think we like doing it.
If you think about what is commonly considered to be Work, most of it has to do with activity: Having meetings, typing up code, writing documents, and many other kinds of keeping busy. This, to me, relates to Eno's thoughts on control: It's the kind of activity that's perceived as being on top of things and making progress, and very much encouraged in working life.
Surrender, on the other hand, sounds like something you may do after a hard day's work. It's art, entertainment, drugs, and sex. Nothing to do with what a professional software developer should be doing while on the clock.
The thing is, we know that software development is a creative activity. And we've also learned that creative problem solving isn't necessarily best solved by keeping oneself occupied with busywork. A lot of the creative problem solving happens in the so called R-brain or "System 1", which works in an asynchronous fashion and doesn't answer to direct commands. You can't tell it to solve a problem on a schedule, and neither can your manager or your customer. Your brain may be able to come up with a solution to a hard problem on command, but it's unlikely that it will be a good one.
Andy Hunt has written about R-mode and L-mode thinking in Pragmatic Thinking and Learning. He also recommends a technique of "defocusing to focus", where you just let things marinate for a bit, in order to find the best solution to a problem.
Rich Hickey's Hammock Driven Development (AKA Step Away from The Computer) talks about the same thing: Loading up your brain with a problem, and then giving some time for your background mind to work on it. While lounging in a hammock.
When you're trying to solve a difficult problem, just surrendering to it for some time might be a good idea. Analyze the problem rigorously, and then go out and enjoy some music, or a walk, or whatever works for you. Just like the surfer, have a rhythm of control and surrender. Most organizations may need some convincing for you to be able to do that, if they're still stuck in the old "activity == work" thinking.
See also: Developing Your Creative Practice: Tips from Brian Eno at 99U.
Photos of Brian Eno's art installations by Dominic Alves, licensed under CC BY 2.0.
by: Tero Parviainen
Seamless software development.
Code management and collaboration platform with Git, Subversion, and Mercurial.