Drinks on stage - live at Jamstack 2022

Published December 4, 2022

It has been a while since we've done a live episode on stage at a conference. In this episode, we were on stage at Jamstack in San Francisco with our special guest, Jason Lengstorf, discussing specialization in software engineering.

Guests

Panel

Episode transcript

Edit transcript

Ryan Burgess
Hello, everybody. Thank you. Wow, it's awesome seeing everyone. It's been a while since we've been on stage. So thank you. All right, who's heard of the front end happier podcast before? All right, some hands. Okay. So for those of you who haven't heard, basically, it's a software engineering podcast. We're very casual. We talk about a variety of different topics. And so that's really what we're going to do here is have a live panel. So before we dive in, let's give intros. Marzieh want to kick it off?

Mars Jullian
Sure. Hi, everyone. I'm Mark Julian. I'm a senior software engineer at Netflix,

Jem Young
Jem Young engineering manager at Netflix of the web platform team.

Jason Lengstorf
I'm Jason lengstorf. I'm the VP of developer experience at nullify and the host of learn with Jason.

Ryan Burgess
And I'm Ryan Burgess, I'm a software engineering manager at Netflix. So if you've heard this podcast before, we like to choose keywords that if it's mentioned at all, while we're talking, well, we see we have alcohol, we're all going to take a drink. So what did we decide to the key word was to depth depths? If we say the word depth would that's we're going to take a drink. And today we're actually going to be going, the reason why we chose depth is we're going to be talking about the topic on specialization in software engineering and how it's changed over the past few years. So maybe before we dive in, we should probably what is specialization and what does that mean to each of you.

Jason Lengstorf
Okay, so specialization is actually an interesting thing. And when we when we were talking about this episode, I think I might be like the the naysayer on specialization here. But so I think the the idea of specialization is that, as somebody learns more in their career, they're going to focus down on a specific area. So you might start out as a generalist, but then as you get more in depth, on everything, cheers. You start to choose as a specialization. So you'll maybe go all in on databases, or all in on the middle tier node, and you know, serverless functions and express or whatever it is that you want to build. Or maybe you go all in on CSS or HTML and become a great animator. So there's, there's a lot of ways that you can specialize. And yeah, so we wanted to talk about how that has happened.

Jem Young
I specialization is a great topic specifically for the front end. So THINK, THINK web development 15 years ago, I know it's a long time for in web developer time. That's like, what, 100 years. All you got to know is some HTML, CSS, Java scripts. I don't even know what underscore was that 15 years ago?

Ryan Burgess
Oh, underscore is definitely like, yeah.

Jem Young
And I'm getting old. So underscore, you know, some jQuery, that's all you need to know. Now, especially in front end, you have accessibility expert, you access expert performance. What are some other ones name, some front end? specialties?

Mars Jullian
design systems? Lifting? I think localization?

Ryan Burgess
Yeah. I mean, I think you covered them all. I'm like, I'm lost for examples. Yeah, I think like, for me specialization, it has broadened in the front end. But even in all engineering, like I don't think it's just specific to the front end, like you mentioned, even performance. I mean, that could be front end. But that could also be backend or like distributed systems. That could be you know, a little more on the platform side. I think that more and more, we're finding that we need these specializations. And to me, that's what I've started in see the that we've changed? I'm curious to hear from all of you, has this become something that you've noticed, like, just recently changing? Or is this something that's really been like this forever? In our industry,

Mars Jullian
I think like, at least from my perspective, it has been gradual, but it is more recent. And I think also, it has to do with how we're building our applications these days. I'm remembering when I started software engineering, it was sort of like one big single page application. And it was like lots of components backbone, for example, and you're talking to a back end, you know, one, one service, and now it's, well, we actually have started to break up our backends into lots of micro services. And we started to think about the way we build our UIs differently as well with like, things like component driven development. And then, you know, having our state management be in different layers. And I think it's mostly just, actually I don't know, which came first, like a chicken and egg. Thing is, did we specialize first and then we started building things differently, or did we start building things differently? And then people started to specialize in those topics to make them more robust so that every layer of what we're building is pretty stable.

