the dev show

Matty: [00:00:11] Hello, and welcome back to Arrested DevOps, the podcast that probably won’t destroy your career with bad advice. I’m your co-host, Matt Stratton, @MattStratton on Twitter.

Trevor: [00:00:23] And I’m your co-host, Trevor Hess, @TrevorGHess on Twitter.

Matty: [00:00:27] So this is episode 3 of Arrested DevOps, also known as The Dev Show, when we decide who put the dev in the devity dev deops. So we have a panel of a couple app devs who are going to talk to us about what they think DevOps means and what it means to be an app developer. But before we get to the panel, as always, we start with our retro. So Trevor, what have you been up to since our last podcast?

Trevor: [00:00:51] Well, I successfully completed another revolution around the sun. Um, took a long time, about a year, but, uh, it went well.

Matty: [00:01:02] Um, do you mean it was your birthday or just that it was a new year?

Trevor: [00:01:05] Just it was a new year. Uh, I guess, yes, you could, you could define your revolutions around the sun in many ways. Um, but other things I did, um, tech-wise, I got some family members some Chromecasts who are, I’ll be honest and say they’re not necessarily the most tech savvy. I was really impressed at how quickly they picked up how Chromecast interfaces with their iPads and their TVs. It was, you know, it makes it much easier for them. I was impressed. How about you, Matt?

Matty: [00:01:42] Well, we celebrated the holidays, and I don’t know if you know this, but pretty much when people know you like one thing, they decide that’s the only thing. So I got a lot of Doctor Who stuff, including my trusty Sonic, which my 4-year-old twin boys decided was the coolest thing they’d ever seen, and they wanted to play with it way more than anything that I got for them. And then I’m also in progress on my new tattoo, which is inspired by Game of Thrones. It’s not done yet. Those of you who are listening, we’ll put up a picture in the show notes if you care about such things. So, that was mostly it, and then did a bunch of work, lots of cloudy goodness and PowerShell-y goodness and DevOps-y goodness. So, that’s where we’ve been. So, I think we’re ready to get to our panel. Again, we’re talking about the dev side of DevOps, and those of you who are listening, if you have questions for our panel, you can either clickety-click on the Q&A button that’s on the event page if that’s where you’re watching, or feel free to send us tweets @ArrestedDevOps, and we’ll try to get to as many of the questions as we happen to notice that you actually post. So let’s introduce our panel. First, we have David Braverman. Dave, you want to tell us a little about yourself?

David: [00:03:04] Yeah, I’m mirroring my own video, which I have to stop. That’s not going to work. I’m a developer here at 10th Magnitude. I’m actually sitting about 2 meters away from Matt over there. I’m a managing consultant, so I get to listen to clients yell at us when things go wrong with their applications, and usually I’m the one who caused those problems, so that’s fine, that’s fair. I’ve been doing this since the Pliocene era. Started working in development back in 1977 when I could barely reach a keyboard, and that’s why I have not studied it ever in my life formally. So I tried to do 3 different things and kept coming back to this. And I should stop talking now because Matt’s looking at me. So I’m here, I think, because I’m really convenient. Matt can just, you know, shoot rubber bands at me to get me to say things. And also because I have wanted to get operations at 10th Magnitude for a long time before we got Matt, and I’m actually really pleased that he’s here and that he’s doing this because we need it and a lot of companies like us need it. And I think it’s good that we’re getting the word out. Back to you, Matt.

Matty: [00:04:26] Thanks, David. Also, I just noticed while this was going on that I forgot to turn the Q&A function on, and you can only do that at the beginning. So all that stuff when I said there was a Q&A box you could type questions in, that was a big lie. So just tweet them to us. Our other panel member is Dan D’Angelo. So Dan, would you like to introduce yourself and tell everybody how I mangled your name? Because I think I did.

Dan: [00:04:49] Oh no, actually, I’m actually well impressed. That’s exactly how it is. I’m a web developer from Chicago. I’m leading the front-end development at Apartments.com, which is actually how I connected with Matt originally. And I am also a freelance web developer, which I’ve actually recently transitioned from freelance into the full-on company where I’m doing a split between web development work for various clients, and then I’m also doing the startup side. I’m actually working on developing a set of social tools right now. I guess the reason I’d say I’m here is I’m a developer, so I don’t do the DevOps side as much as I’d like, but I do it on my personal, and I’m trying to learn it. I interact daily with various teams of DevOps. It’s a very one-to-one relationship with them, so I’m very well connected to it and doing my best to learn as much as I can and kind of connect that back to what I do in development on the front end.

Matty: [00:05:41] Yeah, I would think with what you’re doing with your startup and with your own company, you’re probably doing more DevOps than you realize, because usually in a startup, that’s kind of out of necessity rather than desire.

Dan: [00:05:54] Absolutely. I’m coming from C# and then also transitioning into Ruby and now Node.js, which is a whole other ballpark. And, you know, I knew a little bit about it, the DevOps world, but now kind of getting full-on into it, it’s a whole other beast on top of development to learn. So you’re absolutely right.

Matty: [00:06:13] Okay, I have a question, and this is for either, for anybody that wants to jump in. So how do you think through your career, be it numbering in the decades, like our elder statesman David, or someone who’s starting out even so, how do you see what the role of the developer having changed over that time, if you have seen it change at all?

