 Hello, good morning. How many people are still at bars? I wonder. I'm gonna bring something from Silicon Valley. Has anyone heard of this product? The the Juicero, I don't know how to pronounce it. I tried. This was a pretty good indication of Silicon Valley's excess. It was a it's a juicer and it is perfect. It is in fact 4.5 billion years of perfect. They had some problems here. First off, it cost a lot of money. You had this idea that you could actually just take the bag of juice that they would ship to you and you could just squeeze all the juice out, which kind of defeats the purpose. They didn't it just didn't really go too well. They ended up refunding customers money. But Ben Einstein, who's a VC in Silicon Valley, wrote this this this piece about the hardware and the reason why it ended up being so expensive is because they went all out to build this this masterpiece. Every single piece we have Injected molded parts, very specific pieces of plastic. This is unconstrained development. Very specific pieces. It had Wi-Fi. It had a QR code reader. To check to make sure that your juice might not be expired because that would just be very bad. And every single bit of it, it's machined parts. I can keep going. I have more. I have so many more things here. And ultimately, I think the problem here, there were a lot of problems. No one actually bothered, I think, to say wait, what are we doing? What problem are we trying to solve? By the way, the door was more than 25 parts, just the door, which you didn't need to open because it's a juicer. The problem is that they created an engineering problem where there wasn't any kind of engineering problem. They had this problem, perhaps, like people want juice, and instead they ended up building this monstrosity that cost a lot of money and wasn't all that useful. And I think, I hope, that at some point an engineer said, do we actually need to build exactly this thing that perfectly compresses the juice at once, when in reality you could just like take the bag and just like squeeze it out with your hands, which isn't that useful. How often in development do we sometimes have to ask a question like this? How often do sometimes we have to say, you know what? Now, I think, personally, that with this amazing thing here, that they just had fun with it, and they're like, whatever, we have money, we will build this awesome perfect machine that is just as good as my hands at squeezing juice out of a bag. But in this case, how often is it that we can perhaps just better understand one specific requirement, just one requirement, and realize, you know what, it suddenly simplifies everything else that we're building about 10 times over. This is the whole thing. I'm just going to keep, just going to leave that up there for a bit. My name is Andy Nason. I'm one of the lead developers of WordPress. For the last two years, five months, and about five and a half days, I've been on a leave of absence where I've worked at the US Digital Service in DC, not that I'm counting the days or anything like that. At least I'm counting up rather than down. And I want to talk a little bit today about how I think that you can make a bigger impact with people skills, rather than simply with code. And when we think about people skills, we think about, you know, soft, softly influencing people, showing empathy for our users, having a self-awareness, knowing good problem-solving techniques, things like that, and you know, being a good communicator, for example, very important. But I want to get to some of the other areas here as well. So I think what's really important is we need to be thinking for users, with users, not for them. We want to be able to just do the discovery and learn what we want to do, but at the same time, we need to be able to see the problem for ourselves, because too often we end up not really paying attention to what the actual problem is. So I want to tell a story. About my time in government. We had, this is a few stories here, we had this system, there were three different government agencies, and there were three different systems, one in every agency. If you've ever heard of Conway's law, it's a very classic problem here, where systems take the shape of the communication structure. So you have three agencies, of course, we're going to have three systems. In these three systems, they were about 14 years old, so about as old as WordPress, not exactly maintained. One of them, and I'll just give you some more color, the first one was written in Visual Basic. I don't mean like .NET, I mean like old-school Visual Basic. The second one was written in Java, so we'll let that one slide. And the third one was written in PL SQL, which is Oracle's procedural language written in SQL. It's about as bad as it sounds. And we had this problem where we had these three different systems that all had to communicate with each other. And we were trying to figure out how it worked, because we had a major problem, we had a major incident that we had to deal with. We had to move data from A to B to C. And we had no idea what happened with system B. We weren't actually sure if it was a system. If it was an entire room full of people just writing out spreadsheets, I wouldn't entirely have been surprised. And so we ended up looking through all of this, and we realized, okay, we have finally figured out that when an email gets sent to this group, they do something with it, and then something happens and it magically gets up into system C. So we eventually tracked down where these people worked. They were in a basement in Washington, D.C., of course. And we said, can you show us what you do? We have no idea. And they said, oh, yeah, sure. So we get these 50 emails every single day, and we download the attachment for every single one of them. And then we save them on to this server over here. And then they walk over to the server, sit down, and then they run this file. And this file was, we thought it was going to be the code. It wasn't. We had to find the binary and deal with that separately. We still didn't entirely know what it did, but it did generate. It took all of this XML, XML, yes, and then generated a fixed with text file, which is even better, which would then be individually uploaded into a system. But first, we had to get it to that system. So they would then download all these files one by one to a floppy disk, which he then said, oh, one second, and ran across the room, pulled it out of one computer, ran back, put it in another. I'm pretty sure there was only one floppy disk in this whole operation. They saved everything down onto this floppy disk. And then he walked back over to a third computer. He's still in the same room, by the way. There's a lot of computers, and I think he uses all of them, plugs it in, uploads every one of these files individually. And we looked at each other in silence, and we're like, what is this? What did we just find? And we realized that what we found was a system that was working exactly as designed. Because 13 years ago, there was a team over here writing visual basic exactly to requirements, and there was a team over here writing PL SQL executor requirements, and there's a team over here writing Java exactly to requirements. And they all built the system exactly how it was supposed to work, which also involved a human running around with a floppy disk in order to move data between them. So we were able to cut out system B entirely once we finally understood how it worked. But until we specifically physically tracked people down to learn how all of this was tied together, we really had no chance to find this. I don't think this is that controversial of a statement. I'm sure there are a number of designers here. Your job as a designer is not to make things look pretty. That's fair, yes? So why do we think that our job as a developer is to write code? Doesn't really make sense. Our job is not as a developer to write code. Our job is, it doesn't really matter. Are you going to write the best code possible? Has anyone figured out how to open these water bottles, by the way? They're kind of, there we go. You can write the absolute best code possible. This was the best visual basic code you will ever see, I think at least. But it didn't actually solve the problem. And the problem here is that developers, our job is not to write code. Our job is to solve the problem. I have another story. There is this system that was used by about half a million people every month to go in, you know, citizens of the United States, to go in and complete a specific task. I will protect the teams and not actually say what it was. And it was this old, crummy thing. Now, you can imagine in government, sometimes it's like the PDF that you have to submit and it only works in Internet Explorer 9. Like it doesn't work in 10 or 8, or for that matter, Chrome or Firefox. Didn't exist yet at the time, Firefox even, I'm pretty sure. And so we're like, OK, well, we have to rewrite this. It's not good. So we wrote, this entire thing got rewritten and pushed on to a new system. And no one used it. Half a million people, 500 people. We're like, OK, we'll wait. That I'll even out eventually. A few months later, half a million people, 550 people. Not exactly the ratio that we wanted. And I asked about this. I was like, well, why did we build this? And they said, oh, well, it was on our roadmap. OK, why aren't people using it? Oh, because they can't log into the new system. Why can't they? Oh, that isn't on our roadmap. What happened here is we didn't actually solve the problem. We wrote code because we wanted to write code. But we missed the fact where we need to be able to solve the underlying problem here. Another thing that I end up doing a lot day to day is explaining technology to non-technology people. It is not that unusual. I have a very odd job. And it is not that unusual for me to in the morning be in a meeting with developers and by lunchtime be in a meeting with the agency director explaining why this bug is going to require him to probably notify Congress of a problem. That is not good. That is what we normally call a bad bug. And this happens a lot when we're dealing with teams. We have to go to the pitch meeting. Now, some of you might work at very large firms. And there's only a few people that always go to the pitch meetings. There's always those few engineers that always get called to go to the pitch meeting. That's because they're really good at this. They're really good at explaining technology to non-technology people. At the same time, how good are you at explaining non-technology to the technology people? This great story. There was a system. I think it was in the Department of Defense, the military, and the legendary story at USDS. I guess I can tell it. And there was this funny thing where there was all of these laws and regulations specifically spelling out how it needed to work. But at the end of the day, when we looked through all of the code in the system, we found a single line that looked a little weird. And then we read the comment above it. And the comment said, well, the policy says this, but that doesn't actually make any sense. So we're just going to do that. So a developer randomly made a decision about, like, I don't know how the law is supposed to work or something like that. And just left it as a code comment, which is one of the best things you could possibly imagine. The problem, though, is that how often, for example, do we need to be able to talk to someone and say talk to your project manager or your client or whatever that might be and say, I need to spend this amount of time to build an internal API that you might not benefit from directly, but I promise you, it's really important. And then here's why. And along those same lines, how well can you negotiate the requirements? You don't want to spend X amount more time than you need to to complete the task. You want to do exactly what's necessary. Another thing that we have had some fun with in government is trying to convince them to use the cloud. So imagine this scenario. You were in a meeting with a cabinet minister using the European terms here. Trying, I'm trying. You're in a meeting with a cabinet minister, and they say, tell me why I should go to the cloud. What is your answer going to be? Is it going to be like, well, let me tell you all the cool stuff you could do with EC2? No, probably not. Is it going to be because it's going to be cheaper and faster and also you won't have any major problems? Hopefully. What if they then say, well, will it still be secure? You're going to say, yes, they're like, OK. But I can't surround the building with my guards, with people with guns. How will I be able to keep it secure? This is an actual question that we've received. You have someone else saying, well, that's great. But if there's a hack, or if I have to do an investigation, how do I put the cloud into an evidence bag? If I need to go to my data center and pull a server out and put in an evidence bag, I can do that. Imagine trying to explain technology and things like of the cloud or of the cyber or whatever else you want to put in air quotes to someone who normally testifies in front of the House of Commons or something like that. How do you actually make that work? It's really important to be able to communicate without using jargon. At the beginning of this talk, I was asked by the translators to see my slides. I said, I promise you, there's no jargon in this whole talk. It's pretty simple, because I want to be able to communicate to everyone. I also think that your interactions with others end up mattering a lot more than the code that you write. When I'm looking at a new system for the first time, I normally don't care as much how good the system is. I'm also trying to understand how good the team is behind it. And we do this in WordPress as well. In WordPress, when we're considering which external libraries to add. Anyone get the joke? No, a little bit. When we're considering what libraries to add to WordPress, we end up considering not the technology, but also all of the other pieces. How well does that team communicate with us? About five years ago, a few of us met with the creator of Backbone.js. Specifically to talk about, we want to build a new media library, the media library that's been in WordPress for about five years now. And we want to pick what at the time was the Ascendant JavaScript framework for about a week, I guess. And we were trying to figure out, should we go with this? And so we sat down with him and specifically talked out our concerns and your philosophies. And how does all of that make sense? And does this make sense to adopt? We have very good relationships with the jQuery team. jQuery is now more than half as old as JavaScript. It goes back a number of years. And it's not the sexiest or best piece of software out there. But it is something that ends up being really great for just doing things on the internet. And so it's really important that our philosophies lined up with that project. Current conversations right now about using React or using view.js. And a lot of that isn't just which one is better software, but also how many people maintain it. Do we have conversations with them? How are our interactions with those teams? That matters a lot more than really anything else. What I would also argue is that not only do your interactions with others matter more than the code you write, but also the code you write can improve your interactions with others. And so let me give you an example. You are doing code review. And you are constantly commenting about coding style. You need an extra space here. This should really be broken up into two lines. I'm not entirely sure why you didn't put this if statement here instead. Little things like that. And over time, you are expending social capital and potentially creating negative interactions with someone when you don't necessarily need to. In Go, in the language Go, they have an entire specific defined this is how Go is formatted. They have eliminated all arguments about formatting Go. Probably not true. There's some mailing list somewhere. But they've just papered over all of that. If you could imagine in your continuous integration, you're running your unit tests, or you are making sure that it is styled correctly, you can now let a computer handle those interactions rather than you. An example that I had in government is that I was back to the floppy disk story a bit. I was trying to make sure that all these agencies were basically doing their homework. And I was the big bad mean person who would send them emails each day, letting them know how far along they were and the things that we needed them to do. But at the same time, I was also offering to help. And in some cases, sitting down with their engineers or talking about their problems. And I realized they didn't like me all that much, because I would also be the person that would hold them accountable by sending them emails and saying, hi, you didn't do all the things that we needed you to do. And so I sat down with them and I said, OK, let's make a deal. I will stop bothering you. If you can agree on what metrics we need to track, and we'll take those metrics, we'll put them in a dashboard, and then you can be mad at the dashboard and not at me. Since they're working out really well, they stopped being mad at me. They started responding to me nicely now, instead of me being the big evil mean person. And then they had a single source of truth for them to work off of. This ends up being really helpful rather than arguing about, well, what is causing the problem? Well, now we have a non-human telling us specifically what those problems are. And I guess I'll end with this idea of, as many times as possible, asking more questions. I was dealing with an authentication system at a specific agency. And an engineer said, well, we really want to have system A and system B talk to each other securely. Nathan, how should we do that? And I said, oh, well, just I don't know, like 2ATLS or something else like that. Just have them talk. And I'm like, oh, OK, that works. And I was like, wait, it's not that easy. What else are you trying to do? I said, oh, well, a user logs in here, and then the data gets stored over here. And so we're just going to share a secret key back and forth. I said, oh, you're describing, depending on the specifics, like a WAF or SAML, you should use one of those. And they're like, yeah, maybe. We might not. And I was like, wait, you're inventing your own authentication system. This is not a good idea. What are you actually trying to do? And after asking enough questions, I realized that what they were trying to do is they didn't trust the developers on the team to actually write something to a WAF or SAML spec. Which point my question was, what makes you think they're going to write anything to our either? In the end, a lot of times this comes down to what kind of people skills can we really deploy. We have this hanging up at our office, asking more questions. It's actually a post-it note at the end with a question mark at the end of it. We find that it ends up being really important to ask why, to listen, and to be able to respond very deliberately. And I'll close with one final story. Floppy disks, fax machines, some kind of pattern here about old legacy government technology. In this particular case, we were asked that every day someone faxed a ton of a spreadsheet to about 40 people. And then those people would all retype all of the information. This is not very good. And we said, well, you could email it. And they said, well, it's protected information, and we can't email it unencrypted. I said, oh, you could do what every other government agency does, which is encrypt the email and send it, and then send a follow-up email with the password. And they said, no, our information security people are actually pretty smart. They require us to use a fax machine because it's secure. Not going to touch that one. And so at that point, we're like, OK, that's fine. What are you actually trying to do? They said, well, we're trying to eliminate the fax machine. I'm like, are you? You're trying to eliminate the idea of typing up all the information again, right? You're not trying to eliminate the fax. Are you recommending that we do optical character recognition? I said, no. Your purpose isn't to stop faxing. Your purpose is to stop typing. What if you send the encrypted email and then fax them the password? So this is exactly how the system still works two years later. Thank you very much. Thank you so much, Nathan, for sharing your viral experiences with us. That was really, really interesting. Do you want to have a Q&A? Does anyone have any questions? I think we will find the time for that. Fortunately, you will all need to walk up to the mics, because everyone's up here. There are two standing microphones here in the front rows and also in the upper rows. So we would love you to ask some questions to our speaker. Oh, there's somebody coming. It's behind you. Great. Hey, Nathan, thank you very much for the talk. It was really interesting to see how you dealt with the bureaucracy, particularly layers upon layers that have existed for a long time before even the invention of the computer. How is it that you've managed to turn around middle management, budget, accountants and stuff who have got, they're not even beyond not understanding, they don't even use the majority of the applications that we end up developing for them. So how have you managed to get around talking to those guys? I think what's really interesting is a lot of these people have invented their own systems, especially if they're on the front lines. I worked in immigration policy and a lot of the processes there in the United States for about two years. And it was amazing to see how many Excel spreadsheets and access databases and everything else were used to tie all of this together outside of all the other systems that existed. What we realized is, as long as we could end up making something for them that's going to ultimately be better, we know how long something should take in isolation. But in reality, they're very good at it. They spend all day flipping through paper, for example, to the point where they use the little rubber thimbles to flip through paper really quickly. And they're better at that than we are. So then scrolling through a PDF takes an hour, but then flipping through the same amount of paper in minutes to read everything. And so trying to optimize those kinds of things ends up being really hard. In many ways, what we end up doing, at least to solve these problems in addition to trying to do as much research as possible so we can really come up with a good solution that actually does work and doesn't make their lives worse, but makes it easier, is really just trying to befriend them and work with them. USDS is really interesting because we don't have a huge culture to speak of by ourselves because we often end up grafting ourselves on to other agencies' cultures. So I did five years of remote work and then went into government where I literally would go find that middle manager and sit at their desk and talk with them and then go somewhere else and talk with them, currying favor. I think a lot of my time dealing with contributors online and comment threads on WP Tavern and everything else made me pretty good at talking to people and trying to understand their problems and then trying to work through that. But it's definitely a huge challenge for us every single day. Hello, Michael from France. You present your experience with the state agency. What is your feedback with WordPress? I'm sorry. I don't fully understand the question. You present your feedback from a state agency, but yet what is your return from WordPress development as lead? Well, there are a lot of people who work to lead WordPress right now, which is really great. A lot of them are here. Some of them are not. I honestly couldn't fully understand your question, unfortunately. I don't know if anyone else has. If you want, maybe you can ask in French or I can in French and I'll try to translate. Excuse me. You have shared your experience with the state agencies. What is your return, your experience within WordPress? Yeah. Anyone else want to help? Is there anybody else who can help? Can I read the translation? Does that help? Oh, OK. You can help, maybe. So I will give you my microphone. Yes, I think the question is, inside of the WordPress space, do you have similar experiences or other differences in your experience? How do you relate to the problem? I think what's most interesting about WordPress is that it is not a perfect piece of software and that that is OK and that that is a good thing. I would rather have an imperfect piece of software that actually helps people than a perfect piece of software that no one uses. Is it OK for you? Andrea? Hi. I agree with all of that. And I'm also curious, have you ever seen a juicera moment in the WordPress project or a juicera moment that we narrowly avoided? I have a lot of stories of us narrowly avoiding that moment. In WordPress 3.1, we were developing what is now called internal linking in WordPress, where when you inserted a link, it let you link to your existing content. And the original designs for this were the worst that you would ever see in open source. If you ever used Addium, especially back in the day, the old chat app, you know how the preference pane had preferences? And then it had an advanced tab inside of that. That's kind of what we ended up developing. It was this weird, it had all sorts of different stuff in it. And the way that we saved ourselves from that is that we did a lot of iteration and we did a lot of usability testing. And I remember working with Jen Milo a lot on that, in particular, and Daryl Kruber Smith, to try and really simplify as much of the UI as possible and smooth a lot of that out. I think that WordPress Core has mostly avoided a lot of those really painful moments. We've gone through them, but we've never actually, we've usually not chipped it. I think the WordPress community struggles a bit more with this, where you look at, for example, most of the security and caching plugins just like have so many things baked onto them that don't really make a lot of sense. And that ends up being kind of painful in many ways. I definitely like vividly remember, I have screenshots of this original interface that I really should show off in a blog post or something when I start writing blog posts again. I want you to know, I have like 100 drafts ready to go. The day I leave government, they're just gonna start going out, it's gonna be great. I have way more stories than just these, that's for sure, just I can't share these, so. We have one last question over here, please. Listen, hello, Luis from Spain. The big problem. How can you find out what the clients really need from what they say they think they need? If I knew how to answer that succinctly, I would have written a book a long time ago. A lot of it comes down, I mean, this is hard because a lot of clients that we deal with are people that are trying to just get the word out and it's more about marketing and it's less about they themselves have users. So that ends up being really difficult, but as much as possible, especially when we're building rich applications, trying to understand what their users really want is really helpful. What I like to do is rather than trying to go around the behind a client or government agency or something like that, instead build that into the original relationship, it's really helpful when someone comes to you and says, we wanna do this thing, but we don't really know what our users want either. And then you can hopefully begin that relationship with great, we're going to do some user research and we're going to try to come back with a proposal for what you might wanna do. And all too often a lot of contracts are based on just purely development and not based on any kind of product sense or any kind of experience in terms of what the user really needs. And that's usually where things go sideways very quickly. Thank you so much. I think that's it. And we were talking before Nathan came on stage. So he would like to go to the expert bar and so maybe if there are some more questions, you can find him over there and chat with him in person. So thank you so much for having been here on stage and please give a big applause again to Nathan. Thank you. Thank you.