Jem Young
It's been coming a long time. It's the nature of progress, right? So I don't need to know how the bios on My Computer Works anymore because that's all been out. skated away on a nice platform, I don't need to know exactly how to deploy a server to AWS, because that's been obfuscated away from me. That's the nature of progress. That's the nature of what human development and software development is. So it's natural that there's two ends. And Jason, I know Musil, some some of your thunder, there's increased specialization on one side. And there's decreased specialization on the other. And the fact is, as software engineers, we are moving towards one or the other, you may not know it, but you are moving towards more of a generalist, you know, to use tools that do all the work for you. Or you may be a specialist. So performance is a good one that I always like to go back to, to the point now where you say, Hey, Jem, it's nice to meet you. I am a front end engineer. I'm like, Cool. What do you do? Front end, that doesn't mean much anymore. Because that's such a broad field. And you can be an expert at, you know, WebSockets, or accessibility or user experience or something like that. That's increased specialization. And, Jason, I know you have thoughts on this. So

Ryan Burgess
I feel like we needed to get to that because you started off by saying, I'm not for this.

Jason Lengstorf
So yeah, I think Jem has soundly stolen my thunder. But but the I think the thing that's, that's been really interesting for me in watching since, you know, I've been building websites for about 20 years now. And what I saw at the beginning was, you know, as you said, there's just HTML and CSS and like, little bit of JavaScript, call it DHTML.

Ryan Burgess
Oh, I feel like we should be drinking to that HTML,

Jason Lengstorf
you know, pour one out for DHTML. Right, like, cheers. But so we had, we had, there wasn't a lot of breath, to what you could build on the internet, because you really didn't have a lot of options. And so as the options grew, we saw jQuery, backbone, knockout, all these great tools come in. And suddenly, you could build way more in depth experiences. But what I saw at the same time, is that, you know, we had one option for getting things on the internet was basically get shared hosting. And that was fine. It wasn't a great experience you like worked in your FTP server. But then as time went on, we saw Docker, we saw Kubernetes, we saw all these different ways to go out and deploy, you could get Linode and stand up a bare metal box, or you could use something more managed, or, you know, specialized hosting, like WP Engine. And suddenly, you kind of had like this, you needed a lot of expertise to choose where to put something on the internet. So you're, you're becoming sort of a server manager, then you've got things like, you know, MySQL start showing up and everything, you've got WordPress, you got to figure out where are you going to put your your databases. So now you're becoming a database admin. And then you've got to figure out how caching works. You're trying to set up a varnish cache for your, your WordPress site, and, you know, now we're all trying to be caching experts, right. And so that sort of specialization was was really complicated. But we've seen what I would say, is almost a D specialization, where all of those tools are becoming commoditized. If you go out there, and you ship, you know, a pretty much any of the modern front end tooling, you go Netlify, CloudFlare, oversell whatever, like, the cache is there, your service deployment is there, you never have to learn any of those things. And so now a generalist is actually capable of building some really, really in depth and complicated tooling. Because I don't have to think about how a database works, I just need to access the data, I don't need to think about how things are served, I just need to define a serverless function, and it'll deploy globally. For me, I don't need to think about how caching works, because the CDN is already there. And so I can use that that general front end skill set, and skip over a whole lot of really, really challenging specializations that allow me to build a lot more. So that's where my naysayer comes in, is I actually think an average web developer is capable of building a whole lot more than an average developer would have been capable of 10 years ago.

Ryan Burgess
No, I think that makes a ton of sense. Actually. Even something new like I, you talked about deployment, and that is a big one, or even how to manage a database. All all that kind of stuff is complex, right? But there's another thing that you hit on that kind of got me thinking is like, we had the jQuery knockout backbone. And even as I think of those frameworks, they started to take a lot of that heavy lifting off of you, too. Like knockout to me was one of those ones where two way data binding just took place. And that was huge. Like you would have had to do all that extra work in vanilla JavaScript or jQuery. And here you have something taking that away, you just don't have to think about it as much. And not even that I get to your point is like you're not having to worry about all those little details. So that's a fair point. The only thing I was maybe going to hammer on a bit there too was like what happens when you have to debug some of those systems like the deploy A minute like something's not working or that performance that cache, that caching layer is not working. What do you do at that point? Like, that can be a problem.