Dan: [00:06:45] Anybody want to jump in? So I would say, I’m kind of more infantile in my career, or at least as far as heavy development is concerned. I guess the best thing that I could say is that for me, it’s when you do development or you start on really anything, you get very lasered into the thing you do. It’s, this is what I’m doing. You kind of live in your own little bubble as you’re building things. But as you kind of get farther along, especially where I’m working at now, I see that the DevOps side, you kind of have to evolve as more than just, okay, I’m putting together this application and there it is. It’s getting A to B for me. It has to get out to the world, or it has to make its way out to all the consumers that are going to be absorbing this product. I don’t think early on when I started development I really understood that, or I didn’t really think, to me, there was IT and there was tech. Tech was developers and IT was DevOps. I kind of really had this very black and white separation between the two, a little bit of meeting in the middle, but I never really understood that until I kind of started to progress farther down the line. It’s actually affected the way that I have to develop as well as the way that I’m thinking when I’m actually architecting applications.

Trevor: [00:07:59] So I think that’s really interesting because that’s kind of a similar way to how I approach development, except I’ve always, when I grew up, I loved putting computers together with my father. It was excellent when I built my first machine, so I kind of had a little bit more, you know, setting up the networks for various people, so I had a little bit more ops ingrained into me as I was coming along. So it was really surprising to me when I ran into developers who were like, what’s, I had to change what? What’s a BIOS? There’s more than one disk drive? And I’m like, you’re a developer and you don’t know what a disk drive is? It was, you know, there’s that balance of knowledge that is either there or it’s not, and you have to get through it.

Matty: [00:08:51] David and I were having a difference of opinion about this a few weeks ago when I was stunned and shocked at the fact that I said anybody who’s working in computers should be able to tell you about the different RAID levels, and we found out that quite a few of the very technical people we work with didn’t really know them, and I kind of had to take a step back and say, well, it may not be relevant these days. But I just always assumed that when I would do interviews, especially for TechOps people, that was like the softball question. And then people would whiff at it, and you’re like, great, now I get to sit through an hour with you. And you know, you just totally bailed on the gimme. But I figured anybody in tech would know that, and I guess it’s not as common. And then the question is: is it just a problem that it’s not, other than me feeling arrogant and snarky, or is that really a bygone era to care about those things?

David: [00:09:51] Well, I think actually part of what I love about where we are in development right now is that it might in fact be obsolete to know that stuff. I’m not saying that you, let me put it this way in developer terms. I know what a bubble sort is. I could probably write one in a few hours, whereas a computer science major might be able to whip one out in 15 seconds in C++. But I don’t care. I’m going to use LINQ. I’m going to use List.OrderBy, and I don’t care about all the plumbing anymore. It frees me up to think about the problem that I’m trying to solve. As a developer, the problem that I’m trying to solve is the business problem. Though I actually, going to your question about RAID levels, I spent the last couple of weekends actually dismantling my server rack, and Matt, you’ve heard all about it. I actually set up a whole server rack, 7U worth of servers, that’s 4 boxes, 3 different kinds of RAIDs because they had 3 different purposes. I want my database server mirrored, I want my Exchange server in RAID 5. I don’t really care what my web server looks like because if it goes down, I just bring it back up again because there’s nothing on it that can’t be replaced in an hour. So that was a problem. The problem that I was trying to solve with all those boxes is how do I serve these websites out? Now how do I serve these websites out is I go to Visual Studio and right-click and I either go publish or I go deploy. And what’s going on in the Southern Virginia data center, I don’t care, but bringing it back to the operations question, I don’t need to care what the RAID levels are.

Matty: [00:11:39] I had a question. So, I mean, you do have the downside is you had your websites on-prem in your house, and now you have them in the cloud. So I guess on-prem you were safe from NSA snooping at least, right?

David: [00:11:56] Yeah, yeah, that, except that if I—

Trevor: [00:12:00] BIOS level?

David: [00:12:01] Anybody reads, now, if anybody reads Bruce Schneier, he just, he’s every day he’s posting a new NSA exploit. Today’s is an exploit called Deity Bounce, and I was talking with Matt about this earlier. Deity Bounce specifically targets 5 models of Dell servers, 2 of which I had in my rack. It’s a BIOS exploit. Fortunately, it requires that somebody actually stick a key in the thing and reboot it, but I’m not too worried that the NSA is after me or that they’ve been looking at my servers, but it’s just kind of funny. In theory, my domain could have been owned by the NSA since 2006, and I would not have known. I’m just reading, yeah, targets 5 models of Dell servers. I had 2 of them. Awesome. Thank you, Michael Dell.

Matty: [00:12:48] So you were actually making a good point about operations before I interrupted.

David: [00:12:54] Yeah, the operational side is keeping things running, but I think what we have with the cloud and what we have with no longer caring about exactly how striping and parity works together is we can concentrate on the problem of keeping the customer’s assets available to the customer and their customers without having to think about how at a physical level that’s happening. In other words, the whole point of what I’m saying is if you take a lot of the concrete details out of the problem, it becomes a lot easier to think about the problem that you’re trying to solve and to think of new ways to solve it without having to spend, you know, 4, you’re going to edit this, but I was about to give you angina with what I was about to say, 4 hours to set up a 256 gig drive because you need 5 of them. That was, you know, actually it was 4. Yeah, I had 4 128s to get into, what, a 384 with RAID 5? Am I doing the math right? I don’t care. That’s the point.

