2:35 - What types of teams have we worked on?8:30 - Deciding what kind of team to hire14:25 - Issues and concerns with working on back end/front end teams19:00 - Troubleshooting21:00 - Measuring success with split and cross-functional teams25:35 - Benefits of full-stack teams28:45 - Hiring full-stack, front end, and back end31:05 - Hiring experts and specialists 34:45 - Mobile teams36:05 - Viability of teams within React and Angular42:55 - The future of web development

Picks:

Doctor Strange (Joe)Hacksaw Ridge (Joe)Major League Soccer finals (Joe)React Native Radio(Charles)Ignite - Infinite Red (Charles)Frontend Masters(Charles)

Transcript

Charles:        Hey everybody and welcome to the Adventures in Angular show. This week on our panel we have Joe Eames.Joe:               Hey there.Charles:        I’m Charles Maxwood from Devchat.tv. It looks like everybody else is travelling this week so it’s just the two of us Joe.Joe:               “Just the two of us.” [Singing] I feel like Lukas when I’m singing. I’m like invoking the spirit of Luke. I’m channeling Lukas.Charles:        There we go.Joe:               But thankfully everybody gets to important people.Charles:        That’s right.Joe:               It’s just the two of us, maybe more people will recognize me. Ever tell you about the time I had a conversation with a guy for five minutes about JavaScript Jabber. It took five minutes before he realized I was on the show.Charles:        Yeah, you told me about that. That’s really funny.Joe:               We need more episodes where it’s just you and me so that my [00:08:37] can fill the airways.Charles:        It’s funny because I have people that listen to multiple of these shows that I’m on. I’ll go to conferences and I’ll be standing in line for the lunch behind people and then they’ll stop and they’ll turn around like, “It’s him. I heard that voice.” But they don’t recognize me on site.Joe:               What are we going to talk about today?Charles:        Well basically it was an idea that I had discussed a little bit with a few other people and that is whether or not you should go with front-end and back-end teams or basically dividing up by technology or if you should work across functional teams where essentially you have a team that’s in charge of a certain set of functionality or a team that works across the entire application regardless of what layer it’s on. I’m curious about which kinds of teams have you worked on. Have you worked on both, primarily one or the other?Joe:               We talked about this a little bit before that I did service side before I came to client side. When I was at service side for about 1999 until 2010, I was a full-stack developer. It was about 2010 that I switched entirely as client side developer. Until that point I’ve only been doing full-stack. I think this is probably fairly true with few rare cases. That if you’re doing web development you only have full-stack. There’s no specialist, no front-end, only developers. Everybody was doing both side. You certainly would have the situation where one guy would specialize more on the team or a couple of guys on the team might be more specialized. I certainly saw that a lot with CSS. I have the guys that actually knew the CSS and everybody’s going to them, “Fix this, fix that.” I don’t know. It’s something genetic that allow those people to understand the myriad crap in CSS. Then everybody else tend to be full-stacking.You might have the one or two smart guys that knew JavaScript a little bit better than anybody else but certainly the start of that time period of 2000 there wasn’t much JavaScript to be done. It was [00:11:04] of validation here and there. When you say full-stack, you really weren’t doing much on the client side coding. But over the next ten years, you’d get more and more client side coding but you’d rarely saw a shop where there was so much client side coding. It’s JavaScript coding that lead onto people began specializing.Even when Knockout came out which is [00:11:27] where you actually had something on the client side beyond just JQuery. JQuery was 05 I think but actually did some bindings so you could consider this to be a data visualization fully client side piece. Even at that point you still didn’t do so much on the client side. It just wasn’t a thing. Definitely I have a lot of experience with the full-stack and once I switched and went to client side I did only client side so at that point of course, I just worked on places where they had a client side team or at least a set of client side developers and then they have back-end developers. Definitely had a fair amount of experience of both.Charles:        It’s funny that you’re talking about this because my experience is mostly the same. I got into Ruby on Rails. I did something like PHP stuff and some jQuery stuff when I was in college just because a friend of mine was doing it. And it looked cool because I could build websites with database on the back-end. I didn’t get serious about programming until after I graduated. I was working in Ruby on Rails. Even then Rails had a couple of nice hooks into jQuery and then if you have to manipulate the DOM you did some jQuery stuff.My first framework, if you can call it that, was backbone. Again, it was just part of the deal with working in Rails and having a semi complicated front-end. But even then it was just a nice way to organize the code. I didn’t use it for much more than that.The last full time job I had which was about six years ago, we actually had parts of the front-end, jQuery and parts of the front-end were flash. Basically there were six of us on the team and three of us worked in Rails and three of us worked in Flex. I was one of the Rails guy. I was a back-end guy. Once I went freelance I went back to the full-stack realm and did that. There were definitely trade-offs between the two as far as I could see. I thought, “Oh, this would be really interesting.” Because I get people asking me occasionally. It’s like, “You do Rails and you do Angular so what’s the deal? Should we have separate teams because we’ve had pain with separating them but we’ve also had pain with not separating them.”Joe:               I think that we could look at some lessons from other languages now that you mentioned Flex and see what they’ve done in other cases and potentially use that as a cue. For example, with Flex I think it was very common that you had just some Flex developers and then you have some back-end developers.Charles:        Right, because it has its ecosystem.Joe:               It’s an ecosystem. It’s a language. It was very different. I think one of the reasons why we see a lot more of the full-stack developers is probably two full. One, if you got a small company with just a couple of guys, obviously it just doesn’t make sense. If you got three people and then, “Well, let’s make this one guy the front-end guy. The other two guys the back-end guys.” It probably is too inefficient.Charles:        It’s kind of silly to do it that way.Joe:               Obviously I think the first guideline that should come out of this is under a certain size of problem it doesn’t make sense. This could very base on skill set. If you hire a front-end only guy and you’re back-end doesn’t say Java and he’s never done any Java and you got a Java guy who’s a Java expert but doesn’t necessarily want to do much Java or whether he does or he doesn’t might make sense just have the Java guy do all the Java and the front-end guy do only work on the front-end. If you have a lot more Java work than you have front-end work, then even at that case people are going to have to do what they think.For the small team size, I think it’s a hard sell. But again looking at Flex or other similar topics like Silverlight is another example of totally different front-end ecosystem although you at least used the same tool if you’re doing sort of like you’re probably doing .Net in which case you’re still using visual studio. In those cases, I think especially with Flex, the saw this as being so different that the idea of it’s the same developer is going to do both Java is just didn’t necessarily seem natural. Whereas what happened with the world of the general web is we did everything on the service side, both Rails and ASP.net had this hey we’re adding more and more features on the server side to let your client side be more responsive and have a better user experience. With .Net they called it partials where you could say, “Hey, I only want to update this part of the page.” And you’d make a request, you wouldn’t make a full page refresh anymore, you just have a part of the page which is HTML get updated. And Rails has the same features.Charles:        Rails has turbolinks which does the same thing.Joe:               The server side kept pushing more and more client side functionality onto itself. Your server side developers which is all you had before as the web demanded more and more interactivity, more usability, a better user experience then the features were getting pushed into the service side frameworks so you didn’t say, “Oh wow, in order to do this, we got to have an entirely skillset and a new ecosystem doing something.” Instead, you could just say, “Well the same guys that are already working on the service side and just producing HTML, well now they can make it produce actual functionality and do all the functionality on the server side. And the server side language but [00:17:39].” Then at some point that ended. I think this is when Ember and Angular started getting popular and Backbone. People are saying, “Hey, we could really do some stuff with just JavaScript. Instead of having this server side send this big HTML chunks down, let’s allow somebody to write in JavaScript and [00:18:01] or JSON.” Ultimately to become JSON but let’s just have an API that we call from the client side. I love to point this out to everybody to who doesn’t know this but our entire modern web was enabled by Microsoft inventing SHR back in 1997 or 1998 or something.Charles:        Back when there was still the Evil Empire.Joe:               Right. Back when there’s still the Evil Empire and now there are not quite so much that. I think Apple is trying to take over that spot but I digress.Charles:        There’s a [00:18:40] to open?Joe:               Yeah. Let’s go back and review some comments about DHH from a previous episode. You had that natural progression right? You didn’t have to worry about it’s an entirely different set of skills.Charles:        The thing that’s funny is the way that you’re describing this is exactly how I grew into this. My first job as a Rails developer full time, we use JQuery and Scriptaculous. Rails had basically wrappers around all that stuff so that you could write it in the server side framework and it would just plug all the JavaScript in the places to manipulate the way you wanted.Time went on, more and more people were doing things where we had SproutCore and some of these that were going all the way to build basically what looks like a desktop application in the browser. It’ll manage all of the stuff. SproutCore and Ember, I hear some people say they merged and I hear other people say that SproutCore 2.0 just sort of became Ember but whatever the case we started getting these frameworks that gave us all of these capabilities and it started making less sense to have your back-end framework have so much control and say in your front-end framework if you just pass the data up and you could do it all on its own.Joe:               Right.Charles:        I’m wondering though because right in the middle of this movement was when I was working on one of those teams that was not cross functional and we had that flash front-end than the Rails back-end. We did try integrating, by the way. There were definitely some growing pains with that. I’m curious, now that we're in this modern era, I think you’ve worked on a front-end team more recently than I’ve worked on exclusively front-end or back-end team, did you feel like that made more sense? Because back when we were doing it, that boundary between the front-end and the back-end, they’re, “Okay here’s the API. Here’s how Flex or Flash expects to talk to the server. Oh, crap there’s something that’s quite not right here.” That happen a lot. Or “We’re trying to move ahead with this feature why isn’t it done?” Oh well the back-end’s been done for two weeks. In the front-end, they’ve been working on some other thing. We definitely had those pains. They wanted to be able to solve some of that by having everybody able to work on any section of the code so that if there was a problem with the back-end talking to the front-end well Chuck knows Flex and Ruby and so Chuck can do both ends of the thing.Joe:               Right.Charles:        In you experience was it a Domo where you spent most of your time?Joe:               I had a job right before that where I was the front-end guy but if they had separate teams then I was only person on the front-end team so it was Domo that was my first job. It was like a very specific back-end team and a front-end team.Charles:        Did you run into those issues and how did you guys solve it then?Joe:               I don’t recall running into those issues as far as any kind of dissonance between the two teams. I have these memories of, “We need to get this API changed.” It was sometimes a hassle. It could be a lot of almost hoops to jump through, almost bureaucracy but there were some reasons for that. The application was so dang big that if an API endpoint was changed it might be called by multiple places so you always had to be careful about stuff like that. Then you got the, “Well, do we just create one more new API endpoint that’s a slight variation of this existing one?” That could be problematic too so there’s a lot of challenges in those two things.I don’t recall the dissonance ever being extreme. We did have some front-end guys that could at least go in and write a new endpoint. It was all in Java and I’ve done that. That one is very similar to Java but I’d never bother getting my machine set up to even do Java and I don’t really want to either, at the time. I wanted to just do front-end. We had a couple of guys who could just at least add a new endpoint. They could go in and just say, “Hey, I know how to gather the right data and a new endpoint that produces the right thing.” We do a little bit of that but when it came to the real business subject on the back-end, we weren’t allowed to touch it. It had to be the back-end team that dealt with that. Things just worked out. I think again, a lot of it is the fact that it’s such a large company size. We had almost 20 people on the front-end and probably 15 people on the back-end so it wasn’t like anything moved super quick anyway.Charles:        When I was working on that team there were six of us and then our manager. If we really needed something then we could go to the front-end team but generally it was them coming to us and saying, “I’m trying to build this feature and I need this endpoint.” And then there were other areas in the application that were essentially Vanilla Rails app with jQuery and stuff on the front-end. We did most of that. It was this interesting split. “Oh well, they told us they needed this.” And then they still haven’t finished their end of things.Joe:               It can be hard because you can give them what you need and they’re going to make it and then you realize either you’ve had something wrong or they got something wrong or there was some problem in the communication of it. The point is you get the wrong thing out and now it’s like, “Well, I need an adjustment. Can you get that adjustment done quick?” Or are you completely blocked in your development for a day or two until somebody get around to making that change again to update it to exactly what you need out of that API endpoint.Charles:        Yeah, exactly.Joe:               Dealing with that can be hard. It can be a huge hassle. I think that comes down, once again, to the teams. How you orient them. One of the things that we did and found to work very well was you know, you have two or three front-end guys working on a specific feature and there’ll be one specific back-end guys assigned to them into that same feature. The front-end guys team might be working on multiple features at the same time and the back-end guy might be working on multiple features at the same time but at least he knew where to go so it’s like, “Okay, you need this endpoint. You go to that guy. You’d get it done.” Or “If something’s wrong, you go back to that same guy and he’d make the change.” Then the developers themselves could negotiate the priorities and be like, “Hey, I know that you’re moved on to doing something else. You’re in the middle of something else right now but I’m blocked and I need this changed. I’m pretty sure it’s small.” Then that back-end guy can make the determination of, “Can I be interrupted and switch task? Is it really small enough to do? Is it so important to unblock that person that it’s okay for me to be interrupted?” as long as the people work well together then that flows really well. We found that that flowed really well for us.Charles:        I can definitely see that. I think what it really boils down to is what is the cost to that communication. What is the cost when it breaks down? What is the cost when it’s actually working well? We’re using all of our systems to make that it’s happening as we need it to. From there you can move along and actually figure out, “Okay, it costs this much and that’s okay because training is more expensive.” Or “It costs this much and that’s unacceptable because we can’t move fast enough to keep ahead of our competition or we can’t move fast enough to make the CEO happy. I’m wondering, did you measure that kind of thing or was it just kind of a gut feel?Joe:               No.Charles:        People get frustrated so let’s talk about it.Joe:               We had no measurements. We went so big that we would start doing bureaucratic measurements and stuff like that. We were constantly having planning meetings. We talked about, “Alright, this hasn’t gone very well. Every time I go over to get this thing done that person is too busy in the back-end to get done what I need to get done or is never there.” But certainly we just covered a few things.Physical proximity matters but you don’t want them too close. Because that back-end guy needs to be part of the back-end team so he sat with the back-end guys, the front-end guy sat with the front-end guys. But as long as it was a very short walk. We were 50ft away from each other probably. He might as well have been sitting next to us. But if you talk about different floors, different buildings, all of a sudden that could get very problematic.Virtual Teams sometimes actually feel closer than a guy down a floor. Because if he’s down a floor you might not spend enough time and energy putting together all the tools that make the whole virtual team thing work well. Because he’s just down a floor you can walk there but by the time you started doing that then it’s just too much time and it’s too much hassle and there’s too much effort. You don’t want to walk down there something done and you do and he’s out to lunch or he’s out at a meeting and then you’re really frustrated. Got to take the long walk back. Physical proximity definitely matters in that kind of a scenario.Charles:        In my experience with the split team, we were all in the same room so that really wasn’t a problem. Communication worked out pretty well as well. What it usually came down to was just how much of the work had to be done on the front-end, in Flex versus the back-end and Ruby and whether or not there were enough developers one way or the other to get it done.I’m curious too. Domo, did you have the same backlog they did? When you were doing planning was it all together or was it, “Okay we’re going to work on this on the front-end and you can work on whatever else you need on the back-end.”Joe:               I’m not sure. I’m not 100% sure. Our meetings were all completely separate from theirs. We would have a representative show up to our planning meetings because we would be assigning out task that required a back-end guy and we need to know can the back and guy get this done in a reasonable amount of time. Can he get to them in time? We needed to know all those things. So we have a representative come.Charles:        Right.Joe:               I’m pretty sure we had different backlogs. They had sets of task that had to do with purely the back-end that didn’t involve us at all. We wouldn’t have known about it at all and vice versa. We had plenty of task that were only about the front-end. Didn’t involve any services, any APIs. We do those without those guys ever being involved.Charles:        Yeah. That’s interesting. The company that I was working for that I keep talking about was Public Engines. They had a product crimereports.com. Their base is in Draper, Utah. Since we were all in the same room and effectively all on the same team, managed by the same manager, all of our meetings were held together and we share the backlog. In that case, even though we had separate responsibilities we did actually share a backlog and planning meetings and all that stuff. We were working a little bit more in lockstep with each other for a lot of the stuff. the communication and the tooling and the repository and everything else were all shared unless you [00:31:46]. It’s interesting to hear you talk about it where the two teams were basically completely isolated from each other. Not completely but to the point where you were working on different things than them. With us it was very focused around a feature. My task and somebody else’s task would mesh.Joe:               What is your gut feel? Which one is your preference?Charles:        I would have to say that I personally prefer working on teams where everybody is full-stack. The reason for that is that for the most part then everybody is on the same page. There’s no person that has a concern that the rest of the team doesn’t have. Then the other thing that’s nice about that is then those barriers between the front-end and the back-end as far as, “Does this service expose the right endpoint for the right thing so that the front-end can do its thing?” Instead, it’s always been nice for me when I’m building something with a front-end framework and Rails on the back-end to just be able to just seamlessly build both parts. Now that they’re going to talk nicely to each other because I’m managing both sides of the conversation.The other thing is that Rails really wasn’t set up well to talk to a Flash. Holding a gem that mostly worked. We were fiddling with it all the time to get it to do what we needed it to do. That’s probably colored by judgement.Joe:               It should have been the name of the gem, mostly works.Charles:        Yeah. I think that’s part of my experience. I’ve been on a few other teams where it seems like they had a couple of people that were mostly specialized on the front-end even if they were full-stack people. Even then they’d go do some arcane craft that nobody understood. Then somebody else would have to manage it because enough of those folks were on vacation. It just turned into a disaster. If you the expertise spread evenly across your team, then that works a lot better in my opinion though I will say that most of these teams had 20 or fewer programmers working in the entire application. I think if you get into a certain size, maybe it does makes sense to split it up.Joe:               In this day and age we are starting to see more people that come and their skill sets are front-end only. They’re only a front-end guy, are you going to make them start doing back-end work or you’re going to say, “We’re all full-stack developers except you only do front-end work.”Charles:        If I were hiring now I wouldn’t rule somebody out because they’re not full-stack but at the same time I would expect them to learn enough to be dangerous on the back-end.Joe:               Be dangerous. I think knowing nothing makes them the most dangerous.Charles:        Yeah.Joe:               No, probably not. Knowing a little is probably more dangerous.Charles:        I think the danger is mostly in the attitude. I think I know what I’m doing and so I’m just going to blaze ahead instead of actually asking for help preparing or something. Where would you go with it?Joe:               That’s a hard question to answer because my first thought was at least at the moment in my career I’d rather do the front-end work. There’s lots of cool stuff happening there. Back-end at the moment is kind of boring me.Charles:        You would want the job where they said you would do Express?Joe:               Right or maybe I would be okay with it so long as it was just minimal amount of my job. I think we do live in a funny time. It’s a good time certainly where you can pick and choose as a programmer and do what you want to do, within reason of course.One of my personal preference is giving me some biases to what I feel like is the best. If were to start up a Dev company and be building a web product and deciding, “Alright, am I going to have five back-end, five front-end or am I just going to have 10 full-stack?” I think I’d probably be on the side of the 10 full-stack. Like you said if they are more efficient because any guy can do any task then that’s probably better overall.Charles:        I will play devil’s advocate though with that and that is that it does pay to have experts.Joe:               I was talking about before. With a set up like that, you’ll tend to have the one or two guys that are the real experts and even if that means you got eight generalists and one true front-end expert and one true back-end expert. Obviously the experts can’t do all the work. They’re only going to be able to do a piece of it but they can solve a lot of the hard problems a lot quicker than somebody else could. Maybe the more generalists don’t know things quite as well and can’t write as nifty or can’t solve the problem as quick but the specialist can often then quickly solve a problem. I only thought that with CSS. One guy that really knew CSS that have a team of 15 is plenty.Charles:        Yeah. It’s like, “Come over here. Do your dark arts. Problem solved.” And yeah, you don’t have to call on him for another few days.Joe:               Right. I’ll leave chicken carcass for you to use in your rituals.Charles:        That’s right.Joe:               Just don’t involve me.Charles:        Yeah, do the blood sacrifice out back.Joe:               Right.Charles:        I definitely see that.Joe:               I would say though if I was talking about 40 Devs, I think I’d almost for sure feel differently. But again, it’s not likely that with 40 Devs you’ve got 40 people building the same product. There’s definitely a team size where it just gets too unreasonable even if it’s really all pieces of the same product, you start dividing up people into, “We’re doing this piece and they’re doing that piece.” Even if it’s like, “We’re the [00:38:44] piece and they’re the product piece and they’re the user piece.” You might have teams of only 10 or 20 and then you’re back to well it could totally work with a bunch of full-stack developers.Charles:        I have one other interesting thing with this. I know that this is an Angular show. It’s much more appropriate to talk about back-end and front-end teams but another client for a back-end is a mobile app. Generally, what I’ve seen with those is that they actually split them off into their own team, the mobile team.Joe:               Yup. It’s Flex all over again. It’s a totally different ecosystem, different skill set.Charles:        Right. Different concerns, vastly different concerns. Even more so then I think from front-end to back-end. Even though the concerns are different and the resource constraints are different. It’s just interesting. Does it make sense to have the specialists or not? I think this really just come down in some ways to I think we think of the front-end as in at least some ways an extension of the back-end. I’ve seen apps that really aren’t. It’s the angular app and the Rails app or the Express app and they’re completely separate and the one just knows how to talk to and authenticate against the other. With the mobile app, they’re not even served from the same resource. The apps already on the phone or and it just talks to the back-end. I don’t know if that’s a big enough difference to make you think oh yeah I definitely have a separate mobile team.Joe:               I do think that it’s obvious that it’s just [00:40:42]. It’s hard to make it work the other way. Wouldn’t you agree?Charles:        I do agree. I’ve seen development teams that they have the mobile team part of their web team but effectively then what they’re doing is they’re doing something like Ionic Cordova or something like that where there are effectively web developers anyway.Joe:               Right.Charles:        “Oh, we have a desktop app but it’s electron so were effectively writing a web app that runs on its own little container instead of a fully pledged browser with Chrome on it.” In those cases, I can see it go in the same way. Or React Native where the front-end team does React already so they just maintain their React Native app in the same way that they manage their React.If they’re writing Java, Dalvik, whatever it is on Android and they’re writing Objective-c or Swift on iOS and they’re writing .Net or something else for Windows phone etc. Then I definitely see those teams as completely separated from each other and then just coming back when they need to know how to talk to something. In a lot of cases the front-end JavaScript already solved that. “The endpoint’s right there and here’s how you authenticate it.”Joe:               Right. It’s especially right when you can have the same endpoints whether it’s JavaScript or mobile. I have a question for you then. What about the effects of the latest and greatest in the JavaScript framework scenario Angular to React? Do those change the viability of separated front-end, back-end team teams versus full-stack teams? What’s your opinion?Charles:        That’s really interesting and it’s funny because here we go I get to offend people. I’ve been playing a lot with React and React Native in particular lately. There are a lot of thing that are fairly similar between React and the way it does things and Angular and the way that it does things as far as components and how you think about components. I think the similarities break down a little bit just in how you get data and talk to the back-end but even then it’s all based on the same stuff even if it works a little bit differently.That being said, just from my experience with the two different frameworks it can and the reason that I think it can affect that is because you could conceivably have a front-end team that could conceivably build the components which are more or less custom tags that manipulate the DOMs in specific ways. Both React and Angular work in that way generally. You could have back-end teams that are writing some front-end just because they know the components there and that it will behave and it needs to be in a certain place in a certain way. It takes its parameters or properties in a certain way.I could see these tools being used to meld and bridge that gap where we couldn’t really do that before. In other ways, I could also see it where it’s like, “Look, get your hands out of my JavaScript. Just provide me with API endpoints. Don’t worry about HTML or layout or anything else. I’ll handle all of that as part of the front-end dev.” But the HTML in my opinion could go either way depending on how you think about your app. I could see that as a place where both teams cross over a bit in the way that they manage either static layouts or static layout with specific components in it or full on single page application. I hope that made sense.Joe:               Yeah, totally make sense.Charles:        I don’t know. What’s your take on that? Do you think it changes the dynamic?Joe:               I think it does. I think that as we see more and more specialists and bigger and bigger frameworks and I’m not saying that they’re getting bigger as time goes by but let me take for example Angular 2.0 which I know better than React but I think the things that we are going to talk about are going to be just as applicable as React is there to Angular 2.0. We just finished a training class over this last weekend. Two days, taught people Angular 2.0. Things are pretty straight forward. They learned a lot about Angular 2.0 in just a couple of days but we could spend a week talking about and this theme that was said many times, “The hard parts of Angular 2.0 are the parts that aren’t Angular 2.0.”Charles:        Yes.Joe:               You’re a full stack developer. You’ve been doing Angular 1.0 and have you been doing your app? You’ve been doing script tags in your HTML file. Maybe you bundle it up for production, maybe you don’t, probably you do. When I say hopefully I guess it depends on the application and the needs and performance needs and stuff. You might bundle it up for performance.Charles:        Yup.Joe:               With Angular 2.0 it’s not just Angular 2.0 anymore. Now it’s TypeScript. ES6 modules. It’s webpack. It’s the Angular CLI which hopefully makes all these things easier but that’s still yet one more piece. It’s ahead of time compilation. It’s lazy loading. It’s bundling. Deploying to production is its own thing. All of a sudden you’ve got so many more moving pieces that you really start needing some experts. Maybe this ends up coming down to just like CSS. This is a necessary piece but for all the DevOps stuff you just have one guy set that up and nobody else necessarily needs to understand it although hopefully there’s a backup guy. Somebody sets it up and then it’s out of the way. That’s true to a point but certainly things like ES6 modules are pervasive, RxJS is pervasive in Angular 2.0 and React has its own set of similar concepts. There are some that are definitely, you figure them out once then you could leave them on a shelf unless you want to tune them. Other things that exist all the time and they’re difficult enough that full-stack developers are already having to spend time keeping up on the full stack developments. Now it’s got an entirely different kind of ecosystem. I will say when I went from being a back end full-stack developer to a client side developer so many things so many things are not only new but just different. A lot of things were just different.I would that it can definitely affect that, maybe not to the point at, well it makes sense now to have a separate runner at front-end and back-end team but it might make more sense to say now we have to have our CSS specialist. Now we have our general front-end specialist. We also have to have our React specialist and our DevOps specialist. I’m pretty sure you got four specialists that are front-end specialist and if you only have 10 guys in the team well you might as well just have five guys be front-end guys and five guys be back-end guys because you already have four guys that you specified, “Hey, these guys are already specialist so we need them around as much as possible at front-end unless we got way less front-end than back-end work. Having them do back-end work might be a waste of resources and misallocation I should say. I definitely think it has an effect. The more we see the more complexity we see creeping in to front-end development.Charles:        I agree.Joe:               Can I invoke a little bit from a previous episode of the fact that Development of the Web is a Dumpster Fire. We need more of the specialist. We had this conversation.Charles:        We did. I’m curious with what you’ve explained where do you see web development going over the next several years then?Joe:               That’s interesting. Everybody wants to think, “Oh, it’s going to get simpler. It’s more straight forward.” But I don’t see that trend. I know that people are spending a lot of time and effort making things simpler and easier. That’s awesome. The CLIs that we’re seeing out of Ember, Angular and to a lesser extent React are making so that you don’t have to know as much. But I think even though we are constantly doing to a higher and higher level there’s a lot less development done in c today than there was 20 years ago and certainly an assembly. We’re moving to higher and higher levels where the same number of lines of code could do a lot more. Whether that’s changes in language or changes in paradigm. That’s constantly advancing but I don’t think that we’re getting overall any less simple.20 years ago, you really need to understand Pointer Allocations and Memory. Now garbage collection has become the de facto so you don’t have to know about that anymore but now you have to know about webpack, bundling and the difference in HTTP and HTTP/2 and size modification. 30 years ago, 640k mattered and then 10 years ago it didn’t. now we’re back to where 640k again not because it’s a magical memory number anymore but just that if you have a pack if you’re delivering 640k of JavaScript even that is, not a terribly large package, [00:50:59]. Even half a meg can be a bit too much to ship down in one delivery package.Charles:        It’s because our delivery package isn’t always wide enough for package like that.Joe:               Old school is new school again. Now the kilobytes are mattering again.Charles:        Isn’t that always the way of things though?Joe:               Yup.Charles:        I heard somebody explain that we went from basically a main frame with a consul to having PCs so that everything is on the client. There was a centralized system and then we distributed the system and we ran everything on PCs. We went to the web and we went back to a web browser being the consul to the web server. Now we’re back out to having web development frameworks that do a lot of the work on the browser. We’ve moved to the computation back to the consul or the client and these things keep coming back and going around. It’s really interesting to see just how much some things have changed and how much we have come back around to at least certain ideas and certain concerns that we had in the past.Joe:               It’s all very interesting. The take away from anything is developers will always be needed. We live in a really great era where we can pick and choose a lot what we want to do. You could specialize or you could be a generalist and you’d still get paid well whichever you could do.Charles:        Yup but you should really specialize. Unless you have anything else to add let’s go ahead and do some picks.Joe:               No. let’s wrap it up and do picks.Charles:        Alright do you want to go first?Joe:               Sure. I went and saw a couple of movies this weekend. Doctor Strange is just great but I also went and saw Hacksaw Ridge which was amazing. Based on a true story about a world war two veteran who was a conscientious objector, refused to carry a gun in the battle. He’s a medic and a front line right from an infantry unit. He performed one of the most amazing, I will definitely say miracles that you could possibly imagine. The movie was done really well. Mel Gibson directed it. I really liked the way that the movie was done. I really enjoyed seeing the story so I highly recommend if you have time that you go and check it out.                     For my second pick I’m going to pick the soccer MLS playoffs. Major soccer team in the US. It’s having its playoffs. They just had the finish of the first knockout round. Second knockout round comes in a week and a half or something like that. I think the 22nd of November. I’m going to hope this will be published by then. It will still be going on for a while so check it out. Finals of major league soccer. Those are my picks.Charles:        Who’s still in it?Joe:               Unfortunately, Utah is out. Eliminated by the team that I detest the most, LA but thankfully Colorado eliminated LA in the first round, the semi-finals round. They’re at quarter finals round I guess. The teams that are in it now are Colorado, Toronto is definitely in, and then Montreal. One more team and it’s either Seattle or Dallas. I’m not sure who won of those two. There you go. Those are the four teams that are left. I actually said there’s five. I’m not sure which of the five is left but there’s actually four of those five are left.Charles:        Make sense and if you’re wondering we’re recording on November 8. The apocalypse hasn’t happened yet I don’t I’ll [00:55:23].Joe:               Not yet. Not until tonight.Charles:        I’m going to jump in with a couple of picks. The first one is I got it to React Native. I was up until about midnight last night playing with react Native and working on an app. I’m going to pick that. We have a podcast on Devchat.tv called React Native Radio so if you’re into that go check out React Native Radio.I also went up using a framework called Ignite. That sets everything up for you in your React Native app. It sets it up with nice styles and make it easy for you to manage all of that stuff. I’m going to pick that. It’s been put together by a company called Infinite Red.I’m also going to pick because I was watching it as I was working. Frontend Masters’ latest course is on React Native and it’s done by Scott Moss. If you’ve heard Scott on this podcast and you want to go learn React Native from a genius guy like him then go check him out at frontendmasters.com.Joe:               Cool.Charles:        Alright, well we’ll go ahead and wrap this sucker up. Hopefully everybody else will not be travelling next week because I am. We’ll catch you all next week.Joe:               Laters.Charles:        Bye.