Jason Lengstorf
So here's, here's what I would say is like, Who here has been doing this long enough that you've set up and manage your own cache? Right, I'm seeing some hands. So I don't know what y'all did when your cache went bad. But what I did is I turned it off and turned it on again. And I hope for the best, right and always works. And this was really the problem is like, I, even when I was a specialist, I had no idea how this stuff worked. And so when I go, and I use an odd trust that the people who run that CDN, definitely know more about it than I do. And so like when I need to debug it, I'll be honest, I haven't needed to, like I need to debug my own database calls. Or if I start writing my own cache headers, yeah, I'm gonna get myself into trouble. But typically, if I trust the people who run these services, and just follow their defaults, I haven't hit like, a caching problem in years. Like, it's wonderful, right? I was like, You know what, you're smarter than me, I'm going to do what you tell me and poof, whole category of problems disappeared from my life. And I think that that's, that's the part that I think is such a game changer is that you know, now, you don't have to go out and hire a world class cash specialist, you just hire the SOP the platform as a service that already hired those world class specialists. And as they spend their entire, like, all 2080 hours a year, those people are working on making caching as good as possible, so that I never ever, ever have to think about it,

Ryan Burgess
which would be a huge benefit for specialization. All right.

Mars Jullian
Well, I just I like a lot what you're saying about sort of, like even specialists can be generalist, especially with a lot of tools, you know, any developer can now do like, a larger breadth of things, and they might have been able to do before. But on the flip side, too, I think that even specialists, you know, like the maintainers of these very specialized tools themselves have an element of generalism to them, because they have to sort of understand the boundaries between what they're building and the rest of the world, as well as the different use cases that they're building it for. So maybe, maybe you've converted me now to someone who's also a little bit of a naysayer on the specialism train, in terms of I think everyone has to have an element of being able to do many things. But you know, breadth first and then maybe depth later.

Jem Young
So my, my problem with a generalist is you, you can't be a senior generalists. Like, so I

Ryan Burgess
Oh, yeah. No, no, no, no, no, no, no, you can't be a senior general, I

Jem Young
don't think you'd be a good senior generalist. So we're hiring managers, we hire people. When you're thinking about the composition of your team, are you thinking, oh, I need someone who is a generalist. If you're, if you're hiring someone senior, or you're like, I need this specific set of skills and this specific expertise, I would round out my team. So

Jason Lengstorf
I mean, anecdotally, I was a principal generalist. So I think I think that there are definitely cases for everything, right. And one of the things that I've noticed is that at at Netlify, we have hired principal specialists who have world class knowledge in one thing, and we've also hired, like generalist principle level generalists, whose job is to look holistically at what's happening within the system, and help us spot patterns that, you know, their huge array of knowledge and past experience, allows them despite things that a specialist might miss, because they're, they're so zoned in on one area of responsibility. So, I agree with you, in general, though, that it is, it is very challenging, I think, to become a generalist at that, like, if you get hired at a big company, as companies get bigger, they necessarily specialize. So I think the the, the caveat that I would apply is, I was a principal generalist at a 20. person company, right? And so that that is a I don't know if it would make sense for me to get hired at a 500 or 800 person company, as a generalist, because they probably have a more specific problem than, hey, come in and look around and see what's going on. And you're like they do but like one of those, you know, it's not like, it's not like every team needs a principal generally.

Mars Jullian
I think also to answer that question, I would say it really depends on the team that you're hiring for what I've seen, I don't know about you all, but companies are forming more and more specialized teams over time. So like platform teams, infrastructure teams, a specific microservice team design system team, like like what I work on, and I think, you know, there it's very hard to hire a generalist, but sometimes when you're in a product world or a product team, or you know, some other team that's maybe more of a conglomerate of skills, like you know, having a generalist roles is applicable and probably very valuable.

Jem Young
makes sense. And I like this, this is a healthy to the size of the company does matter about specialist versus generalist? Absolutely. Like I'm not going to get hired, pick a big tech company as a generalist, like I'm going to have a very specific role. They're in a very specific stack in a very specific setup. I think the challenge is, when I say you can't be a senior generalist is you, even you principal generalist, as yourself reclaim, you have depth in a lot of things. Cheers, cheers. Like, Jason, I know you, we've been friends for a while, you have depth in many, many areas, you may not think of yourself as like deep, but you could probably talk about a variety of subjects. So I don't know, it's hard for me for someone to say like, I have a lot of experiences. But I say I'm a generalist. If you're senior, I know you have depth in something. So I think that's where I try to make that distinction.

Jason Lengstorf
I feel like you had something to say. So I want you to

Ryan Burgess
know, go ahead, Jason.