Dan: [00:13:57] I think he actually raised a really good point. Matt, I could definitely say personally, I love, I mean, again, the operations side is not my area of expertise nearly as much as development, but a little bit of ego-driven that I love knowing a lot of the information that I do because a lot of people do not know that information. Absolutely. But I think that David makes a really good point that if you really step back, let’s just go down to math. There’s a big thing in education right now where they’re saying that why bother making people learn all these rudimentary mathematical skills when you can just have a calculator do it. My idea is that I feel better that I know that, but I can see that utilizing, say, like he was saying, let’s say a cloud server that’s doing all that backend legwork that I don’t need to know about, I’m okay with that. And I think that really also comes down to role. For operations and for you personally, I would assume to you that information could be very important, even beyond just knowing it as some type of base knowledge, whether it applies or not. But for me, in development, I wouldn’t ever, just like David said, that’s not a piece of information that necessarily is going to affect how things are going to be for me. You’d be dumping into some really heavy memory management stuff maybe to really sync that up. But again, like David said, it’s just, for me, that’s not a piece of information I necessarily need on hand. But again, I do feel better that I know it. And I do think it can help me in certain applications.

David: [00:15:14] Yeah, I agree with you. I think knowing the fundamentals helps you. And one of the things that in my career, my background is that I have degrees in history, law, and business. I have taken one computer science class by exam. That’s the extent of the studying that I’ve done. And I think at times, that has actually hurt me by not having the fundamentals, it kind of slowed me down in some aspects. But just to talk about, so I’m of two minds. One, I think knowing the fundamentals is important, but on the other hand, picking and choosing your fundamentals may also be important because we don’t need to know how to arrange RAID arrays anymore. We don’t. If there’s a performance issue in an Azure product, in an Azure cloud service, the performance problem will not be solvable through hardware, even if hardware is part of the problem. We have taken that out of the equation. Matt, would you agree with that? I mean, is there any way really other than changing which size VM you’re on?

Matty: [00:16:22] If you’re talking, I mean, again, if you’re looking at it as anything as a service and whether you’re, and fundamentally in a DevOps scenario, whether you’re talking about being in the public cloud in something like AWS or Azure, or if you’re talking about private cloud, which is your home, your on-premise virtualization, usually the only place where you really, everything is quite literally virtualized away enough, it’s abstracted away enough. I mean, what’s the quote? There’s no problem in computer science that can’t be solved by a sufficient layer of abstraction. But the place where it comes into play is it can come into play when you have really I/O-intensive applications and you’re starting to play some games. And we see this with certain cloud providers too, that even when you’re virtualizing disk, you’re wanting to be able to distribute it, but you’re looking at it in such a different kind of way. I guess that the reason that I think it’s important to understand the basics of it is because if for no reason, then you understand when it’s not a problem, right? It’s one of the easiest things in the world to blame is something you don’t understand. Okay, what’s something that very few people in technology, developers, even sysadmins, whatever, storage. Storage messes people up. Storage is hard. And I’m not talking about like a radar. I’m talking about something like a SAN. You’ve got this big EMC frame. You’ve got something like that. People don’t fundamentally understand it. So what’s the first thing you go to blame is the thing you don’t understand. So people love to blame the SAN. Oh, it’s gotta be because of the SAN. I got news for you. It is almost never the SAN. It’s how you’re using it. It’s how you’re configuring to go. So which is a roundabout way of saying that if you understand even at a high level, you know enough to be dangerous. You know enough to say, I’m not going to sound foolish by blaming something that couldn’t possibly be the problem. So I think that’s where understanding these types of configurations and stuff can come into play. Now, when you’re talking about something with the way that you’re interfacing with it, it’s such a virtualized layer, be it in the cloud or something of that nature, yeah, like how the disks are laid out, how they’re striped probably doesn’t come into play, but you really need to understand disk I/O. You need to understand how to read disk queues. You need to understand, because you’re still talking storage, be it physical or virtual, and you can’t just assume that the storage, now again, like you said, are you going to be able to fix it? Are you going to be able to drive down to some Amazon data center and say, hey, I really wish you’d, in this rack, I wish you’d change the way that you’ve got these disks striped? No, but then you know it’s a limitation, and then you code around it.

Dan: [00:19:24] I think you kind of hit it still as far as what David and I were saying about how it comes down to the actual person. A lot of people come to me, and I’m sure you guys have had similar situations, like, I want to get into DevOps, or I want to get into development. Tell me what it’s like, or what it is. The one thing I always tell people is that I think the best developers, the best DevOps guys, the best system admins are the people that care about exactly what you’re saying, Matt. It’s the people that do care about the fundamentals. They want to know how things are working. It matters to them. It helps them get, say, their brain in sync, whatever the case is. Those are the people I think that are the ones, much like it sounds like everybody here, is very deep into the fundamentals, and you do see the value in it and how that can be the case where there is an issue, and it doesn’t always have to jump to, well, maybe it was this guy, maybe it was this system, maybe it was the application. I think it’s very much so based on that person, which is why I think it’s really important for things like this podcast, among other things out there, to evangelize how important it is to know the fundamentals, like David was mentioning earlier, that there is a lot of value in what it can be for you and for the teams you work with, or even if you work by yourself. There is a lot of value in having that knowledge and how it can empower the things that you’re trying to build.

Trevor: [00:20:33] I think it’d be interesting if you build a little bit more on what David was saying about the ever-changing fundamentals though. You know, now it’s not necessarily as relevant to know the different levels of RAID. You don’t need to know how to do a bubble sort. There’s tools out there to do it for you.

David: [00:20:51] That’s true.

