 Good morning. Merci de m'avoir invité. Here I am. There I am. I have a purple line, but we're okay with that. There we go. If you have been around WordPress for a while, or if you have looked at the lanyards that are holding your name badges, then you've seen this slogan, emblazoned. It says code is poetry. As Carole said in my introduction, it's always kind of irked me a little bit, so I wanted to take some time today to look into what it is that we really mean when we say this. Do we mean it as a metaphor? Do we mean it literally? What does it do for us? And to talk about maybe some alternative ways of thinking about the work that we do that captures some of the spirit of this without maybe capturing the bad stuff. But first, let's talk about the good stuff. When you look at a piece of poetry next to a beautiful piece of code like this one, it's just something, it's like looking at pictures of two distant relatives, and you know that they're kind of related, and maybe it's the nose, or maybe it's the big ears or something, but there's something about them that seemed very similar. Both code and poetry share the properties of being non-conversational. They depart from the conventions of regular speech. This is part of the power and part of the distinctiveness of both code and poetry. They're both syntactically complex in the sense that they depart from the regular rules of putting words together, but they often introduce new conventions, new rules for the ways that you can put words and symbols and characters and punctuation in certain places in order to form new kinds of meaning. Code and poetry both share a certain density of meaning. They both have, they manage to pack a lot of stuff in a relatively small amount of space. Like when I'm up here talking, as you're reading the transcript, it's blah, blah, blah, blah, blah, but you know, if I have a bit of code I can express all of that quite elegantly. Code and poetry, or code and poetry, both have a sense of rhythm. They have a sense of symmetry. They have the same sorts of patterns. We have line breaks. We have indentation. And they both have the qualities of elegance and concision. You know, a good piece of code or a good piece of poetry expresses what it needs to do without wasting any space or without wasting any CPU cycles. I like to sum all of this up by saying that they share a common texture. These are sort of surface qualities of code and poetry that make them feel, these are like the big ears and the nose that when you're looking at the two pictures they feel like, well, it's these surface texture qualities that make code and poetry feel alike. So when we say code is poetry and we use it as sort of a mantra for ourselves, this is part of what we're evoking. But what I think is really going on at a deeper level is not just saying that, well, code is kind of like poetry, but it's more about us as coders and how we see ourselves. It's more about the people who wear things like this. Software developers have sort of a perpetual crisis of identity. The work that we do is relatively new. It's a really good tradition of work in which to situate ourselves. We'd like to think of ourselves as sort of rugged individualists. We are able to forge into a great wilderness of the blank screen and we forge something beautiful, some beautiful jewel where previously there was absolutely nothing. This is a very romantic idea of what it means to be a software developer, but I think it drives a lot of the pride and the dignity that we take in the work that we do. We're not just cogs in some machine, but we are somehow creative and romantic individuals. But this is a little bit at odds with the daily realities, the stuff that we actually have to shovel when we do our daily work. You know, 90% of my time is spent fixing bugs that came up because I didn't have sufficient test coverage or arguing with clients about scope creep or sacrificing my grand and beautiful architectural visions for the sake of meeting a deadline. Now these things don't feel like the sort of cowboy riding his horse through the mountain pass, rugged, beautiful individualism that we like to think of ourselves as embodying when we do our software development work. And I think that when we say that code is poetry, it's kind of a coping mechanism for this torn identity. It's a way of saying that, yes, my daily job involves a lot of suffering. I do suffer, but like the artist, I suffer for the purpose of my art. I'm able to give it some sort of higher purpose. In this sense, when I say code is poetry, it's not so much a description of the work that I do, but it's an affirmation for the way that I want to think about the work that I do and a way that I want to think about myself as somebody who's chosen software development as a worthwhile and dignified career. But the problem is that code is not poetry. It's code. It's something else. It's simply not true. There's something fundamental about the way that poetry and the artistic process works and in particular the way that the artist communicates with the audience for his or her art that really doesn't match up with the way that software developers work at all. And I think it's important to explore this. When you see an object like this, you may have certain sort of visceral reactions to it. You may think that it's beautiful or not beautiful. You may think that it, well, it's not a very good picture. It's not very proportionate. But once you want to start having an artistic judgment about it, you have to enter into a different kind of relationship with this object than just simply looking at it as if it were just an object of pure beauty. You have to ask yourself, who created this object? Well, this was Picasso in 1921. But in order to understand this as an artistic object, you have to know that Picasso was a Spaniard working in France. You have to understand that synthetic cubism was a reaction to various arts movements of the time and art movements that came before. You have to understand that Picasso knew that when he painted this, he was painting for an audience of critics and other artists and museum-goers who were going to have a sense of history about where cubism fits alongside other movements of the early 20th century. Now, maybe some of us don't have a complete understanding of this at all, or maybe some of us have a very misleading understanding of it. But the point is that in order to think about this as a piece of art instead of just a pretty object, we have to engage with this sort of relationship, consciously or unconsciously, with the artist as sort of an author who's doing something to us. This becomes even more obvious when we think about some art that comes later on in the 20th century and is really purely conceptual. If I see a picture of a can of soup on a poster when I walk down the streets of Paris, I may feel certain emotions. I may feel hunger. But if I see the exact same image, pixel for pixel or paintbrush for paintbrush, the exact same image on Andy Warhol painting, I have a very different reaction. And the reaction, you know, it may be a number of things. I may say, oh, the banality of commercial life, or I may say the banality of Andy Warhol. But I have a very different reaction from the exact same visual image. So something is happening here, and what happens is that I understand when I look at this image in the context of being a piece of art that Andy Warhol created this trying to do something to me, trying to make me feel something, trying to make me think about something. Whether he succeeds or doesn't succeed is another question entirely. But my experience as the audience for this piece of art is fundamentally guided by the fact that I am aware of the author and I'm aware of the author's intentions. So here's something we're maybe more comfortable with. Contrast this with software. WordPress has many millions of users, a large percentage of whom don't really know what WordPress is. And even a larger percentage of them don't know and don't care who created WordPress. And they don't care what the creators of WordPress were trying to convey when they created WordPress. It's simply not relevance to the experience of using WordPress. In fact, when we build software, we often say that we like to have it get out of the way. Software is successful when it is transparent to the user. This is the opposite of the artistic experience. The artistic experience is grounded in the knowledge on behalf of the audience that the author intended something. But in software, we actually want to hide. The author should disappear. And if it becomes a totally seamless experience for the user, where they can just write or where they can do their work or have their fun without thinking about the software and its authors, that means we've done a good job. So from a social point of view, this is a completely different sense of what code is than poetry. So that's the end of my argument. Now, it sounds a little bit crotchety. And you may be saying, okay, that's very nice. That's a lot of very fancy concepts that you've introduced. What's the points? Code as poetry is a nice little slogan. It makes us feel good about the work that we do. Maybe it's not true. But maybe truth isn't the important thing here. And I'm not just an old man yelling at a cloud. What I want to argue here is that there are some facts about code as poetry that actually lead to bad results and adhering too closely to the idea of code as poetry and coders as artists can lead us to some bad results in software. Let's talk about just a couple of these ideas. And this is not meant to be exclusive, it should give you a sense of some of the features of poetry and art that do not translate to good software, one of which is metaphor. You know, this is the idea that we say one thing, one word, and we mean something else. When the poet says, he's not talking about roses, right? It's not an actual rose that you're picking. There's something else. And it's this experience of taking one word and moving through it to get to another meaning. That's much of the power of poetry. It's much of the emotional power. We don't do this in software. Have you ever tried to debug something that came down to a variable, variable name? Metaphor is not something that we enjoy using in software development. Vaganness is another example. Sometimes you read a piece of poetry and the poetry can have more than one signification at a time. It can have more than one meaning. It can be three or four meanings and you're not sure when you read the words which path you should go down. Now, this experience of feeling the uncertainty of exposition is part of the aesthetic experience of reading a piece of poetry or viewing a piece of art. This is not something that we like when we read code. When you read code, you want to be able to understand it. We look for clarity rather than some sort of artistic vagueness. Inscrutability. Difficulty to read. Sometimes poetry is hard to read. Sometimes it's exhausting to read. But that feeling of exhaustion of struggling and wrestling with a piece of poetry or with a piece of art in order to get meaning out of it is often a part of the aesthetic experience of engaging with the art. But our code is exactly the opposite of this. If you have to struggle in order to understand my code, that indicates a failure on my part as a software developer. Novelty. Software developers, well, artists are often a success when you see them create something totally new. If I read something in a poem, if I read a metaphor or a simile or a word that I've never seen before, that's part of an aesthetic experience that brings value to the poem. When I see something new in a piece of code, that's not a benefit, that's a cost. If I introduce a new API, a new naming convention, a new architectural construct, these things have costs and we only introduce them if the benefits of that novelty outweigh the costs. It's not a benefit in itself to introduce new kinds of things. But these are all sort of the surface texture issues that I talked about before. The real issue here is that when we think of ourselves as some sort of grand artists, when we think of ourselves as engaging in an endeavor that ought to be judged by the standards of artistic excellence, we do things that don't really match very well with what we ought to be doing as software developers. Just to take a few examples, artists are necessarily, in order to be successful, individualistic. They develop their own personal styles. They try to make themselves stand out from their peers and to the extent that they do so, they count as successful artists. But we try to do exactly the opposite. Artistic license is not a virtue in the world of software development, and we have tools like coding standards and shared architectural patterns and shared naming conventions and things like that that enforce the ideas of conformity. This is not a bad kind of conformity. It's one that saves time and that makes our lives easier. But it's in a grand contrast to the sort of artistic individualism that we value in poets. Closely related to this is the idea of ego. It's difficult to say about an artist that the artist has done something wrong or that the idea of the artist is somehow incorrect or inappropriate. And this has the effect of allowing artists to sort of set their ego at the center of their work so that the value of the work that they do, in part, comes from their value as people. And this may or may not be a good thing in art, but it certainly is not a good thing in software development. I mean, think about something like code review. If you are so attached to your idea of what code ought to look like or feel like or how it ought to work, if you think that your ideas are somehow so valuable and so perfectly formed the moment that they come from your mouth or from your precious fingertips, that you are unable to be criticized on those without taking some sort of mortal offense, this is obviously not a good way to collaborate on software. It's not the way that we want to build software, especially not in a community atmosphere. So it requires a certain amount of humility. A good software developer needs to be humble in the same way that a good artist is allowed to let his ego shine forth. Isolation and collaboration. There's a kind of myth or mythos about artists like Monet and Giverny, kind of cloistering themselves off into a place where they're all by themselves surrounded by beauty and by nature and they're able to produce great art. When they come out, when they step out of their cocoon, here you have something beautiful. So there's a similar mythos about software developers that they hide away in their rooms with a gallon of soda and headphones on and they crouch over their keyboards for a few nights and they come out with a beautifully formatted piece of code. Well, this isn't really how we build software. It is true that generally only one person is typing on a keyboard at a time. So there is a sense in which isolation is an important part of the development process. But where software is really built is in communities. Whether that's an open source community like WordPress where we iterate and improve on each other's patches, or whether this is in your internal teams, or even if it's just you working on something for a client who will then give you feedback and you work in a collaborative environment with your users. So not only is code not poetry, but believing in this phrase too much, hanging too strongly to this notion of code as poetry, could push us in the direction of embracing development techniques and embracing a way of existing with our peers that is not healthy to the way that we ought to be developing software. But remember, this was supposed to be an affirmation. There was something good about code as poetry. It gave us a way to conceptualize the dignity and the pride that we want to feel, and that we should feel in the work that we do. So I want to find a way to capture that idea without relying so heavily on a metaphor that I think is problematic. So the first part of this I want to look at is meaningfulness. One of the nice things about art is that you say, oh, I'm an artist, and everyone is like, I'm an artist. Because the idea of being an artist is so sort of imbued with importance. But there's a lot of meaning in the world. We like to call ourselves engineers, which I think is a little annoying sometimes, but one thing I really like about the word engineer is that it denotes a clear lineage, a clear connection with people who build houses and bridges and tunnels and airplanes, and things that actually matter, right? Some things that matter too. We build things that are used by other people. They're real physical objects in the world, even if they're instantiated in ones and zeros and magnetic bits on a drive. They're real objects, and they have a real effect on real people, and this is where the meaning of these objects comes from. So you don't have to say that you're producing some great work of art in order to say that it's somehow meaningful or important. The importance of the software that we write is even more manifest, even more concrete than that. It comes from its use. Code is beautiful. Well, this is another thing that is really clear when people say that code is poetry. They mean, oh, isn't this nice? And certainly it is the case that we try to build beautiful software, and we try to write beautiful code. Sometimes we don't succeed, sometimes I don't succeed, but we try, and we want to find a way to capture this. Poetry is one way to do this, but there is beauty everywhere, and most beauty in the world has nothing to do with art. We see in nature symmetry and patterns and contrasts and proportion, the same features that we can see and identify in our own code and identify that as a real and valuable form of beauty. An even better way to think about beauty in software design is to think about our friends, the designers, because the designers are able to think about this in a way that we are not. When we come to the table more conceptually prepared, they know that the beauty of an object does not simply lie in its sort of sex appeal, it's not about the prettiness, but the beauty of an object lies fundamentally of a designed object, is in its how well it suits the purpose for which it is designed. So the Eames chair, very famous design, it has pretty lines, but that's not what makes it a beautiful design. What's beautiful is that it accomplishes its goal of being a chair in a simple way, in a durable way, in a way that's comfortable, and it's this kind of appropriateness for its purpose and the elegance of suiting a purpose in a concise way. This is a kind of beauty that designers recognize and that we should embrace as well as a legitimate and really wonderful kind of beauty that we can aim for in the code that we write. When I think about code as poetry and when I think about something that, another way of thinking about code that captures some of the ideas, the word that I keep coming back to is craft. I mean something specific by craft here, the skillful creation of useful objects and the word useful here is critical because art can have an effect on the world, but almost by definition, artistic objects are not meant to be immediately useful. The painting on your wall may bring you joy, but you don't use it as a doorstop. Designed objects, crafted objects, are meant to be used in the world, and what I like about this notion of craft and thinking about ourselves as craftspeople, rather than as some sort of artist, is that it gives us a clear connection with others in our community and the way that craftspeople are embedded in the society at large. Like I said earlier, the idea of software development is something brand new, and we have to find a way to fit ourselves in and think about the way that we fit in around the people around us, but we already have a sense of how people who build homes and ships and people who build bridges, we have a sense of how these people fit into our society and thinking of ourselves as craftspeople allows us to be contiguous with this idea of craft. There's a couple of specific aspects of this that I think are really worth highlighting before I wrap things up. Craft and thinking about our work as craft, instead of thinking about it as some lofty artistic endeavor, helps to bring us closer to a more grounded sense of class. There's this weird and really scary tendency in the software development community for people with technical skills to think of themselves as being somehow better than mere mortals. Think about the stereotypical tech CEO who, because they have achieved some sort of technical success or some sort of business success, that they therefore can remake society in their own image. This is called disruption, by the way. Why do we think that this is okay? Well, when we think about ourselves as craftspeople, instead of thinking of ourselves as some sort of artists or some sort of conceptual workers, we're craftspeople. We're building real things. This connects us much more closely to the general class of individuals. We, too, are we mortals. If you prick us, do we not bleed? Craft is inherently collaborative in a way that... in a way that art is... it's a little bit harder to say this about art. There's a long history and tradition in the world of craftsmanship for working together because there are some objects that are simply too big or too complicated, a house or a ship or a computer or a content management system. They're too complex for one person to build on their own. They require collaboration. It's part of the process of craft and part of the tradition of craft for people to work together. By thinking of our work as craft, it puts collaboration as in front. It makes it the first strategy rather than something that we resort to only when the other strategies of individuality have failed. And finally, craft... and the idea that what we do is constitutes craft situates us in the broader world in a way that I feel is healthy for the way that we view our work. So go back to Bridges. A bridge may or may not be beautiful, but what counts as success in a bridge is that you keep people dry. If the bridge crumbles, you've failed. That's objectively true. If the bridge does not crumble, it's objectively true that you have succeeded. It has an effect in the real world, and the criteria for success are non-negotiable. We, too, are building things that make a difference in the world. When we talk about client work, your client has needs. They have goals. They may have business goals. Maybe it's a nonprofit. They have educational goals. Your software helps them meet those goals. Your software is not an end in itself. When we talk about WordPress, WordPress has the mantra of democratizing publishing, which is probably something I could give another talk about. But what I really like about that is that it emphasizes that WordPress itself is not the point. The point is giving a tool to other people so that they can do the things that they need to do out there. Remembering that what we do is craft reminds us that what we do really matters in this way, and it reminds us that we have a responsibility to keep the real-life consequences of our work in mind as we do it. This is another way of bringing a sort of dignity and sense of responsibility and pride to the work that we do without relying on a metaphor that I think is less than ideal. Thank you very much. Thank you so much, Brun. Very, very interesting talk. Are you feeling better now? You're not a curmudgeon anymore? I'm a curmudgeon, yeah. I haven't experienced you in that way. I'm incorrigible. Good, good. I'm quite sure there are some questions for you here in the audience. I think you already know the procedure. There are standing microphones here in the front rows. I'm feeling like a stewardess. It's like... Also in the upper rows, there are two standing microphones, and we would love to have some questions here for Brun if there are. The argument that I presented was so sort of cohesive and concise that I could see how there would be no room for argumentation. You have been so clear. That wasn't meant to be a joke. So my question was if you were better now and if you're not a curmudgeon anymore. I don't have another one. I will give you a good answer. So code is poetry, just autobiographically, has always annoyed me a little bit, and the process of preparing this forced me to think about a more productive way to engage with the work that I do so that I can feel good not only about the things that I produce, but feel good about the process of producing them. For me, it's been healthy. I'm less of a curmudgeon. Please, go on. I really love the argument. I can totally connect with it, and I love the shows of the word craft. However, it seems that somebody is there before us as a company that uses this as their motto for developers. Then there's also a sense of having a motto that unites the community. When it connects with another brand, it may be problematic. That's a great point. That was not necessarily promoting this as the new thing that we print on lanyards. I think that code is poetry. Look, it's nice. People know what this means. I think the point is that it's a metaphor. You take away from the metaphor what you need to take away from it, but if you start adhering to it and seeing it as a guiding principle for the work that you do, it can lead you down paths that may go against the goals that you're trying to accomplish. That's my main point, but I take your point very well. I'm not a marketer, so this was not intended to be the development of a new slogan for WordPress. Hello. First, I want to say it's great to see your talk in person. I have this opportunity, and I kind of had not a question, a bit of my playful suggestions. If right here on the spot, we're changing the slogan for WordPress development. Let's make a new slogan right here right now what you would say the slogan for WordPress development should be. Oh, my God. You want this to be serious or a joke? I'm okay with the joke. Other people might not be. How about We Shall Survive? Thank you. Love it. Thank you. So, okay. I think we're done then. Oh, there's somebody up there. It's the second time I did not see you. I'm so sorry. I'm beginning to wonder if I'm here really. You are real. This is a question that arises from us. Okay, so how do you think there's a thing to be say about repetition when you're start to do the same kind of thing again and again and again. You're looking for short codes or better ways to do this and these turns into developing your own tools and I have heard other developers in other projects related to PHP saying that this is a good practice set of tools. Thinking of as a developer or an engineer as a craftsman I believe that this is the right way to look at things. What will you say about we motivating ourselves to create our own tools to prevent us from repetition and open sourcing that or what will you recommend in the aspect of searching for tools for people that may have the same problems as us. Thank you for the very thoughtful question. I will start with an anecdote that seems unrelated. I was reading an article in the process of preparing this talk about the JAV saxophone player Sonny Rollins who is now 85 and part of this profile documented how he was legendary in the JAVs community for his practice regimen. So while most virtuosos they obviously practice a lot when they're very young but then they get to a certain sort of virtuosic skill and they're able to coast on that. They play gigs but maybe they're not running scales but Sonny Rollins practice for 10 hours a day every day a week into and through his 40s and the way that he described it, he didn't use the word craft to describe this but what I take from this is that for somebody like Sonny Rollins and I'm sure many many artists like him that you can take the work that you do and artistic work and divide it into its two constituent parts. One is the creative part and that is or at least can transcend to the level of art is craft. So inside of art there always is craft and the process of honing one's craft is really critical to the process of being able to attain excellence, whether that's artistic excellence or otherwise. So to bring this around to your question I think what you're getting at is that I suggested that individuality and the idea of creating your own tools is maybe it can be counterproductive but what I'm suggesting is that these sorts of exercises of let's say building your own version of a virtual DOM renderer like React when React already exists this can be an exercise a little bit like running those scales that is a way of honing your craft so that when it comes time to actually perform the tasks that you need to perform, client work or working on an open source project or whatever the case may be, that you've actually taken those technical skills to such a level that you'll have the kind of virtuosity that you need to perform your end goals. So I'm not against people exercising artistic or individual sort of freedom in terms of the way that they develop their own tools or whether they use existing tools to save time but I think as long as it's done with a spirit of self-improvement and bettering one's own skills instead of reinventing the wheel then I think it's a very healthy thing to do. Thank you. We have a last question from over here. Yes. Thank you very interesting talk. I can just briefly say that before I began working as a software developer I was a musician for 10 years and I can say that's also an industry that's very much plagued by the idea of the artist. It doesn't really help anyone I think. But I do have a question which is also another comparison which is often used for developers which I really hate and that's the idea of the ninja I fucking hate. You all know what ninjas are, right? They're assassins, right? No, and they're also like wicked people. I don't know, do you have any feelings about this? Well, I think the idea is that the way that I always imagined it somebody, is it Wu or something that has like a little ninja who's very stealthy and I think he sneaks in and he gets your bugs I think that's the idea, right? That's how I always imagined it. But I agree it's a little, it's cute. Again, it's like code as poetry. There's nothing particularly wrong with it until you start actually unpacking the metaphor and trying to use those as guiding principles. I don't know that I have anything really profound to say about it that wouldn't be offensive to some people in the room but I agree with you that it's highly imperfect. Yeah. Thank you so much. It was a pleasure to have you here on stage. Thank you. Thank you.