Jason Lengstorf
So the thing that I found really interesting is thinking about careers. I've heard the phrase T shaped thrown around for a really long time where you're, you're kind of shallow in a lot of areas, but you go broad, and then you've got like one area that's like your area. Another way that I heard this described that I loved was this idea of paint drip. So if you're a paint drip professional, it means that you go broad, and then lots of different areas of expertise, you get varying levels of depth chairs. And this is going to be a dangerous as good. So as you as you sort of continue throughout your career. So to your point, as I, as I started, I started out as a designer. And then because we needed to do something, I figured out how to do some HTML and CSS. And then I got into JavaScript, and suddenly I was maintaining servers. And then I got really into the back end and like Node and building microservices, and all these sorts of things and got into developer tooling. And at each point along the way, I was gaining more experience that made me more of a specialist. But I think the thing that that has always really paid dividends for me is the the the broadness. And I also there's another like facet of this, I think, which is the type of person that you are. So I've heard this really interesting categorization of people where there are, I think it was Simon Wardley came up with this with their pioneers, who are like explorers, they dig in, they try new stuff, but they have no follow through. Right? Then you've got people who are town settlers, they'll follow the pioneers, they'll find something that's been sort of exposed, and then make it more real. And then you've got city planners, people who will go into an established system, and they want to polish it, they want to make it perfect, right? I am a pioneer. If you put me in a system, and you asked me to own that system for years, I will quit that job. Like, that's just not how I'm wired. I'm very much like, I want to try stuff, I want to be an r&d, I want to be kind of exploring and seeing what's possible. And I want to hand off the experiments to somebody who doesn't necessarily want to explore, but wants to take something and mature it. Right. So I think my career, because I have that that sort of seeking for new things. mindset that generalism in my career has been a huge asset to me. I think if I was more of the town settler type where i i wanted to own a thing forever, I don't think it would have served me the same way. And so I think that's another sort of dimension of looking at it where I have to make sure I take into account my own my own story, my own circumstances, when I'm kind of making these claims.

Ryan Burgess
So that's an interesting point. Jason, like, do you think that we, if you're almost too specialized, is it career limiting at that point?

Jason Lengstorf
No way. Like, like, look at look at somebody like, like Liz Fong Jones or charity majors, like they're so incredibly deep in their area of expertise. And I'm like, I don't want to imply that they don't have any breadth at all. But like this, they are specialists, right? And they are absolutely doing better than I am. So I don't, I don't think that that is Oh, to hire them if you need that done. And that's exactly what it is. Right? Like when when Netlify when we're looking at our SRE team, nobody wants to hire me. I am the very last person who should be on an SRE team, because I just am not wired for it. But I absolutely want a world class specialist to come in and be on the SRE team. So I don't think it's career limiting at all. I think it's I think that it's limiting in the sense that like somebody who is wired for specialization, and for for that, like city planner, you probably don't really want an r&d job. It's going to stress you out the same way that I shouldn't take an SRA job because

Ryan Burgess
it's not it's a fair point. Jem, I'd be curious for you like since you're probably leaning more to like specializations a great thing, any like, what are some of the positives that you would sell someone when they're like Jem, I need career advice like Why would I specialize in how should like what would be the benefit of me specializing in performance?

Jem Young
for career advice, you have to be able to go deep on something. Like if you say your senior, you say you have X number of years of experience, you have to be able to go deep on some topic that you're passionate about. That's why one of my favorite interviewing questions of all time is, how does the Internet work? Because it doesn't matter where you work in the stack with your front end, back end networking, you're going to be able to tell me some specific part of that of the internet sack, which is everything, and go really deep on that and show me like your passion, show me what you know. So you do need that specialization in some degree. I really liked your analogy of like the Pioneer to subtler, I always use the hacker, developer, engineer architects. But you know, we're all talking about the same thing. And it's fine. It's about the role that you want to go for, ultimately, is it I want to be perpetually on the bleeding edge, building new things, showing people what's possible, you're probably more of a hacker, and there's definitely roles for that. If you're saying, Hey, I've got this eight year old codebase, it's got a lot of issues, it needs a lot of help. You know, I'm not looking for a hacker there, I don't need someone to go in there. And you know, throw around the China, I need someone who's more of an architect and say, here are your problems. I've done this before, I have deep expertise in maintaining complex distributed systems, something like that. So my general career advice is find something you're really passionate about. Go deep on it, even if it's totally unrelated to what you want to do, be passionate about it, because that will show up in later in your career, you'll need that at some point. But don't be over specialized, where you're like, This is the one way to do things, because it's the way I've done it for 30 years, because we've all worked with those people. And they're they're very unpleasant to work with, even though their expertise and they're they're experts in their field, don't be that person, like, have a feel for what the latest technology is, even if you don't completely understand it, at least have a passing knowledge of what people are talking about.