Dan: [00:20:52] You know, I’ll give you one. I’m actually reading a book right now, and honestly, if I tell you, you’ll be like, why? I’m reading a book called Code, and it basically breaks down from binary to low-level languages, all of what’s happening at the real root of a computer. And that has absolutely no application to my development, but I don’t know, I find that fundamental, just more part of the thought process that goes into the things that I’m building. And it always comes down to maybe not necessarily the grind of what I’m doing, but the architecture and the logic that I’m putting into the things that I’m building. Not being so lasered in all the time and thinking about how each of those pieces are playing together, because there is more than just a couple pieces nowadays. And in regards to the ever-changing fundamentals, again, I think that’s very important for developers, for DevOps, anybody to constantly be on what I always call a quest for being better. You want to be better. You want to learn. A lot of people, constructive critique, especially on code or anything, a setup of a system, it’s kind of tough. It’s a personal view of what someone, or someone’s giving their personal view of your work. And that’s what we need to embrace is that. So we’re always looking at how can we be better, what’s changed in the field, what can we change to make it better, and kind of bringing that, like I said again, evangelizing it. That’s why things like this podcast are awesome because it’s a way to start to bring that out in more people and find the people that truly love what they do so that they can always be on that quest.

Trevor: [00:22:11] And that’s one of my favorite things about being a developer is that you can never have the, you can’t stop learning. If you stop learning, you’re dead.

Matty: [00:22:22] Absolutely. I always used to say, and this is my, pretending to be ahead of my time, but I didn’t know what to call it. But even 5, 6 years ago, I remember saying things like that your best developers have a little sysadmin inside their brain, and your best sysadmins have some developer to them. That siloing is rough, and now, really with the way the toolsets go and the way that we’re trying to do agility and velocity, you really can’t, that flattening needs to happen. But even before, even if it wasn’t part of your job, even if you weren’t allowed to do those things, you kind of needed to be good at what you did. I would feel like you had to understand the system and systems, and that’s one thing that, and I know we kind of were saying, what’s the level of how you understand them? And that’s, I think, where the abstraction comes in, right? Do you need to know how to go and tweak the hell out of a kernel? No, but you should know how to, if you’re a .NET developer, you should know how to tweak the hell out of IIS, right? If you’re developing in Java Spring, you should really know how to kick the crap out of Tomcat and know the right way to set it.

Trevor: [00:23:41] I don’t—

Matty: [00:23:41] You know what I mean? I have little patience for developers that then go to tech ops and say, I don’t know, how should the middleware be configured? It’s your application, man. There’s more to developing an application, in my mind, than writing the procedural code. I would like to hear what David says about that.

David: [00:24:00] Yeah, yeah. I hear what you’re saying. I guess it depends. So I’ve been in a lot of different roles, and independent more often than not. And I’ve learned a lot of the operational stuff as sort of part of my toolkit. But I’ve also been building applications that were, you know, the size of doghouses in some cases, or maybe strip malls in others, where you had a small team, and everybody’s got to chip in, and I need to know how to run the cement mixer. But on bigger teams, it can take away, I think it can take away brain space from developers who, especially people who are just learning, people who are new to the profession, it can overload them. And I think as a lead developer, I would see it as my responsibility to protect more junior developers from having to deal with that level of detail so that they can get on with the problem of writing the code. But as they get older, especially to Dan’s point, as you get older, as you progress in the profession, you have to, you’re either going to continue learning as much as you possibly can, and you’re going to learn sort of from where you start up and down the levels of abstraction, up and down the abstraction hierarchy, if you will, or you’re gonna wash out. I came into, I was there in New York in the late ’90s when people were getting paid $120,000 out of undergrad, or sometimes out of undergrad, like they’d be dragged out of class, thrown in front of a computer, and say, okay, write some Flash. And then I was one of the guys who survived in 2001 when that vanished, when that, when the wizard flew off in his balloon. So everybody that survived that and then survived the shock, I think, again in 2009, are the people who do have that desire to learn more. But just the same, Matt, I don’t think that all developers need to learn this immediately. And I think, to get to my point, it is appropriate in a larger team environment especially for a developer to say, okay, ops guy, help me out here. I don’t know how to do this and I don’t want to. You know, at some point in the career that’s got to stop. At some point people have to get broader knowledge or they’re just not going to progress. But yeah, I think, somebody 3 to 5 years who’s on a big team and they’ve got a responsibility for one chunk. It’s going to help everybody if they don’t have to worry about the operational side, which is, to get back to the point of all of this, I think, why we need to have good ops.

Matty: [00:26:59] I think the clarification I’d make is I said a good developer. I didn’t say all developers. I would agree. You don’t start with responsibility over everything, and I wouldn’t expect that someone gains all the skills that they need to have right away. It’s the same thing. Admin doesn’t learn middleware day one. A good sysadmin learns the base OS day one and learns how to keep it going, right? Then you build on that. I think we’re going to have to start an over-under on how long into each podcast it is before I quote Lucis’s blog post about what DevOps means, but right? It’s not saying that’s not my job. It’s giving a shit about what needs to be done, and that’s the thing. That’s what to me I see is fundamentally something that is changing for the good, is that you’re getting less of this throw it over the wall and more of the, okay, I do care about the middle. Because that’s the thing, you need good ops people who understand the core of the operations, but that’s, some of that’s genericized, some of that’s like, hey, this is just good practice for running Windows Server, this is just good practice for Debian. Or whatnot, right? But then there’s the, okay, and what’s the special snowflake about this organization’s application? And the thing is, sometimes you have sysadmins who’ve been there for forever, and they know all the special snowflakes. But when you don’t have that, or you have a new app, the person that’s going to know the special snowflake the best, and I think that’s a land speed record for saying special snowflake the most in 1 minute, are going to be the people who designed and architected the application. Is that every developer on the team? Not necessarily. But to just sort of say, hey, I wrote some code, ops figure out how to make it work. That’s where it, and again, it’s collaborative. I mean, there’s stuff on ops’ shoulders too. They can’t just sit there and say, I don’t know, you tell me what to do. And that’s what we’re trying to evangelize with this, and that’s the difference between the way that we perceive DevOps versus, and by we, I’m speaking for this podcast. So Trevor, putting words in your mouth, so whatever.

