 Thanks for coming everybody and thanks to WordCamp for having me here. So as you probably saw from the thing, and I guess a lot of you are interested in this topic, call this talk the back end is dead. And I just want to briefly ask you guys a question. How many of you guys are developers? Or how many of everyone is developer? I'm trying to reduce my gendered language here. Okay, how many of you consider yourselves to be front end developers? You're probably like, yeah, when you saw this title topic, right? How many of you consider yourselves to be back end developers? And then you're like, I want to see what she has to say about this, right? So how many of you consider yourselves to be full stack developers? Sweet, sweet. All right, so I'm going to start off with a little bit of story time. My title is full stack developer, but I primarily do what we would consider back end work. And there's something about me, I guess maybe because I primarily do back end work that sort of seeks to do refactors all the time, right? So at O3 World we do work for clients and it's not always appropriate or cost effective or time effective to propose a refactor for any sort of website. So I was looking around for an opportunity to refactor something because that is sort of how my mind works and I was like, let me refactor how I think a little bit. And so I wanted to, I looked around and especially in the projects that I was working more closely on and it seemed like the traditional lines and how we would divide up how it would work were a little bit blurrier than sort of just front end development and back end development. And how can I sort of best figure out how to delegate tasks when it comes to responsibilities for a project and how can I help leverage the strengths of everyone on my team? So I thought, why on earth are we using these distinctions to, continuing to use these distinctions to define ourselves? So that's why I call this talk. So when companies are hiring and agencies are hiring and they post job listings for developers, they're not hiring, if they're not hiring for a specific language say PHP or Ruby or a specific platform like Rails or Groovy or Grails, they're hiring for, they usually falls into three categories. I usually have front end developers, back end developers and full stack developers. So using these categories can be a great way to find talent but I feel like it can be potentially limiting. So this is pretty much on, I'm going to preface this by saying I didn't do a ton of research into this. This was a thought experiment that I used to play out how I relate to the other developers on my team but it seems to be working so far. So what I'm putting forward is a new way to think about the stack when you're hiring developer talent. So I hope that this will enable you to truly hire for your needs and assess your business needs to leverage the wide range of talents on your existing development teams and then to give developers more opportunities to develop professionally by introducing them to previously unfamiliar workflows or concepts. Does that sound good? So let's talk about the new stack. So let's replace front end, back end and full stack with the data layer, the business logic layer, the presentation layer and the operations layer. So if you use these four layers to define your stack it might be more difficult to hire someone who is quote unquote a full stack developer but if you hire for several people who can cover each element of this stack you'll have more of your workflow covered than if you hired off a traditional stack paradigm. So if you're lucky enough to find someone who actually does cover all four parts of the stack then you got yourself a unicorn running in the clouds with rainbows coming out of its butt I guess. I just thought that was a really cool gift. So let's talk about the stack a little bit. So the data layer. So that's mostly self-explanatory but I will dive a little bit into this. So you can think of it as someone who is managing data or someone who is actually making an API or microservice that is connected directly to a data layer. A data layer developer would be able to build or organize data for an application or analyze and optimize relationships for the data. Ideally, maybe if you were going to try to shoot the moon you'd want them to be able to write an ORM or a microservice to connect to the data or actually just sort of own the data stack when it comes to a project. Does that make sense? Yeah? All right. So then there's the business logic layer. The business logic layer, I should put business in parentheses because not everyone, I personally don't like the phrase business logic but it's kind of the algorithmic layer. I think you're kind of getting my drift here. This is the meat and potatoes, so to speak. So it's how a site works. So I think traditionally people would think about this as back-end work, right? Something if there's some really complicated number crunching or data transformation or something of that nature or even if it's a more complicated version of CRUD, you would say some of that stuff would sit on the server side and you would think of server side, client side would be your clear delineation between a front-end and back-end. But I think that as things are shifting and as APIs are becoming more available, more of the logic is actually sitting on the client side. So if someone who's been traditionally what we're calling a back-end developer is developing applications that where they're mostly using client side logic or a framework like Angular or React, then are they still a back-end developer? Does that distinction even make sense anymore? So in a WordPress shop, this could be someone who creates new plugins. This could be someone who manages a series of plugins who creates custom plugins. It really varies. It could be someone who does really heavy JavaScript logic. It could really vary. So this is the part where you think, okay, actually someone who is traditionally a front-end developer is actually working on a pretty good bit of business logic for an application more so than a traditional back-end developer would. The distinction between server side and client side seems to be, you know, those walls are crumbling, seem to be crumbling a little bit more. So then there's the presentation layer. I always found that at least in the past the presentation layer, you know, people wouldn't think about the presentation layer specifically. It was all lumped into front-end. So you'd get everything that basically sat on the client, like everything that you see in front of you is all, you know, how it works is the back-end and what you see is the front-end. And that's not necessarily clear either. The presentation layer is often, especially now, a lot more complicated than it used to be. So, you know, the presentation layer, it's the stuff you see. But it's a bit more, it's not just the stuff you see, but it's how the stuff you see works, how you interact with the stuff you see, or not even see if you're not visually inclined, if you are, it's the stuff that you're interacting with, those things that are actually sort of bringing the application to life for a user. So you're maybe responsible for converting all those amazing web assets from the designer. In an agile designer development shop, shout out to the three world right here in Philadelphia, you know, a presentation layer developer may previously been a designer, or they may not have, but they speak the language of a designer and they can, and they can, you know, interact with the designer very quickly, iterate on things, especially when it comes to developing a web application. So, you know, bonus points to the person who's a specialist in accessibility and keeps non-computer web connected devices in mind during the development process. So, and then there's a layer that's near and dear to my heart, the operations layer. So, that's a lot of text, isn't it? So it's not traditionally thought of as a part of the stack, but it's an important one. I think people will hire support positions and hire, like a DevOps positions very much separately from who they hire, you know, from when they're hiring someone who is going to be doing the rest of the development cycle. And I think you can, you're actually, you might be missing out on a little bit of an opportunity to cross train someone for that. You could, so, you know, if you have someone doing DevOps that's involved in the development process from its inception, you can avoid a couple pitfalls and headaches related to deployment. And chiefly the works for me syndrome, well, my local, you know, my local vagrant box WordPress install, this works perfectly and it's like, actually, your client is using a different version of PHP and so that's why everything is all jacked up when you try to deploy it, right? You know, the works for me syndrome, you avoid that stuff because the operations layer developer will actually think of that sort of thing ahead of time and actually understand what are the, what are your client's needs? What are your end users' needs? What are they, and sort of keep that into my development cycle and help steer the rest of the development of the application based on some of those things. So they're responsible for keeping an eye on site bills, test coverage, updates in patches of software and plugins, server hardening, security audits, deployment, workflow disaster recovery. So, you know, that would be the person who understands the WP Engine ecosystem or Pantheon, better than everyone else, and it can help optimize your project for the use of that in your environments. And some of those responsibilities are traditionally like a, you know, systems admin, but as platform as a service becomes more influential and grows in scope, someone, having someone on hand who sort of understands what all that is about can be incredibly useful. And that, you know, just because it's difficult to find someone who actually understands what it's like the day-to-day to be a developer and understands the operation side might be difficult, it doesn't mean that, you know, a position like that should go unfilled. Shout out to me. So, you know, some of you may be thinking, okay, well, where do I fit in in this paradigm? You know, and, you know, like me, you might fit into more than one category. And that's totally fair. Like, you know, I also probably fit into more than one of these categories. The lines are, even though I attempted in this thought experiment to make the lines more clear, that doesn't make them perfectly clear. You know, but I do think that it makes more sense to call myself a business logic operations developer than it does a full stack developer. Sorry, I'm just going through my notes here. So, you know, if you're into this paradigm at all, like, who do you hire, right? Well, you know, anyone you want, really. But, sorry, I love Gibson. I love Beyonce, so I had to do that. But you may not find, you may or may not like the specific reconfiguration of the stack, but I hope going forward that you'll do your best not to let titles and categories or even the languages that someone knows limit you and limit you, limit who you hire. So, you know, you could be missing out on finding a great fit in your organization if you're paying attention to what previous titles they held or what specific, what stacks, whether or not they are actually full stack or not. So, you know, I could have easily called this talk, the front end is dead. I could have called it, you know, how I learned to stop worrying and love hiring developers. I could have called it anything. But you catch my drift. I want to empower people to give a deeper read to a resume and cover letter when they're hiring people. Listen differently in interviews and take risks on people who may not be precisely who you had in mind because I think you will end up having a better team for it. So, this actually is. I left a lot of time for questions. So, you know, you can ski-dattle or if you have any questions, feel free to ask. No questions is a good thing, I hope. Does any of this make sense to you? Yes, you have a question. When you talked about the operations layer, I kind of thought you meant just like the day-to-day way that end users actually end up using it. Okay. Can you kind of speak to sort of where that fits in the stack of like, well, you know, Elaine in HR actually uses this application to XYZ? Right, I think to me that would be a little bit more of the presentation layer because I think someone with like a developer with a strong UX and UI sort of bent would fit a little bit better in the presentation layer than the operations layer, but I see, I understand what you mean. I think that with the operations layer, I'm thinking more of DevOps, but, you know, that certainly, you know, again, you know, this is more of a thought experiment and in doing, and in thinking of developer, thinking of my team that way, you know, if we had projects where we had a lot of items left to work on, it was easy for me to say, oh, I know that this person, okay, maybe they've only worked in this language or done these sorts of things, but I know that they have a mindset and a way of thinking that they could easily solve this problem regardless of whether or not it was the issue, the bug, or the new feature was on the client side or the server side. Yes. Hi. So I wanted to know if you could comment for a moment on how you could apply this paradigm to actual interview situations and how you can suss out these different things to match up what you need on your team with the probably miscellaneous skill set that the applicant has. Right. I would probably, excuse me, I would probably, you know, in asking them about specific projects that they've worked on, I would want them to go a little bit more in depth in terms of what their responsibilities were on the project, so if they were like, well, I handled all the client side, blah, blah, blah, for this site. I was like, well, what actually, is it a single page Angular app and you actually, you know, worked on converting all the data visualizations from like a bunch of a series of API calls to like some beautiful charts using D3. Sweet. And like, okay, then like, maybe you, maybe you should be working a little bit on the presentation layer and a little bit on the business logic layer, so, yes. Thank you very much for the energetic session and one thing I think that you have missed and I was also missing that was the Steve Harvey. There was no chief for that. Oh, no Steve Harvey give. Oh, goodness, yeah. I could have probably used some like family feud stuff but that's not the question. The question is all about, while we are mapping this paradigm onto our development, we come across sometimes with the trainings and the massive trainings, just like I hire a developer, say, for the front end, maybe you are UX and after a certain time, technologies change altogether and before that, those are working maybe on the HTML and CSS and gradually I have to move them towards some JavaScript frameworks and stuff like that. So, where we can accommodate the training and retraining and retraining stuff in the whole of this paradigm. Where can we accommodate the training in the paradigm? I think that that would be, you know, sort of a title shift, right? I mean, I think a lot of, like in the earlier part of the web, you know, JavaScript was used as it was, you know, expedient to delivering HTML and CSS, right? And now it's way more complicated. You have front end frameworks and things of that nature. But I think just, you know, using this classification allows someone to grow. I only thought of, you know, someone who could say, I only thought of myself as a front end developer. But now that I've learned Angular and actually learned how to you make, you know, or React or, you know, Ionic, I actually learn how to build the bits of an app that actually work or bits of a website that works as opposed to, you know, like some of the things that I, some of the static assets, some of the static things that I see, I can actually do a bit of interaction. So it would be a professional, you think of it as a professional development thing. So if they retrain, they would shift maybe from a front end developer from a presentation layer developer into a, say, a business logic developer or be a hybrid of the two. Yes. Most likely to be operations logic or across the board. Across the board. Like this is, oh, so, so I was asked where testing sort of fit in. And I would say that it fit in across the board. So, you know, I think testing is a responsibility of every developer on the team. You know, it's not just, you know, for the operations developer that may be testing the workflows, testing the development workflows or deployment workflows a little bit. That may be, you know, making sure that if they're using get or any other sort of version control system, making that that, making sure that that makes sense to how the rest of the team is working for, you know, someone who's mostly doing the presentation layer. You know, test, you know, there are, there are test suites for that. You know, there's karma. There's, you know, phantom if you want to automate some of this stuff, you know, for, you know, there are any other sort of unit testing for a business logic developer depending on, whether or not you're working on the client side or the server side of the business logic, you know, I would say it fits in everywhere. You know, there's, there are always, there's always a shortage of tests. So, yes. Yes. As a developer, how do you recommend that we focus on growing? If you're weak in part of the stack, do you recommend that we concentrate our efforts there or to deepen our strengths? I mean, I think that really, I think that really depends on, you know, whether or not you want to grow in that. I think sometimes that, I think this paradigm sort of gives you the ability to, like, focus in on what your strength is, but it also gives you the opportunity to grow a little bit, right? So, if you're a front-end developer in this, in original paradigm and just say, you know, you're, you're not as strong in the HTML and CSS, but you're very strong in JavaScript, then, you know, you could either, you know, build up your skills in HTML and CSS or, you know, try to work on more server-side JavaScript if that is something that you're, that you're doing as well. So, I mean, I would say that, you know, training yourself and, you know, there are a lot of amazing tools out there and I think, you know, this will allow some, from room to growth, room for growth as like business needs change because that, I hope that answered your question. Yeah, thanks. I guess you guys are going to get out early then. Thank you so much for your time.