Ryan Burgess
I like that keyword of passion, too. I think that's a really good example. And like someone like Mars, I've worked with you for years. And I've known that you're really passionate about like creating, like design systems and building components at scale. And I'd be curious, like, how do you think of specialization when it comes to design systems? Like specifically?

Mars Jullian
That's a really hard question. I think. I mean, also, the word design system, the word system is in the name. And so specializing in a design system is not just specializing in one thing, even though it's specializing in an area of interest, or like a type of a type of service, I would almost call it because you're building components for other people. But it goes back to even as specialists who are building a tool that is like potentially just one very small part of part of your stack, you still need to know a lot about other things like accessibility, localization, unit testing, in the case of Netflix, it's like a B testing, how do you build components that are flexible enough for a B testing, and I mean, the list probably goes on, I was just making a list of like, you know, a page long at this point of the type of work that is that's involved. And so I think that, I think it goes back to to Jason's earlier point about, you know, even specialists or generalists, because you need to know a lot more than just the one thing you're working on, because it exists in a world of tools in a system of engineering. And I think that's, it's hard to really just focus in on that and close your, close your eyes off to the rest of the world, I think, to be open minded, again, like, you know, going back to, if you're someone who's like, this is the only way I've done it for 30 years, it's very hard to work with. So just keeping an open mind, even when you are very passionate about something can also not only open your mind to other things, but make what you're working on even better.

Jason Lengstorf
I just little self plug here, I was just the keynote speaker at all things open this this last week, and the topic of that of that keynote was seeking and wandering. And this idea that when you like you have to specialize, because you have to practice, right, in order to do anything. Well, you've got to be willing to put work in and really go after like, what are the finer details, where's the the true expertise here, but you can only gain expertise in something that you know exists. And so you also have to do some wandering around and looking at what else is out there. Because otherwise, as you said, you end up that person who's like 30 years down the line. And you've you know, Scott Hanselman just said, you know, have you do you have 30 years experience? Or do you have the same year of experience 30 times, and I that is a really resonant phrase, because you can definitely see folks who sort of settle into a groove and they're not really learning more. They're just where they're, they're just where they want to be, and they're just coasting. And that's cool. Like you you don't have to be that thing. But it gets harder to make the claim of like, I've been doing this for 30 years school you haven't been learning for 30 years. Now. How many of those years have you actually been like because I mean, more of an expert, as opposed to just kind of settling into a lane and staying there. But yeah, I think you need, as you said, like, there's got to be that combination of both where you're you're trying to get better at the things that you're already good at, and trying to see what else is out there so that you make sure you don't get yourself locked into a rut.

Ryan Burgess
I think that's really well set to and I think that I mean, we're talking about front end, right, front end has constantly changed, drastically changed all the time. It's it's evolving, things are changing. And I think if you did things the way five years ago, or even 10 years ago, if you continue down that path, it's probably pretty limiting, right? Like, there, we've solved for other things that have come up, things scale better. And so I think to your point, there is like, yeah, you have to continue learning. And to Mars's point, you also have to understand some way of which you're connecting to, right. Like, you can't just say like, I specialize in this, and like, that's all I care about. It's like, no, there's you have to connect those dots. Now, that being said, I want to go back to the job point, because like, so one, we said, it's not limiting. But I do feel like being a specialist, you have to know like, how to find those right? jobs like, right, you're not that person JSON that everyone's necessarily always just like, that's the guy who does performance. But how do you how do you find jobs or know that this is the right job for you? Like when you're a specialist? I don't know. You're looking for a job?