Trevor: [00:29:14] I think I was getting ready to reiterate what you were—

Matty: [00:29:17] Yeah, it’s, we just believe it’s not a toolset. It’s not a role. It’s a culture and it’s an approach to things. And that’s how we look at it and everything we’re trying to share with people on this podcast is that at its core, but then saying, how does that apply? So I think we’ve been doing, I think I’m really enjoying this episode. I think you guys are fulfilling that piece, because when I was kind of throwing it out there on Twitter and saying, hey, who’s got questions for our panels? We’re doing, the topic is the Dev Show, and the response I got was like, well, that’s not vague. My thing is, if we say that that’s the point of DevOps, what does that mean to someone whose main job is a developer?

Trevor: [00:30:01] I mean, I think reiterating a little bit or building a little bit on what David was saying and what you’re saying, you know, the fundamental thing we’re saying here is giving a damn. I think the developer who gives a damn is not the developer who turns around and says, hey ops, here’s this application, go make it run on the website. It’s the developer who says, hey ops, I don’t necessarily know exactly how to do this. This is what I’m trying to do. How can we accomplish this? And working together with ops and making sure that you gain an understanding so that the next time a similar problem comes around, you can do it yourself, or you don’t need as much help in the future because you’ve grown your own skill set and you’re not just pushing it, pushing the blame, pushing the responsibility onto somebody else.

Dan: [00:30:54] You know, one thing that you kind of made me think of, Matt, is I noticed a lot the last couple of years, or actually probably the last half decade, there’s been a lot of push with things like Codecademy, Code School, the whole idea of 1 hour of code and everybody’s all, we should all code. What I noticed is I can’t personally think of any examples of, maybe it’s just because I’m not as well connected in DevOps, is there like a devopschool.com? I haven’t really heard of anything like that. Sometimes these kind of things that we’re talking about is a lot of educational base where we’re not teaching the right things to people that are prospectively wanting to be in this field. And that’s why it’s become a point where we have to evangelize much more efficiently, much more hard, because we have to create good developers because maybe schools aren’t letting them out at that, from that more lower level in their career, even before a career has started. Maybe that foundational level isn’t there. Does that exist in DevOps that I don’t maybe know about? Because that’s the kind of stuff I think would be phenomenal. That’s where you can really start hitting at the core.

Matty: [00:31:55] There’s a, and I’ll find the link and I’ll put it in the show notes. I came across a sysadmin training manual or something that was kind of like Codecademy a while ago, and it’s not complete. It’s like a community project. But it’s very Unix-y, like there’s no Windows stuff in it or anything like that, but it’s still really useful, I think. But you’re right, there’s not as much of this, hey, everybody should learn how to code. You don’t get, hey, everybody should understand how their damn servers work, which is probably would be a good thing. I also don’t know, it’s been quite a while since I was in school, but I remember I hired someone a few years ago, best intern I ever hired, became an amazing employee and has gone on to, actually he is a DevOps engineer is his title now and he’s doing incredibly well and is so important he won’t return my emails. But it was funny because he was the 3rd intern I’d ever hired into our sysadmin group into our TechOps group, and he was the first one that actually wanted to be a sysadmin. The other ones were developers, wanted to be a developer, they wanted to be a PM or something like that. But Billy was the one that was like, hey, so what do you want to do? Well, I want to be a sysadmin when I grow up. I’m like, really? Nobody says that. We all become sysadmins. We don’t do it on purpose.

David: [00:33:29] I spent years as a sysadmin for exactly that purpose, one of the, for that reason. It’s like, well, you know computers, here, fix this one. No, no, I’m a developer. No, really. Another reason why I’m glad that we hired Matt, because I was usually getting that call.

Matty: [00:33:49] It can happen. You can be a very successful and very advanced system administrator, and it’s not necessarily a bad thing, but it’s just, again, I don’t know among my peers, I don’t really know anybody that this was what they went to school for. What I tend to see among my peers is that it’s something that they started in one direction and through whatever winding road ended up in here. You see a lot of sysadmins come from military. Because there’s a lot of stuff to do there, and that’s the thing you can learn. When you, hey, if you join the Navy, or join the Army after high school or whenever, and you go do that, that’s a job. And they learn it real, real well, and they have very strong opinions about how things should be done. They have one very strong opinion about how things should be done. If you’ve had the luxury of working with a former military systems person or are one of them, I salute them, but they can be a lot of fun.

David: [00:34:55] Well, let me touch on something that you said, Matt, just a second ago. 2 words that have been floating around, and I think maybe it’s helpful to draw a distinction between them: job and profession. If you just want a job, then you can get vocational training in an area of what we do, and you can do it for 20 years and retire and get your gold watch, and I think that’s a valid career path. I don’t think the people that are tuning into this podcast are going to count themselves in that number. A profession is a group of people that are doing things and trying to move everything forward, trying to learn as much as they can about what they do, and that’s what we’re talking about, right? So I don’t know if that’s a helpful distinction, but it’s just something that came to mind while you were talking.

