 Excuse me. Thanks for coming out. You people didn't want to ask these questions, no? Alright, I appreciate it. This is a hard time slot. So, my name is David Moore. I'm a Drupal developer at NPR. What are we going to talk about today? As I just said, I'm a developer. I'm going to tell you again, you will definitely get the point by the end of this hour that I am a developer. And this is going to come from a developer's point of view. I'm not a product owner, a scrum master, an ops guy. And so, just you've been warned. And keep that in mind as I'm talking. That's the lens through which I look at these problems. I'm going to be talking about my experience with Core Publisher. And I'll talk a little bit more about what that is. I was on the Core Publisher project for three and a half years. I'm on a new project now as of January, which still involves Drupal, I'm happy to say. But I learned a lot of things over those three and a half years and I've tried to distill them down into an hour's talk and hopefully you can get something out of it. Now, this is more of an abstract sort of general talk about building a Drupal team, building a big Drupal project, things like that. I'm not sort of a nuts and bolts what's under the hood of Core Publisher. If you're interested in that, it's still very interesting, but it is very specific. If you need to know how to build a public media specific platform starting on Drupal 7 Alpha, there is a talk out there and I've given it before and you can email me and I can send you a link. But I thought I'd do something a little more general and hopefully it'd be a little more useful. Not too abstract, but not too detailed. This might seem like a strange thing. I'm assuming everyone here has heard of knows of NPR, yes? All right. There is some nuance here though that often gets overlooked. We are not, just so you know, we're not a government entity. We're not a government radio station. We don't have really anything directly to do with radio stations. What we do is we produce content and your local independent public radio station purchases that content and then plays it over the airwaves. You can also get the content obviously through NPR.org, any regular users of NPR.org out here. So we are obviously to produce this content, we need to be a big news organization. But I'm just bringing this up because I get a lot of, there's some ambiguity there and it's often times intentional because the NPR brand is so powerful. It behooves a local station to say, this is your NPR station. And what that really means is we purchase an awful lot of content from NPR and you hear NPR content an awful lot on us. You hear that especially during pledge time. Anyway, that's who NPR is. What's core publisher? These are, like I said, we provide content to public radio stations but we also provide services. Digital services, that's the name of the division I work for. We're based in Boston, not D.C. where the rest of, most of the rest of NPR is located. Started in 2010, it is a turnkey solution. So most public radio stations, as you can imagine as I just alluded to, have to beg for money. They do not have huge tech staffs on hand. Some of the bigger ones do BUR and WNYC, KQED. But for a mid-market or small market radio station, they just don't have the means to do a lot of digital outreach. And so we provide that with core publisher. It was built on a Drupal 7 Alpha. If anyone went to Schnitzel's talk yesterday, Amazee Labs re-launched their website on Drupal 8 Alpha. And he used the word crazy and insane multiple times. And I'm not going to disagree with him. Do not try to build a big project on Drupal 7 Alpha. I learned a ton about core and all sorts of stuff in Drupal 7, but it was a very rocky ride. In fact, it was on, when we launched, we started building on an Alpha. We launched live on a beta fall of 2010. And I think there was about six pilot sites when it actually went to 7.0. So don't try this at home. There's now pushing, I think that's a little high on the estimate, but pushing 150 different stations using it to one big multi-site. It obviously has a lot of bells and whistles for public media, particularly radio, but some TV. And the biggest thing is integration with the NPR API. As I mentioned prior, NPR is a very large news organization that creates an awful lot of content. Some of it you hear on the radio, some of it you see on NPR.org. And we also have an API that draws that content out and places it in your local public radio website. So a very small station can have a very good-looking website that every morning automatically pulls good, fresh, original NPR content onto their home page. And that's, as you can imagine, that's a real attraction. So four easy steps if you're about to build a big Drupal project. Piece of cake. Build a strong team. This seems pretty obvious, right? If you don't have a good team, you're going nowhere. And we're going to talk a lot about building that, hiring and building a good team. Everyone needs to be on the same page. That is crucial. Notice it says keep developers happy and motivated. I'm going to include front-end guys as developers and maybe designers too if I'm in a good mood. But that's the core of your team. If your core of your team is not happy and motivated, things are going to fizzle out. You're not going to get that great product out. And if you get the first three bullet points, the fourth should follow relatively stress-free, right? So as I said, first and foremost, you don't have a team. You want a team. Jeff Bezos, who I think is probably, you might probably have opinions about him, but he seems like a pretty smart guy. I probably wrenched this rule completely out of context, but I like it. The two pizza rule. How big should your team be? Can you feed them with two pizzas? I know things are bigger in Texas, but up in Boston, a large pie is like, yay. Eight sort of medium-sized slices, two large pizzas, 16 medium-sized slices. It's about six people. Similarly, when we're talking about keeping things consistent at NPR and the core publisher team, we went through a lot of different phases. Small team and medium-sized team, two pretty big teams. One enormous team. And now they're back to one sort of tight two pizza team. And that seems to be what's working best. Keeping things consistent, it's important to have the same people working on the same code base for as long as possible, getting to know each other, getting to know how each other works. The more cohesive unit you have, the more productive things are going to be. Be patient when hiring. They talk about fail fast in the startup world. Don't do that with hiring. Take the time. I'm sure if you're looking to hire or looking for a job, especially here at DrupalCon, you've heard people saying, everyone's hiring and there's no good Drupal developers. And there's more than a little bit of truth to that, but still you got to be patient. If you make a bad hire, especially a bad key hire and don't realize it until six months in, your project is going to falter. And you got to start with a hub. Now what on earth is a hub? Hub is your lead developer. Is the man or woman who stirs the drink on that project. They need to be good and they need to be experienced at Drupal. And I think those are two different things, okay? They need to have been in the Drupal world for a while and understood the community and the idioms. And they also need to code well. More than that, they need to be a leader. They need to be someone who's respected by the other people on the team, people look up to who knows how to lead. You can find a very good Drupal developer out there who is just a little too introverted, a little too thin skinned. It's not going to work. You need to vet the hub. You need to find out if this hub, this man or woman is everything they say they are. Now sort of a catch 22 if you don't have a hub already, how do you know this person is that good? Do whatever it takes. You know, hire Aquia to pour through their code. Hire some consultant that you trust to go in and say thumbs up or thumbs down on this guy. Again, be patient. It makes all the difference in the world if you start with a great lead developer. And give that developer real authority. Don't just thrown to the junior developers and say, this guy's good. Do what he says. Allow him to actually veto things. Give him the ability to say, that commits no good. Roll it back. Or don't merge that branch. It's not ready. Things like that. You've got a hub. You need some spokes. And spokes are the junior and mid-level developers that complement the lead developer and the designers and the front-end guys. I thought about all the adjectives used to describe developers that I like and respect and think are very good at their job. And I kept on coming to these two points. They're passionate. They're enthusiastic. They love coding. They code in their spare time. And they're also very careful and cautious and thoughtful. They're fastidious. There's lots of good coders out there that are too sloppy. And there's lots of very careful coders out there that are a little overly cautious and sort of get paralyzed and move very slowly and don't write that code that well. So you need both. You need a breadth of skills these days. Front-end, they need to, at least some experience with the front-end, they need to be able to be knowledgeable about markup and CSS, jQuery and JavaScript. They don't need to know all the ins and outs of CSS3, but they need to be familiar with it at least. Some DevOps, the line, and I'll talk a little bit more about this in infrastructure. The line between operations and code, especially in Drupal, gets blurrier and blurrier. And the more they can help out with deployment scripts and moving things around, the better. They should be able to write a little bit of bash. And not Drupal. The phrase that Larry Garfield Crell coined a couple of years ago, get off the island, which you might have heard this week, that's even more important. It's good to see Drupal 8 seriously getting off the island with all the symphony and other things in it. If they only know Drupal, I think that's a little bit of a red flag. They got to know any signs of playing with other frameworks, other languages is always a good thing. And what do they do from 6 to 8? I just alluded to this, but do they have hobby sites? Do they have stuff on GitHub that's totally unrelated to Drupal? The last point is sort of obvious. Start with just pouring over what code they have available. The incredible advantage of hiring an open-source developer is everything is or should be public. And so you can go over, you can look at so much of their code and really get a good grasp. It's a good way to weed out things. Other ways to weed out people, you know, I get questions all the time like, what's a killer interview question? What's a really specific like, if I'm using the Form API on a multi-step form and what should this pound, whatever be, that's ridiculous. No one knows that stuff off the top of their head. Everyone Googles that. It doesn't matter who you are. It's much better in my mind to ask more generalized questions. You're going to know much more about the person. If you ask, these are what? One, two, three, four, five crucial things that just sort of ask. Not even a question like, tell me what you think about technical tech. You know, tell me how do you do version control? And if you get any kind of faltering around these, that might be a red flag. I mean, no developer likes writing tests, but if they say, I don't write tests because my code's great and it doesn't need to be tested, or I don't write tests, I do it all manually, that's a red flag. Version control, this is, I've actually heard this. Someone said, I don't do version control because I don't work with other people, or I don't do version control because if you write it right the first time, you don't need version control. Like, these are serious red flags. So these are just great ways to very easily just weed out people. I'm going to talk a little more about interviews, which might seem a little weird and obvious, but I think most tech shops and most companies, they're doing interviews wrong. I'm going to explain. The bad interview is also the typical interview, right? You sit in a room, you're bombarded with questions. They're either overly specific or overly broad. There's very little give and take. It's an interrogation. It's 45 minutes by a developer who isn't really a stakeholder, doesn't have a whole lot of skin in the game, and just wants to go to lunch. That is a bad interview, and like I said, that is the typical interview I think these days. It's unfortunate. Here, my radical solution is this is what I think is the great interview for a developer. And I've done this once before. I've been on this interview before, and it was by far the best interview I've ever had. Hands down. Bring the person in, bring the candidate in, buy them lunch. At the very least buy them lunch, but I'm a bear at the end too. And take a existing module that you have that's fairly simple. Show them what it looks like and say, can you reverse engineer this? Take all the time you want. It's a completely open book. We're going to put your code up on the screen, so it's completely conversational. You can ask questions of us. We'll ask questions of you. We just want to know the process. We want to know how you code. I don't care that you're Googling really simple Drupal functions. I do that. I'm not embarrassed by that. I can't keep that all in my head. Now, the common reaction to this is, yeah, that's a lot of time. So don't, first of all, don't do this with every candidate. Do this when you're down to a final three or two or one. And also four hours isn't a lot of time if it means you're hiring the right. If you are much more confident about hiring the right developer. I'd rather spend four hours early on than find out six months from now that this person just isn't right and sort of passed that 45 minute interview but kind of bluffed his way through it. So once you've got the team, set the ground rules. And as you'll see on my list of regrets, we didn't do enough of this at Core Publisher and any project I do it from NPR here on in where there's going to be a lot of assumptions and ground rules. How to deal with TechDet. How are you going to deal with TechDet? I've used TechDet twice now. Does everyone know what TechDet technical bet is? You familiar with that term? Oh, not many. I'm going to completely oversimplify this. And Ward Cunningham is going to kill me for saying this. But TechDet is bad code that still works. It's not a bug because it still works. But it is an accident waiting to happen. It's a little, you know, grenade with a pin in it. It drives developers crazy every time they do it. It's unmaintainable. It needs to be fixed as soon as possible. It's often, I'll talk a little more about TechDet in a second. Coding standard, that's obviously the syntax. They greet upon set of rules. Your curly braces go here. There's a space here. Your comments look like this. Code reviews is having developers look at each other's code. Making sure it's okay. Making sure you're on the same page there. DrupalCon, I'm sure you've heard this all week. This is the whole ethos of open source and Drupal is contributing your code back to the community. Snippets, best practices. It doesn't just have to be modules and themes, but hopefully you're kicking that back as well. Scrum rules, I'm assuming you're doing Scrum Agile. Most people are these days. Do everyone know what Scrum and Agile are? Again, I'm not a Scrum master. It's basically a way of working. You iterate usually over a two-week period. You plan at the beginning. You work on... I'll talk a little bit more about Scrum in a second. Testing, what tests suite are you going to use? How much coverage are you going to get? Things like that. And VCS is just version control system. These days, especially now that Drupal.org and Drupal is on Git, you probably should be on Git too if you're not using Git. If you're using version control, get on version control ASAP. If you're not using Git, you need to have a really compelling reason why not. Okay, tech debt. I'm going to sound like I'm overstating here, but I'm going to say I can't overstate this. I feel like I should take off my shoe and bang it on the podium here. Tech debt will kill you in your project. It will just absolutely destroy developers' morale and motivation. By its very nature, it's sort of viral and self-replicating. You often see the broken windows theory from sociology or anthropology used to describe that and what that means is if a developer is looking at existing code and sees some bad code, some hacks, some shortcuts, some laziness, he'll say, oh, that's okay to do that. I guess I'm going to do it here as well. And suddenly you have twice as much tech debt in your module than you did yesterday. Yeah, absolutely. If you don't have a firm plan to deal with it, first step is to document it. Know that it is tech debt, right? Say, okay, we need to get this out tomorrow, but this is tech debt. This is a shortcut. We need to fix this as soon as possible. Go back to the Wiki and document it. Write a ticket in your ticketing system saying we need to fix this ASAP. Have maintenance packs and trigger deals. So true story on another project that wasn't core publisher was a side project we were doing. I literally made a pinky swear with the product owner and said, if we get a fifth radio station on this product, we have to write a UI. We're not writing configuration in code anymore. The sad part is that the project got spiked before we got to five radio stations, but I felt very confident and I kept on reminding her that we did this pinky swear. I felt confident that we would deal with that tech debt if we had to. Coding standard. I can talk about this all day and all night. This is probably my biggest passion. The good news is Drupal has an existing coding standard that's pretty exhaustive. 90, I say 97, that's a pretty good number. 97% of the time, if your two developers have a dispute about a bracket, a comment, a space, something like that, just go to the coding standard end of discussion. The developers I used to work with on core publisher, we actually had a good time about this. We'd go racing over to the coding standard and say, I think I'm right. No, I'm right. Someone's right and someone's wrong. It's pretty black and white. And this is another talk I give, another talk I give that I am very passionate about is, I would highly encourage you to go well beyond the Drupal coding standard. So, look at common idioms and design patterns in your code and codify those and say, and basically create a style guide for your code. You know, always we say, we have a saying in the core publisher of each team, WWCD, what would core do? If it's not spelled out in the coding standard, then we look, is there an example in core? Which isn't always the best. Core is not super consistent, but it should provide you with some guidelines. If you start writing these guidelines down, the fewer debates you're going to have on your team and the cleaner and more maintainable and predictable your code is going to be. Like I said, I have a whole other talk about this. I like to talk about how Drupal's cookie cutter code. I love coding Drupal, but 70, 80% of it is very rote. You know, I need a page, okay? That's a hook menu, but only certain people can see this page. That's a hook permission. It's black and white. Like, just do that. There's no alternate way of doing that. And then the more you rootinize these things, I think that's a word. I'm pretty sure, anyway. The more you make these routine, the more time you'll have for like the really fun stuff, the really creative stuff where there is no black and white answer. Code reviews. Well, I'll talk about, I'll do the big reveal about regrets later on, but not only is this, your developers have to be looking at the code base as a whole, and they have to be looking at it in real time as other developers commit you code to the code base. And it's not just good to have sort of another set of eyes so it's more consistent and whatnot. It's just a great learning experience because you learn things as you look at other people's code and you also interact more with your other developers. You get to know them better. It does require a baseline of respect, which again, if you've done hiring right, that shouldn't be a problem. If you can't get developers to look at each other's code because they're too proud or they're too thin-skinned, they're too defensive, that's indicative of, you've got an iceberg there. You've got bigger problems underneath the surface. Also, if they can't do it with a modicum of fun, that might be a problem as well. Honestly, when I was on the core publisher team with the last iteration of developers, I loved doing code review and we would give each other a fair amount of grief but we had that baseline of respect that no one took it personally and we learned so much. You need to be a mixture of confident but also a little bit humble and not thinking you know everything. Kicking code back. I talked about how this is the whole driving force of open source and Drupal. The more you can kick back, the better your code is going to be. If I'm just writing a one-off custom model, it's going to be a little sloppy. I'll admit that. If I know it's going to be on Drupal.org for anyone to see, it's going to be written a lot better and it's also going to be sort of more Drupal-y. That's definitely a word. Don't tell me that's not a word. I use that every day. It's going to be modular. Drupal is very modular so instead of one big Uber module that has seven features, it's going to be broken apart into small, maintainable pieces. Free beta testers. Some of that we have not related. I'll admit we have not released enough stuff to Drupal.org but the stuff we have released, people have immediately picked up on feedback, all free of charge. And to be perfectly selfish, it's really better for your resume. If you walk into a job interview and say, yeah, I've been doing Drupal in open source for two years. I wrote, you know, thousands and lines of code and 10,000 commits and the hiring manager can say, well, show me. Oh, I can't. Is it an NDA? No, we just never got around to releasing it. It's not going to help your job prospects. It's much better to say, this is what I did and here you can see it and I'm proud of it. It's nice and shiny because I know anyone can look at it at any time. Scrum Agile. So again, this is a way you work. It's very common these days. Basically, you sit down at the beginning, you plan out what you're going to do for the next two weeks, you do it, you regroup, you push the code live and then you regroup, talk about how those two weeks went and then start all over again. Again, I'm not a Scrum Master. I don't have any little certifications on my wall. There's things I like about it, things I don't like about it, but mostly like it. Everyone I talk to out there always, they seem a little sheepish and say, well, we run a slightly modified version of Scrum. I don't think you should be embarrassed by that. You know, there's all these rules and books and whatnot about this is how Scrum should run. The bottom line is does it work or does it not work? If it's not working but the Scrum Master says you should do this, that's a bad idea. I was at a Scrum training session one time and the guy next to me had a question about multiple product owners and the certification guy sort of hemmed it hard and said this and that and I just wanted to step in and say, is it working? You know, if multiple product owners isn't working, stop it, change it. The fact that it's okay by the Scrum Master doesn't matter. So what do devs and yeah, I'm a developer, I can speak for developers or at least developers I know but I think designers in front end and I think probably a lot of people agree with this. So you have a daily stand up usually at the beginning of the day or the end of the day so it doesn't break up your day. Maybe lunchtime, that might work. It's got to be brief. I think a great idea which ensures that it should be brief. You're only supposed to say three things. What did you do yesterday? What are you doing today? Are there any blockages? But it's a great way for we already think good communication on the core publisher team but it's a great way if you're not paying attention or you're out that day or you're buried in your code to say oh, that guy's working on that, you're having a problem with that? I remember that. I know how to fix that. Another great thing about Scrum is tickets. Manageable tickets. You write out a task, a very explicit task and task actually has a specific meaning in Scrum. I know, I know, but bear with me. You write out a ticket that I want to add this feature. I want to fix this bug and developers love that. Give me tunnel vision, that's all I'm working on right now and in a broader sense you have sanctity of the sprint as well but that means is unless something is on fire on fire new tickets don't get added to the existing sprint. You have some priority it better be, you know, a site needs to be broken before we interrupt the sprint. Come back to me in two weeks at the end of the sprint. And that, again, that is, it sounds confining but it's really liberating to a developer to be, hey, I'm free I'm not worrying that someone's going to run in and break my flow and make me some stupid task that really does not need to be done this week. Clear prioritization of issues, which is important when you do your planning you can see what's happening this week what's important, what's not, what's got bumped down and the retro as I mentioned at the end of your sprint usually in two weeks you sit down and you have an airing of the grievances basically or a celebration of the successes of what's happened in those past two weeks. And again looking for warning signs if you have everyone sitting there looking at their fingernails for two weeks that's not a good sign it means they're not communicating honestly because there's no way something didn't happen in those two weeks, either good or bad. By the same token if everyone is yelling and screaming every single retro that obviously, I don't have to tell you this but that's not a good sign but if it happens a couple times a year once a quarter it's a decent sign you guys are working on hard stuff with deadlines people make mistakes people check out for a week people are preoccupied with something at home maybe there's going to be problems and as long as you're communicating honestly I think that's a good way to go with the retro what don't they love as I mentioned before blindly following procedures and saying hey, we have to use this tool to manage our tickets because we've always done it that way or hey, this is exactly the way sprint, you know, this is the way Agile says we have to do things even though no one likes it and it doesn't make any sense we still have to do it this way similarly, people particularly on the product side who don't get you know, horror developers they might see Agile and their eyes light up and say oh, this means we can if it works on the screen during the demo live server, right? no, no, no, no this is a proof of concept we have a saying a POC proof of concept plus a live server is a POS and it's very true you know, people also just hear the word Agile and think oh, that means we can jump from project to project and it's just a messy way to do things developers can tell you when tests have been written when it's passing tests when there's little to no technical debt and that's when things should go live word or two about architecture when I was asking for advice from some of the developers I worked with one of the guys said architecture is a feature and he was paraphrasing I'm sure from performance as a feature which is also true I don't know what architecture as a feature means but I really like it so no one steal that but I think it was getting at was ABA, this is from Glen Gary Glen Ross always be architecting always be thinking this goes out to developers put everyone on the team don't just develop features in a vacuum, you know if you get a feature think about it and say go back to the product owner and say this feature is too broad or this feature is too narrow if we make this feature a little more abstract that use case comes up which it probably is this feature will be able to deal with that you know when you get a feature say is this a stand-alone feature should I build a separate module or can this go into an existing module always thinking about that stuff don't abstract things too much but don't just take the feature as is and say okay this is what the product owner wants I should build it that way small pieces loosely coupled I wish this were my phrase but this is all over software books and blogs and what not is actually relevant when you're building with Drupal which is a modular system it's always better to say to build one feature per module couple them together you can turn it off and turn it on without breaking stuff you can write small this is Larry Garfield channeling Larry Garfield again write small manageable testable functions don't write what we call God functions that do eight different things err on the side of releaseability that's a word too releaseability I use it every day what do I mean by that I always think there's a JD Salinger story I want to say it's Franny and Zoe it has these deep theological implications implications but at the end of the story one character is telling the other character shine your shoes even if you know no one is going to see your shoes right that's the same thing with your code write your code as if it is going to be on the homepage of Drupal.org even if you know it isn't it's just such a good practice to get into it's always easier to just push a button that says release rather than say oh man do I have to tidy this up and also you're going to see this in my list of regrets but we again we were building on an alpha so we did have to write an awful lot of custom code early on but there are times when you know your first choice should be a contrib module product owner says I want this feature say okay well we have this you know a good I should say a good well maintained contrib module that's not an alpha I guess that goes without saying you can say okay I want this feature say okay we have this contrib module it gets you 80% of the way there is that good enough no then go back to writing custom but say is there sort of a shim layer a tiny little you know hundred line module I can write that interacts with that contrib module that does what it should do that should be your priority list contrib plus a tiny bit of custom and then only as a last resort custom every module gets a real true API this is this is another 45 minute talk and it's really just aimed at developers but what it means is every module should have easily accessible functions that other modules and Drush can use again this is a I was inspired by Larry Garfield who gave a great talk about this given a great talk about this several times you should not be cramming all your functionality and business logic into a hook submit into any kind of hook a hook cron they should be your Drupal functions should be calling other functions work with Drupal this is my most abstract point so please bear with me on this Drupal is a CMS this is a long standing debate no it's a framework no it's a CMS no it's both 90% 95% of the time you're going to be using Drupal as a CMS you're going to take the minimal or the standard profile copy that or just use it out of the box and modify it you're going to be using the Drupal admin it's a CMS it's a CMS as such your approach to it should be extend and theme rather than I'm going to build this from the ground up and let me give you an example because this is kind of abstract okay this is a screenshot from the current project I'm working on I don't know how well you can see that but it's a very basic Drupal UI and it doesn't really matter what I'm doing you need to I'm modifying certain objects in a third party API but I want to use it I want to make a user friendly version of this that's all it's doing but as you can see it doesn't look great and it doesn't look great especially when I take a screenshot of the Drupal 7 theme you know you've got your ad group that's called an action link that's not incredibly intuitive you've got a lot of trapped white space you've got edit delete and the link say edit and delete if I'm a product owner and my developer comes back with something like this and I'm not fully immersed in Drupal and understand the Drupal's a CMS and not a framework I might say oh you know what I'm going to give this to the developer and he's going to make a better UI that's not part of the ticket though this is what the UI organically comes up with and this is the following existing here I'll go back on this slide you're following what did I say pre-existing well-worn core patterns so when you go back to this you write a separate ticket that says I'm not wild about the admin theme particularly I'm not wild about the trapped white space and the zebra stripes and the trapped white space and the action links and all that stuff that's what you say and it's a completely separate ticket it has nothing to do with this UI in particular similarly I would worry what I call comp driven development this is going to sound like a broadside against designers it really isn't I love designers I love working with them we have some very talented designers at NPR but if you give if you're starting on a project and you start with a designer and say go nuts write a fully formed web page give me a comp back it's inevitable that that person is going to put in inherent information architecture and features and all sorts of stuff which if they're not working with developers as they're doing this the developers have to then reverse engineer all this stuff based off of a PDF and things can get really strange and sloppy and I have a real use case of that but keep that in mind Drupal's a CMS think extend think theme don't think I have this feature I want to see what this feature looks like from top to bottom I want this UI to look different from the other core UIs a few notes on infrastructure again I'm not an ops guy I knew very little about ops when I got there four years ago I know a lot more but I still know very very little did anyone go to the caching session the two hour caching session yesterday it was kind of detailed it was amazing I can't believe what these guys pulled off in two hours really really valuable you should know this even if you have no technical skills at all but Drupal is very expensive it takes up a lot of memory and processing power you need to start caching ASAP you're running a multi site and you have like five pilot sites that's about the max you want to get to before you start thinking about caching if you have a big Drupal project do not go live without many many layers of caching it's just imperative your site will go down so fast similarly this is front end performance you know big images huge javascript files you got to keep those in check at the beginning or else it's basically another form of technical that fortunately ten years ago sorry four years ago 2010 that was a bigger problem 2014 now people think mobile first all the time so they're thinking you know very lightweight websites from the beginning which is nice to see so that's less of a problem as I said before the line between ops and code gets blurrier and blurrier the more you as a developer can write bash and glue code and what not and help out ops the happier they're going to be and this goes without saying as well but it's good to be able to write these bash scripts and stuff but the more you can automate and outsource Nagios we use Nagios to make sure our servers are up in the middle of the night uh agar which we don't use we built our own agar but again that's another talk that allows non-technical people to deploy sites new relic for monitoring performance if your site's kind of sluggish you can go to new relic these all cost money and time and everything but I'd much rather get a ping in the middle of the night from Nagios saying hey this site is might be down can you do something about it then getting a ping 45 minutes later from a general manager who's you know has our VP's personal cell phone number saying hey the site's down Jenkins for various levels of automation all kind of standard stuff but stuff you need to be thinking pretty much from day one again being all being on the same page uh advice for product owners again I'm not a product owner um and this is advice I've given to product owners I know I think um this first point actually is something that our product owner came up with and I find it incredibly valuable and she's actually asked us to repeat this phrase to us when she seems to be strained from it and what do I mean by that provide the dev team with problems so when you write a ticket for a feature it should say something like as KUT which is the one of the local Austin radio stations as KUT this is weird um this is how issues are written in scrum if you don't know as KUT I would like to have a list of local stories on my homepage there's not any local stuff it's all national that's the way to write that ticket that's the problem don't write it as as KUT I would like a view with the following parameters on my homepage in a block with the weight of such and such that's for the developers and the frontend guys and the designers to figure out and again it provides a nice clear line of distinction of what the product owner should contribute and what the team as a whole should contribute uh be a leader not a dictator um probably goes without saying the first time you say to your team that's for something kind of out of the blue with no really good explanation you're gonna start to lose people and lose respect communicate or over communicate you notice under communicate is not an option here I feel like I'm giving you uh the top five number one pet peeves of developers like well I only have one peeve as a developer but there's five of them right uh but one of them is definitely getting sandbagged in the middle of a meeting with some bizarre request or feature you know some bizarre feature request that comes out in the middle of nowhere with no good explanation you know if we know that's coming a couple weeks ahead of time if we see that in planning it's much easier to to a argue against it and b be ready for it stay focused I've touched on this a couple times now it's it's tempting to say oh wow this is you know there's a nice shiny new toy over here I think we should start working on this or hey let's do uh let's do a responsive theme but at the same time let's cut down on tech debt but at the same time let's build up um you know a TV API at the same time like stay focused the developers are going to like you a lot more for it and stay positive you're a leader and this goes out to the to the dev lead as well stay positive don't stay positive to the point of insincerity because people can smell it a mile away if things are bad admit that things are bad and talk about how to make things good but uh you know don't be a grump just because you're feeling grumpy uh basically it's you know people will follow your lead if you um if you show low morale then the developers will follow okay so the um the talk summary promised a uh short I think I should have a short list of regrets it's a little longer than I expected uh so I have to deliver on this uh this is this is sort of the practical stuff you probably could have guessed this from the first uh whatever 45 minutes of this talk um all this stuff basically boils down to I feel really good about where core publisher is today I'm happy to be doing something different after three and a half years but I think it's it's in a good place right now it's a huge project so there's always going to be tech debt there's always going to be bugs uh but it's in a much better place than it was before I just wish we'd come to a lot of this stuff sooner rather than later basically and so like I said I think at the beginning um these are lessons for you as well as lessons for NPR the next time we start a project I think we want to go down this checklist and say you know uh what's our plan to deal with tech debt uh what's our plan to deal with testing coding standard who's going to enforce the coding standard um how are we going to treat this uh what's our what's our process on grabbing custom code versus contrib uh like I said before are we going to do this on you know early early adapters are early adapters um we had to just make so many changes because we did this on an alpha it might have behooved us to wait a little bit and we stayed on the island a little too much we started uh you know uh I'm going to get this wrong Drupal uh we picked up a hammer that was Drupal and then everything we looked at was a nail basically sometimes that was good sometimes not so good um we uh focused a little too much on Drupal basically um this is my this is my touchy feely finale uh but I think it's important uh might have been a little negative there so I want to end on a high note uh we live in a fascinating time it's eerie and creepy I admit but it's fascinating and it's it's nice to be part of the fascinating thing things that are going on you know uh driverless cars solar powered roads does everyone watch the solar powered roads video on youtube google it there's there's two different ones there's like a nuts and bolts one and then there's a more fun one but uh it'll make you feel a lot more hopeful about the future and about technology and make you want to wake up in the morning I don't know about you but I get to do my hobby is a well paying job I don't know a lot of people that get to do that and um it's a real privilege and never take that for granted I mean it's really especially working in public radio which is something I love and I listen to every day um you know I have friends and co-workers who have the whole TGIF vibe and it's not like I don't really enjoy spending time with my friends and family on the weekends but I don't dread Monday morning either so don't take that for granted you know if things are going bad on your team take a step back and take a deep breath and remember that you get to do something really great every day um this third point I almost put in the PO slide but it really is for everyone stay humble and curious you're right I don't know I was wrong those are the three most important things you can say at a stand up at a retro at planning don't be so thin skinned and defensive you know don't be overconfident you will gain so much more respect if you stop your product owner and say yeah you're right I was wrong there that person will respect you so much more and I don't know I'm a like a lot of people out there I think I'm a pretty good developer but I'm also self-taught like most I'm a former theology major who's pretty good at math that's basically you know my back story I know nothing about hardware I know nothing about CS I knew very little about servers until I started at NPR I asked my boss and my director of ops the most naive questions but I know they respect me and they'll make fun of me but in a good natured and respectful way you know say it's perfectly fine to say I don't know like you don't know everything no one knows everything um any fans of the wire out there alright so if you want to know more google this last phrase you'll see a little clip as much as I talk about hiring people who do development as a hobby and are working from six to eight don't let it consume you I mean it's great and I love it and I'm obsessed with it but it doesn't consume me the video is the video clip from the wire I'm sure it's not safe for work but it's all about Lester Freeman who's a good cop and dedicated cop but he has a girlfriend and he makes dollhouse furniture and he has a life outside of the job and he just is giving it to McNulty who's a womanizing alcoholic who has nothing besides the job giving him full barrel saying the job will not save you Jimmy you know so um go outside and see your friends and family and um take some time off have a beer and enjoy yourself and that's me if you want to talk about Drupal if you want to follow me on twitter talk about nothing except this stuff on twitter basically um which is good I don't talk about food I don't talk about my daughter I don't talk about anything except Drupal minutia basically and tech debt and what not so if you're into that I'm a good person to follow if you something want something more casual than don't if you want to talk Drupal that's my email address um there's the if you want to comment on this talk please do there's the link there's no way you're going to write that down easily enough on the Austin Drupal con site we are if you're a developer I believe we still have one more position open Boston based if you know anyone who's Boston based or you're Boston based it's more of a general web generalist job it's less Drupal I think it would start I don't know I'm not doing the hiring at all so I wouldn't know about it but I I think it's more um we're looking for someone with note or willing to learn note so come see me I'll give you a card and that's about it we have seven minutes for questions can you get up to the mic maybe while we're waiting for him great talk I think perspective and humility are very often lacking in this industry and I think that's it's good to promote those principles sort of being a little bit newer to Drupal and adopting it I'm also doing a lot of web application work in our agency curious what your comments on Drupal don't treat Drupal as a framework it's a CMS and there's boundaries what in your experience are those boundaries and how would you know given your experience the last four or five years what would you have done differently when you start to hit those edges of where Drupal is not a framework um yeah this is like I said this is some of the that's the more sort of abstract and not fully fleshed out and I have like two really good examples but I don't have enough good examples to really write like a whole talk and treat us about it but it does go back to um you know if we could travel back in time and I think it should come clear in this talk that I have the greatest respect for our core publisher product owner but she didn't know a lot about Drupal she came from a different sort of I think dream we very kind of background and so it was the it was the thought was we need this feature let's pump it out first with the design and then build it as opposed to um because it's harder to it's easy to write a comp to to to drop a comp it's much harder to make a list of sort of features and what not um it's much more abstract but if you do it that way like I said the UI and everything sort of organically comes up you know if you the more sort of generalize the task the the feature say um I want this and then your Drupal experts can come in and say oh you know what that's a view and that's a block and we're going to give it this way and we're going to put it here um again um it's hard for me to the real example is uh when core publisher started out as a as a uh it first started out first iteration with something called news destination which was a um it was just a very very simple reverse chron block a river of news and we we didn't have views yet we didn't have features yet um but we needed this and I'd have made sense to do it in WordPress off the record this is being recorded damn um but we started with a comp which is bad because there was all these weird things that got a comp we started with like two modules in a theme instead of five or six smaller more discrete modules in a theme you know um we did too much custom work which again early on we really our hand was forced and at the time I argued that we didn't need views because our our uh our query was so simple it really is just give me everything paginated um but we we took us forever until we actually did move over to views when views was available um so I don't know if that answers your question it's it's it's um uh work with the designers early on grab as much custom as possible make sure your product owner understands that it's better to grab a custom mod like give us a very very abstract idea of what you want and then let's look at contrip let's browse through contrip there's what 20 that is an insane number of modules like something's got to get you most of the way there and either you're okay with that or we write a shin layer so that's uh I can probably talk more about that but uh if you want to talk later but that's those are my general thoughts off top of the head thank you more questions so knowing what you know after three and a half years of building a poser which is awesome by the way we use it um as I mentioned before on our site would you have still built it in Drupal if you could go back well as I was talking to my coworkers and trying to get ideas about this talk uh there was the question am I going back in time to 2010 or am I starting right now in 2014 so there's things I'd still do it in Drupal yeah um like I alluded to some of the other sort of side iterations news destination and some other things we might have done in something different but I definitely do it in Drupal I would have waited uh until uh core publisher was sorry Drupal was actually stable Drupal 7 was stable uh would have used much less custom stuff finer grained things but yeah I would have stuck with Drupal I I actually talking to product owner about this I also would have been more and I think I just sort of said this already been a little more uh forceful at saying stop treating it like a framework right like hey we've got a module that does 80% of this please say you want this you know I know it's not how your designer drew it up but it will save everyone time and hassle if we can just use the group stuff you know the contrib stuff there's a lot of uh changes I would have done in the infrastructure and um some deep dive Drush make stuff and things like that but but all in all yeah anyone else last call alright let's go eat lunch then thank you very much I appreciate it