Jason Lengstorf
No, I think when you when you're. So I think part of it is recognizing when you have developed a specialized expertise, I think that I speak to a lot of people who are really deep experts who don't believe that. So somebody who has been, you know, making CSS and SVG animations for years, there is a market for that people really do want beautiful animations and performing animations on their homepage is because we see them all the time. And whenever a company drops a really dope animation. It's all that Twitter talks about for like, a week and a half. Right. And so there's there's definitely a huge market for that. And Lynn Fisher, who won the personal website of the year, if you? Yeah, like give it up for Lynn Fisher like Yeah. But but if you look at her work, you can see very clearly that Lynne is I don't know that Lynne would describe herself as an expert, right. And so I don't want to pick on Lynne so let's talk about somebody you know, somebody who's like really into the database space, or really into some other, you know, performance or something like that. If you, if you are a specialist, and you're looking for that specialist role, you have to first internalize that you are in fact an expert, and like, be willing to accept that, and then go seek those roles specifically. Because if you if you aren't, if you're an expert, and you're like, Well, I'm just looking for like, a little bit everything, you're, you're actually going to struggle on the interviews, if all of your depth is here. Sorry, cheers. Cheers. It's been a while. If you know, everything you know, is in one category, but you're applying for a generalist role, or presenting yourself as a generalist. So I do a little bit of everything. When you get asked questions out of your your specialization, you're going to struggle in that interview in a way that you would really shine, if you said, I am a database specialist, and then they're going to ask you about it, you're gonna light up, you're going to talk about it and just like, blow somebody away in the interview, because that's the thing you said you're good at. So I think that's a big part of it as a specialist is you have to be willing to own that specialty.

Ryan Burgess
I really liked that a lot one upon obviously applying to that role. But even if you were in the maybe not the senior of senior roles gem in the generalist, but if you're going for that role, it's also even just highlighting that in the interview in some way of like, I care a lot about CSS, I'm that person who just dives deep into CSS or I care about whatever it is like databases, and you're you're highlighting that for them too, so that they really see that shine and evaluate on that. So I really like that is like even just calling that out in the end. I would be curious to have like you touched on CSS and like SVG animations. And I'm gonna call out on Twitter as well. Oftentimes, I'll see people say like, you have to know JavaScript, in the front end world, you cannot be you know, just specialize in HTML or CSS. What are your thoughts on that one you like if you didn't know JavaScript is that I know

Jason Lengstorf
several people who are full time employed who don't really know JavaScript. So I know I think my personal stance is, it is fun to learn everything and therefore you should try to learn a little bit of everything that's sort of my driving ethos. However, I don't think it's necessary. I think it will make things more challenging because the the more avenues you cut off the the more difficult it is to find something that's a good match, because the the shapes get more are specific, right. And if you make yourself a very specific shape of developer, you have to wait for a company that not only values your skill set exactly and nothing outside of it, but also has a role open, and also is a company you want to work for. And also is that a budget that you want to work, right? So it starts to really limit your options. But I've watched people do it like there are several people in my network who just don't write JavaScript at all. And they're gainfully employed, they they do great. But there's not a ton of them not like comparatively far more people who have been a little bit more general in the baseline of their skills have been able to find work.

Jem Young
You said well, the more specialize you get. And the more expertise you get, the harder it is to find a role that's going to fit you exactly. And the harder it is to find a company that's going to fit that exact role. And generally, the more specialized you are, the more specific the company and probably the larger the company, start up with 20 people is going to need a principal generalist, you got to touch a little bit everything database, back end, front end networking, security, but a large company, you're going to be very, very, very, very deep into a specific area, I can think of some roles of some jobs I've looked at. And I'm like, That would be cool. That would be cool to be the world expertise of this company. And I don't even remember what it was, I think it was like gRPC schemas. And this was Google at a job I was talking to and I was like, that'd be cool. It'd be cool to be that person. However, do I want to be that person like is this really where my passion is gonna lie in the next 10 years? Probably not. But there is that role for that person. So that's the danger of being overly specialized. The upside is, there's a lot of COBOL engineers in the world who make a lot of money, because they're the only ones in the world who can write COBOL. So glad you brought that one up. The financial system is a lot of it's written in COBOL, nobody writes COBOL anymore. So these people have job security, you know, till whenever till till they pass, and you know, they all do a migration, and then you'll have tire migration expert, and all that sort of thing. So, that's the upside of being a specialist is, once you're world renowned as that person, you can get paid a lot of money, but your roles are going to be very limited, your career is probably going to be more on one trajectory. So you really have to know what you want to do before you say, I'm gonna become a specialist in this area.

Ryan Burgess
I like it. That's, that's a good point of the COBOL one, though, like, do you want to be doing that forever? No, probably not. And also, to your point, the migration piece is like, eventually those things migrate off of it. And so I think you're, you still need some depth, like you need, you can't just be, I only pay attention to this. Cheers. I didn't catch that one.