Matty: [00:35:47] I think I could see what you’re saying, because again, I guess I don’t know enough about development and don’t interact in the places that I’ve worked where you would have the 20 years and gold watch employees within IT. I tended to be, that tended to be a very siloed world where I didn’t know the developers, so I can’t speak to it, but I can definitely speak to infrastructure folks and sysadmins and DBAs and stuff. And you can absolutely do that in the TechOps world. You can go and you can work for the big bank, you can go work for the big manufacturing company or whatever, and you can be there for 20 years running those same systems, and not really changing because they don’t. And that’s, I think, is again, is when it’s, I’m going to stop swinging back and forth because I’m probably giving everybody vertigo, whatever. And I imagine it’s similar, can be similar in development. I’m sure that you could be a coder that just sits and says, yeah, I just do my projects and I’ve been sitting in the same chair for 15 years and I’m cool with that. And but again, I don’t think that’s our audience here. I don’t think those people are listening to this podcast because, to your point, that’s a job. It’s not the profession. It’s not someone who’s looking to say, what’s the next level? Because you can coast for a long time. Legacy stuff sticks around for a very, very long time. If all you know is VB6, I guarantee there are plenty of jobs for you. You just have to figure out where they are. That’s all I’m going to say about that. Some people listening will get the joke.

David: [00:37:28] And other people will look at you and cry.

Matty: [00:37:31] Yes. Well, that being said, okay, so if we look at DevOps from a, if we say it’s mostly a collaboration thing, and I kind of alluded to what I wanted you guys on the show to talk about, which is to say, how can a dev, someone whose title is dev, I’m an app dev, how can they work better in a DevOps collaborative environment with the operational people? What advice, what two cents might you have?

Dan: [00:38:00] I guess I’ll jump on that one since I’m a dev. I think one thing that I would say would be a really big takeaway, and I think that I’ve definitely experienced this more, is actually just kind of ending off what we were just talking about, is like Matt, you said about corporate culture, I think is a really good example of that where you can do the same thing for 20 years and you’ll work on the same systems, and they’ll be affecting you for your entire career there. But you’re right, you can get by, and coming from kind of like the more startup-y side myself, and also I’ve done like the one-man IT show where you have a little bit more freedom, that is definitely the people I think that are going to be more focused on this podcast. And I think that’s awesome. And what I was going to get at was, it’s all about a team effort, kind of like even like what we’re doing right now. We’re essentially kind of working together here to bring a message and talk to a certain group of people. And it’s the same thing as that is I’ve had a lot of points where, yes, I’m doing an app, I’m developing it, I’m thinking code, I don’t even speak any other language but code right now, but there is a point where, like you said, I can’t just hand it off and say, make it work on the server. It doesn’t work like that. It is a team effort. I’ve learned very much so, especially at my current job, that I can get the greatest app in the world done, but if I can’t get it out there and it’s not working or it’s not functioning or it doesn’t make it past this line of servers that we have to get through in order to get to production, then you’re never going to get anything out to market. That’s why I think it’s really important to know the value of both roles. I feel like the DevOps side really, or TechOps, really suffers this a lot in a lot of places is that it’s almost like because it’s that last leg going out that, like you said, the blame can end up on you guys. That isn’t how it is. That’s why it really needs to become a lot more of a tight-knit team atmosphere where it’s not, okay, I’m done, here, take it. It’s, here’s my portion, how is this going to work for you? What should I do? Is something missing? And that communication is really what makes it key, I think. And we’re technical people as it is, even at the base level. Even if you don’t have those fundamentals we talked about, open that communication line up and you’ll make things, you’ll connect on things much better than you probably ever thought, even if you’ve had a hard time in the past. At least that’s been my experience as a dev.

Matty: [00:40:06] Let me ask you this, would it occur to you, and if it wouldn’t, I’m going to challenge you and any developer who’s listening. Next time you’re in your stand-up and there’s stickies on the board and there’s something and your sysadmin or your tech ops person, or to be quite frank, it could be a tester. Sometimes it gets harder, I think, because you can’t do what they do because it’s silly to have them, you know, you can’t test your own stuff. I mean, you could test somebody else’s. I guess what I’m getting at is I would challenge developers to pull a task off the board that’s not a dev task.

Dan: [00:40:45] Absolutely.

Matty: [00:40:45] I mean, don’t pull the one off the board that says, re-architect security architecture for the entire domain, but pull the one off that says, hey, we need to get a box built, and maybe go to tech ops and say, hey, can I help you with this? I’ve got some cycles. And the thing is, you never do. Everybody’s super busy, and I know when I brought this up, they’re like, oh, well, I’ve got so much to do. Well, everybody does, and I would love to have people try that and let us know. Give us some feedback. Tweet at us or send us a note, comment on the post, and let us know if you’ve given this a try in your next couple stand-ups and what the reaction has been to trying it. That’s my challenge.

Dan: [00:41:24] I will take that challenge on, Matt.

David: [00:41:27] What’s a stand-up?

Dan: [00:41:33] The only last thing I would mention just to what you just said would be, even like I think you said about being busy. Everybody’s busy. Everybody’s got work. Everybody’s doing things. But if, again, at that root level, if you really care about what you do and you know the value of, like you said, picking up one of those tasks off the board and say taking something off, like you said, I’m not going to completely rebuild the entire setup for whatever it is over there, but taking those smaller ones. And I believe we do something similar to that where I work at Apartments, and it’s that when we set up our sandbox environments, it wasn’t, hey tech guys, can you come over and set this up for me? It was, get your applications running, set things up, and then we’ll talk about meeting in the middle when we go to the next stage after your sandbox environment. So again, I very much so say I’ll take that challenge, and I would say the same thing as Trevor’s is to be willing to do something like that. And even more so, again, going back to just be willing to talk to them because, to be honest, the people that I’ve talked to that are most into the thing that they do, meaning loving what they do, I’ve never had a problem pulling them away from their screen to say, yeah, I would love to show you this, or let me show you how this works.

Matty: [00:42:41] I think sysadmins mostly like to show you how this doesn’t work.

Dan: [00:42:44] Or that too.