Jason Lengstorf
So I think you just brought up COBOL. And I actually think that's a really important thing to call out. Because COBOL is a great specialization, because it's so ingrained in the industry, right? You If you over specialize on something that isn't ingrained like that, like if somebody out there is trying to become like the world NFT specialist. That was such a good idea six months ago, and it's, it's a little bit more challenging now. Right. And so it should be something that is going to have a little bit more like proven longevity before you specialize. Because otherwise, you're putting your all your eggs in a lot of bad into like a in a pretty new basket. And it doesn't have legs yet, you don't know if it's going to live beyond next year, the next fad cycle,

Ryan Burgess
which even to the like JavaScript ecosystem of frameworks, we've always said, like, no JavaScript, know the fundamentals. Because the frameworks do come and go. It's like, you could have been a jQuery specialist or a backbone specialist. There's still there's still code bases out there written in that. But now it's becoming more limiting. And so it's like React view, whatever else is new in the industry. It's like, you still need those fundamentals. And so to that point is like, you don't want to just jump on the new hotness and say, I'm going to specialize in this because it does come and go. It's a valid point. What does the future look like, though? Like, do you think it's going to be our industry is going to become more specialized, less specialized? Like, we're, you know, I feel like to me, it's becoming more and more specialized. Like, I feel like everyone is becoming like to JSON your point where the earlier was like, we offload, like, we really have to only care about a couple things, so that someone specializes and takes care of that caching layer, and you don't have to think about that anymore. But I'd be curious what you all think is like, what does the future look like?

Mars Jullian
Um, I mean, I think it's like a lot of things it's probably gonna be a pendulum. And we're gonna, you know, like, specialize more and more and have smaller and smaller teams to a point where it no longer makes sense potentially to have a team or a specialist. They should in that area to some of your points, like both of your points earlier about how if you become so specialized, you sort of close yourself off to other opportunities in the future. So I think part of the specialization we're seeing now is pretty healthy in terms of creating like smaller and smaller, maybe more composable systems. But if you break it down to small, I think that's when we'll see the pendulum swing the other way back to teams that are a bit more of an aggregate of skill sets. But I'm not sure exactly when that will happen. i That's just my gut instinct.

Jem Young
I love you said composability that that to me is the future. Have any of you ever read Snow Crash, you know, very famous book amongst a sec nerds. But in it, they describe kind of a bleak future, but one that's probably a little closer than we'd like today. But in IT software development is akin to a factory job, you're taking components together, and you shipped out the door, you don't really know how the components work. But you know how to put them together in a way and you know how to debug a little bit. That, to me is where software development is moving, and we can already see it. Instead of me having to know how to configure Apache and configure my firewall, I can just slap some HTML, CSS, slap it in that nella phi, it deploys my website, I don't have to know how any of that stuff works anymore. That's what I think we're gonna see more of kind of that more assembly line or I'm an expert in this toolset. However, someone still has to build the tools, so and also maintain the tools. So there's opportunity at both ends, it's kind of where do we want to be, the world does not have enough software development, or software engineers, like that's pretty clear from the salaries a lot of us get paid is, there's not enough software engineers in the world, I don't know if there ever will be. So what we're going to see is more and more common sets of tooling more and more component based systems where you don't have to have that deep expertise that's necessary to be a software engineer today, you can just put together these tools. And it works. I think that's okay. I think that's the nature of software, the nature of progress, nature of software development and human development. But someone always has to build the tools, someone has got to have the expertise. So there's opportunities that both both ends.

Jason Lengstorf
Yeah, I think that that, that's pretty close to, to what I see happening, what what I've found really interesting is that we need deep specialization and all the software as a service and platform as a service companies, then we've got all the companies that are just trying to build their websites, they don't need, they're not, they're not building infrastructure, and they're not selling a tool to anybody. So I think that we're going to need a lot of specialization in the developer tooling space. And that is going to be such a good space for anybody who wants to go deep. If you want to be a world class specialist, start looking at that, like be the one who's figuring out the best tools to make for developers. And then if you want to be more of a generalist, be one of the people who builds websites, join a marketing team join in an agency, you know, work on a, a, you know, a fashion brand, or an E commerce brand, where you're just going to be working on the storefront, because that's gonna let you be so broad. You, you get to work with the design systems with the JavaScript framework, you get to do the CSS, do the animation, all these cool things, you get to plug in the API's, but you don't have to go necessarily go build the API's. Maybe you write a little, you know, middleware, maybe you're writing some edge functions, but you're not necessarily like digging deep into the micro services. And I think that, like, there's a lot of the gradient here is pretty, pretty broad, you know, I think you're going to find companies that are pretty web native, that are there gonna have a ton of like, composed API's, like composability, I think is absolutely what's coming next, right? Like everything is becoming composable. We just use API's. plug everything together. So some teams are going to be doing slightly more advanced versions of that, where you use five or six or 15, different platforms, software as a service, and you're wiring all those together with you know, a little bit of node and whatever that is, and then that's what you bring on to the front end, and you get to do all the front end stuff with it. And that's super fun, super general. And then there's the people who will build those 15 services. And that is real narrow, you're an SRE, you're a database specialist, Performance specialist, you know, whatever it is. And I think, to me, that's really exciting. Because it means that you don't necessarily have to choose, you just have to know where to look for the type of