Matty: [00:42:49] Trevor, I’d ask you your thoughts on this, although I know you’re already kind of doing this by default.

Trevor: [00:42:54] Yeah, that’s, I mean, that’s, where I work, that’s kind of, I kind of did that from the very beginning of the project I’m on right now. It was a matter of, we got this project coming down the line. Oh, well, somebody needs to put together the machines we’re going to use to do it. So might as well be me because nobody else is going to volunteer to do it. So that’s how we got, we did some testing to see if we’re going to do AWS, we wound up choosing Azure, we built some VMs and got our whole development environment set up that way. But, there’s a lot of, when the project started, we actually had an operations guy at the company on some level. He was kind of more of a jack of all trades than necessarily an ops person, but there was definitely well-received questions when I asked questions. They were really answered, and it would go both ways. I would ask him a question and he would ask me a question like, oh, well, if you’re gonna go ahead and use IIS, well, then what are you gonna use to deploy it? And that brought up the conversation of, well, how are we gonna set up Web Deploy? And so, did I just drop off? Because everybody seems to—

David: [00:44:12] Oh, no, just, we’re just hanging on to your every word.

Matty: [00:44:14] We’re just being insightful for a change. We’re not used to it. It’s blowing our minds, Trevor.

Dan: [00:44:20] Trevor, I think you said something that kinda goes back to, again, that thought process that we go through. It’s very much so from the product owner level, just speaking to one way that I know it, to getting to production with a finalized product and getting to market, it’s always thought of as very much so a straight line. But I think what you said is that while we may work in a straight line, or at least that’s the idea, there’s so many circles in between that has to go back and forth. And for developers and DevOps to be able to go back and forth, and so many other roles, within a company, especially a larger company especially, that’s really how it needs to be. Is yes, we’re going from A to B, but there’s gonna be a lot of in-between circles and off the path and on the path that has to happen. That’s why, like I said, that communication is so important. So I absolutely commend you for doing that and taking on a task like that, because I can’t say I know many developers that are ready to jump on any kind of system admin work of any sort.

Trevor: [00:45:06] It’s fun. It’s different. As long as I don’t have another big coding task to do, I’m more than happy to do the system work.

Matty: [00:45:17] That’s great.

Trevor: [00:45:19] I, given the choice, I will write software as opposed to put it together, so to speak.

Matty: [00:45:25] As opposed to make it work. As opposed to get the pager. Let me ask one final question of the panel, and then we’re gonna be probably heading into our checkouts and wrapping it up as we’re coming close to the top of the hour. So my final question is, I know we’ve talked about how the role of the developer has evolved over time. We’ve talked about what we kind of look at and things like that. And I’d like to know just from you personally what you’re looking at. I mean, this is the beginning of the year and we’re starting a new year. So what’s your DevOps resolution? I’m putting you guys on the spot. I’m gonna put me and Trevor on the spot too because we aren’t prepared for it neither. So we’ll let the panel go first. Tell me your DevOps resolution for 2014. And the first person who makes like a 1024 by 800 joke is just off the podcast.

Dan: [00:46:21] Go ahead, David, it’s all you.

David: [00:46:26] Now see, that was my Facebook status a couple of days ago for some reason. Actually, I think it was, I don’t have any specific resolutions about DevOps because Matt’s here and I don’t have to think about it anymore. So my resolution is to think about DevOps when Matt’s not in the room, just to keep fresh.

Matty: [00:46:58] Keep the flame alive. I’ll go ahead and jump in on mine. I think my DevOps resolution for 2014 is to become more aware. I’m gonna, my resolution is to write some code, some code that isn’t some PowerShell config script or some Chef recipes or something. But my goal is to write some code for something that does some shit, and I’m gonna let David deploy it, and he can write it. That’s my resolution for 2014.

David: [00:47:35] So, dude, I was deploying things when you were in diapers.

Dan: [00:47:41] That’s probably true for me. I really don’t think it’ll work. I guess I’ll jump in back to devs. Yeah, that is kind of on the spot, but you know what? Since I’m working in startup world right now, my side stuff outside of 9 to 5, I have to be doing some DevOps work that I’ve never done before. I’ll be honest, I wouldn’t mind by at least the later half of this year to say that I’m not #anube, because I completely consider myself just entry-level in the DevOps world. You’re like, oh yeah, buzzwords, I know them all. But then, tell me to go set this up, and I guarantee I’m going to be tweeting you for questions and answers right away. So my goal is definitely to really take a big step forward on the DevOps side, especially in relation to the work that I’m doing, which is, right now I’m doing Node.js, which is completely different than anything I’ve ever dealt with as far as how threading works and performance and stuff. So I am hoping that I can come back here and feel much more DevOps-y next time versus developer.

Matty: [00:48:39] So we’ll have to make sure that Dan is on our December 2014 podcast.

Trevor: [00:48:45] I was going to say the same thing.

Matty: [00:48:46] I’m also going to resolve next year that if someone’s on our fucking podcast wearing a pair of Google Glass, it doesn’t take me 45 minutes to notice it.

Trevor: [00:48:57] That was the first thing I noticed when he came on.

Matty: [00:48:58] I didn’t even notice it. I’m sitting here and I’m like, all of a sudden as he’s talking, I’m like, holy shit, he’s got Google Glass.

Trevor: [00:49:04] I’m over here being jealous the whole time.

Dan: [00:49:06] I will tell you, there’s only 2 types of looks you get with these. 80% of people don’t want to look at you because they think you’re recording you or you have an eye problem, and then the other 20% have to talk to you because it’s so weird what’s on your face. So it’s an interesting experience.

David: [00:49:20] Matt, I’m afraid you probably have missed a number of things in this podcast.

Matty: [00:49:25] That’s good. All right, Trevor, what’s your resolution for 2014?

Trevor: [00:49:29] Well, mine’s actually similar to yours but from the other side, which is actually interesting given our kind of dynamic of you being the ops guy and me being the dev guy. I want to be more present in my mind of when I’m doing ops-y things and not getting frustrated when I am doing code stuff, and I really need to give more consideration to the ops side.

Matty: [00:49:51] I know exactly how you can do this. You can now be in charge of the server that hosts the rest of DevOps.

Trevor: [00:49:56] Cool.

Matty: [00:49:57] Although, you can help me write the Chef recipe I’m working on to keep it running.

Trevor: [00:50:01] Cool. I wanted, I was actually, I wanted to learn some Chef since we started talking about it, so.

Matty: [00:50:05] Chef is sweet. We’re gonna, I cannot wait. We are gonna so have a config management episode, and it’s going to just rock. So stay tuned. I don’t know when it’s going to be, but it’ll be soon. So we’re going to thank our panelists, and we’re going to thank them by moving on to the final part of the episode, which is, we call it the checkout, where we’re going to tell you something cool that we think you should check out. And it’s not necessarily tech-related. It could be a TV show, a beer, a tech tool, or something. I’ll go ahead and go first. My 2 items that I have for checkouts, one of them, and I’ll put a link in the show notes, is there is a video going around. I would call it viral, but that word is stupid. And it’s this 6-year-old kid just railing on Welcome to the Jungle by Guns N’ Roses on the drums. It is amazing. It’s quite possible that you’ve all seen it. You have Facebook, you’ve probably seen it because everybody’s posted the freaking thing. But I’m going to put up a link in the show notes. And even if you have seen it, go watch it again because it just kicks ass. The other thing that I’m going to recommend is a tool called, this is on the Windows side, it’s called Chocolatey. It’s basically, imagine it as apt-get or yum for Windows. So it’s like a package manager. And you combine it with a tool called BoxStarter. Really neat. You write these gists in GitHub that basically say, here’s the tools that I want. So it’s great for rebuilding your developer workstation just to get everything down the way you want it. You could use it for configuring VMs if you want, although I would probably use something different for something more robust. It’s kind of a one-time run tool, but we are now big fans of Chocolatey around here. So Trevor, what do you got?

Trevor: [00:51:53] I got a couple things, and I was really worried you’re going to steal it from me because we were talking about it earlier. But there’s a really good article, given Matt Smith’s departure from Doctor Who, about the, the article’s called The Captain Kirk Problem: How Doctor Who Betrayed Matt Smith. And it really kind of hits the nail on the head about why I was frustrated with the last 3 seasons of Doctor Who.

David: [00:52:18] It’s not Doctor Who as an institution, it’s one guy. Yep.

Trevor: [00:52:25] And he writes such good single episodes. When you put him in a box, Moffat can write some really interesting stuff. But if you give him control over the whole series, and my second checkout is I got Jen the Game of Thrones cookbook for Christmas, and it is just delicious. We made a pork pie from the Wall. The food that the recipes create is wonderful. We made the medieval pork pie last night and bacon bean soup and it was fantastic. Oh, it was so good.

Matty: [00:53:05] David, your checkouts?

David: [00:53:09] There we go. Yeah, we were talking about, well, Dan, was it you who mentioned the book Code that you’re reading? Yes. Here’s another one. I keep this actually by my desk.

Trevor: [00:53:18] Oh, I have a copy of that.

David: [00:53:20] Where is my, I can’t see where it’s at. You can see it. There you go. Got the, okay. So this is essentially, Robert Martin has given, it’s just the basics of how to write good code. This would be what I would tell people to read today. Back years ago, it was Code Complete, which is really the book that introduced me to construction and software construction as a concept. That, and this is a really good modern version of that book. I think both of them are important, but a guy named Dave Codus turned me on to this book, and I absolutely recommend this. Clean Code by Bob Martin.

Dan: [00:54:14] Okay, all right.

Matty: [00:54:14] And that brings us to Dan.

Dan: [00:54:16] So I’m feeling kind of on the spot here. I wasn’t ready for this one, so I will give you something.

Matty: [00:54:20] If it makes you feel any better, nobody ever is, especially the hosts.

Dan: [00:54:24] I do have one, and maybe I’m really late to the party on this one. I just started switching over to all ebooks for everything, you know, Kindle. I use the Kindle app, and I decided to hop on Amazon, and kind of a cool tidbit, and I know there’s plenty of free books out there, but I actually hit Amazon set the price from low to high specifically in the Kindle Store, and I started searching for code books and all sorts of other learning fundamental stuff, especially computer science and actually one DevOps. I apologize, I don’t have the title on me. But there’s like an absolute multitude of free resources specifically in ebook form. I know you could Google for just about anything, but finding a nice book that you, I was looking at the reviews, and it’s nice to find a few. So I’ll actually try and find some titles and send them to Matt. But trust me, hit up the Amazon Kindle Store and hit the free section. There is just an insane amount of free resources out there for great material learning.

Matty: [00:55:11] Great, thanks. Big fan of the ebooks. That brings us to a close. I’d like to thank our special panel guests, David Braverman and Daniel DeAngelo, who’ve joined us to talk about what puts the dev in the dev-de-dev-deops. As usual, this is Matt Stratton from Chicago signing off, and don’t forget to follow us on Twitter at @DevOpsTalk. Arrested DevOps, or check us out online, or on the line at www.arresteddevops.com. And we’ll see you guys in a couple weeks.

Trevor: [00:55:45] Take care. Thank you.