Ryan Burgess
I love that you said the part about developer tools too, because I think that you're enabling more of this, like, how do you build at scale and, and all that too, is like Netlify is a great example where it's like, it just makes it easier for people and that's amazing. But when you're in some large companies, they're having organizations that are literally thinking about this, like I'm part of Netflix's productivity engineering space we build tools for our deployments are like builds are even in production. Like what what are metrics on that? How are things looking and all those things just take that load off of people so that they can do their like A B tests, like we do a ton of that at Netflix or build their feature, and get that out the door. And so I do actually see us going more and more in that direction. And I love that you call that out is like there's companies that exist because of this and will continue to exist. So I think that's like a great way to kind of summarize that. So I love

Jason Lengstorf
that. It's like, this is a little bit tangential, but I find it really exciting. Because of the work that your team is doing. How long does it take for a brand new hire at Netflix to make their first commit to production?

Ryan Burgess
It could be better? That's for sure. You know, I think it varies actually depends on the team and everything. But that is something that we're striving to make better, right, we want to make sure that it's really easy so that we take that load off folks to just go and you know, take it and make it so they don't have to think about all those details. Now, could we do better documentation, onboarding all those things? Absolutely. But yes, once the you're up and running, things should just work, right? Like you shouldn't have to think about those details.

Jason Lengstorf
That's, that's the part that I like, me, my little developer experience heart loves the fact that 10 years ago, 15 years ago, the companies that I worked for consulted for it was a month, it was, you know, weeks, at minimum before somebody new to the company would be able to make their first commit to production. And that was some combination of setting up the dev environment was really complicated. And way out of their skill set, you know, maybe you got a front end developer trying to set up nginx locally, that's gonna you know, okay, well go find a senior engineer pair with, or it's because the deployment process was too slow, you had to go ask the DevOps team who was way overburdened to make you a staging environment, and they, you know, it takes them a few days to get to it. And so you just have like all of this really slow ramp time to get anything done. And because of the, what I would say, the squashing of specialization with platform as a service and software as a service, we've got, you know, when somebody joins Netlify, they can commit first day, because all they're doing is cloning a repo and like running a CLI tool, and they're just there. They're done. They're local, local Dev, right. And that is such a powerful thing, that it takes an internal tooling team, it takes a developer productivity team to think about that. And that's deep, deep specialization, so that a generalist like me doesn't have to learn any of that, to start building the website when I joined the Cony. I think that's so exciting. And even

Ryan Burgess
better when you have industry tools doing it, right. Like you're you can jump around to companies, and you're like, Yeah, we all use this, like, you know, get hub. Like we all use that. And it's like, that's really cool to just its ease of use. So yeah, I think that's a good way to end out. I know, we're running right up on time. I want to thank you all for like checking us out listening to us on the panel. Maybe I'll throw it to each of you. Where can people find you to tell you you're wrong on specialization? That's what that's all.

Mars Jullian
I'm not really on Twitter, like a lot of people on this stage, but I'm on Instagram at Mars, Josephine, the pH.

Jem Young
I am on Twitter at gem young and I will argue with you all day, anytime, anyplace. I'm kidding. But, you know, it's LinkedIn, LinkedIn.

Jason Lengstorf
I'm at Jay lengstorf on Twitter, Mastodon wherever. I don't argue on the internet, but head over to the barks and brews afterward, and I'll argue the hell out of it.

Ryan Burgess
And we've already started as you can see. All right, and you can find me on Twitter mostly at @burgessdryan. Thank you all for listening. You can find front end Happy Hour front end happy hour.com or on Twitter at @frontendhh. Subscribe to whatever you like to listen for podcasts on and give us a listen. Thanks so much depth depth