Crafting Code Podcast

[00:00:00] Allan Stewart: Welcome to episode 13 of the Crafting Code podcast, where we discuss the importance of doing the right thing at the right time with the right tools. I'm Allan Stewart, a software architect, and lately I've been thinking about simulator code, which I wrote in days gone by.

[00:00:15] Dave Adsit: I'm Dave Adsit, a CTO, and I have been thinking about behavioral economics and commitment

[00:00:21] Matt Baker: mechanisms. Hey, I'm Matt Baker, software architect. Lately, I've been thinking about swapping out my home internet for a 5G connection.

[00:00:30] Allan Stewart: Our episode topic today is full stack development. So Dave, what does full stack even mean? Why are we talking about this today?

[00:00:39] Dave Adsit: You know, sometimes I think that full stack is just a sales pitch or a marketing tool that we use in our job boards to let people know that we expect them to know more than just JavaScript and CSS. And also to let the people who only code on the server to do JavaScript and CSS. I think about it and I'm like, you say full stack. And I'm like, okay, so the stack starts with electricity, silicone. When was the last time I wrote a C compiler? That's right. Never. It's a pretty good argument to be made that there are not very many, if any, full stack developers in the world. But we sure do fill a lot of full stack development jobs It's about 15% of the stack instead of the typical 12.

[00:01:29] Matt Baker: So I think one thing we've already established then is that full stack might have aspects of title glorification to it. I think the term right now, full stack is synonymous with web development. So they're in web development. I think it describes someone who can write JavaScript, HTML, and CSS, usually with qualified with like a react or angular or some framework front end. And then they also can get in the back and write APIs to serve that web application and potentially, well, not potentially, but also right into the database. So they understand how to do data modeling. So oftentimes I think it's like a database middle tier front end is what we mean when we say full stack and that's all web development centric.

[00:02:17] Dave Adsit: I think that there is also some aspect of the client server kind of architecture that you would get in. And maybe a mobile app, you might have a full stack mobile developer as well, but you're on the right track there, Matt. Definitely full stack is front end server side database. There's definitely something to that in the, we typically need people who can do that kind of work. We're trying to build effective teams. And I think that we've learned as an industry that slicing people in layers across technology, is an anti pattern for delivery.

[00:02:59] Allan Stewart: It's kind of where the pendulum has swung in the industry. We've gone back and forth many times between server side development, where things are centralized on a server and client side applications where individual computers do the work, right? So in days gone by you had a mainframe and nobody owned a computer, but everybody connected to the mainframe with like a teletype machine or something like that in order to do that. workloads workloads workloads workloads workloads workloads workloads workloads workloads workloads workloads workloads workloads workloads workloads workloads workloads workloads workloads workloads workloads workloads workloads workloads have native apps, but we're kind of at a place where this pendulum has swung back and forth. And we're kind of in the middle where a lot of software development these days is expected to have server and cloud components to them, even if they're mobile first apps, or that there's a strong client side perspective to what they're doing. And so then going to full stack, it might not be the full stack of all the things that you would ever use, but it's this idea that we, we want some people who can span that gap. And typically it gets broken up between front end

[00:04:20] Matt Baker: and backend. I've noticed with people that call themselves full stack devs, and I don't meet many people that wouldn't take this label if you offered it to them, you know, I've noticed that they often have a preference for some part of the stack. So for me, the real value, I think, in a full stack engineer is that they at least are capable in the CSS down to the database, maybe, writing some infrastructure code in AWS, they're able to do all that. But oftentimes, I've found that they'll have a preference for something like they might be a CSS whiz, they might love doing artwork and putting it up on the front end. Or they might be the person that loves to write an interesting algorithm loves to tear apart maybe like a security, like a password hashing implementation, or they like web servers, but you know, they're more focused on the back end. And sometimes you meet the people that are just super into data, they write their own data, databases on the weekend, right? So they're most at home, like when we start talking about the data layer, but when those types of people that have those deep specialties can also at least be kind of effective in the other layers of the stack, I think that that's really valuable. And yeah, I don't know where I'm going with the rest of that. So I'm going to shut up.

[00:05:30] Dave Adsit: So I think about it in terms of these are your T shaped people. Saying full stack is kind of like saying, I'm looking for T shaped developers who are broad in a lot of areas, but deep in the originally I was thinking of as like, you know, a lot of us started our web development career on the front end, because the feedback cycle is super fast. And it's easy to see that you did something. And I know a lot of more novice developers, people starting their career really like that feedback, because they can see what they did actually made the computer do something. And I totally resonate with that. But then over time, you start to get more into the deeper aspects of software development, of enterprise application development, or whatever. And you start to think, oh, well, I want to work more on the back end. And so my thought was, maybe full stack is an indication that somebody's made the leap from one side to the other. There's probably people, I don't know any probably people who started on the back end and jumped to the front later. And then I was thinking, maybe this is just a way of saying, I'm looking for people who are kind of mid-level, four to seven years of experience, and they're kind of in the middle of that transition. So they're more comfortable on both sides. And now I don't know. Now I think it could be anybody. I think there's definitely some differences

[00:06:56] Allan Stewart: between what we consider front end code and back end code, mobile apps, and the frameworks that you use for mobile, right? That gets really interesting. And you can go really deep in that space. User interfaces and how they work and what kinds of, you know, what kind of, you know, affordances that you give to your user, how you help them accomplish tasks. Those are often different kinds of problems than you see in the so-called plumbing of the back end, because they're often, you know, a lot of data and how do you deal with keeping servers and keeping things online and keeping it available, especially as things scale. So there's these different types of problems as well. And certainly some people gravitate towards one end or,

[00:07:42] Matt Baker: you know, one or another. Yeah. I, if you were to ask me, I would say I enjoy writing back end code more than front end code where front end code is some CSS and some back end code is like a web server. I've also found some pleasure in writing front end code in some frameworks that have like good state management with like unidirectional data flow. I think that equates to a lot of pure functions. And I think pure functions are fun because it's just data in data out and really in a simple way. It's fun to TDD, there's something about that that I just enjoy as I've been trying to think like, well, what is it that draws me to that over the front end? And I'm not sure the biggest thing I'm coming up with right now is that visually, like I don't get a lot of pleasure out of designing interfaces, like what, what colors go where, where should I place the buttons? How big they should, should be. Those aren't interesting things to me. I do them all the time, of course. But it's like, it's just something I have to do. It's not something like you'll find me enjoying, but a few, start talking about like a function design with me, like what kind of parameters should this function have? Or like, what should it be concerned with? What should not be concerned with? Then you have all my attention. And I'm excited to be working on that.

[00:08:55] Dave Adsit: I think one of the interesting things about front end development, specifically in a web context is that we've gotten to the point where front end web development has basically become client server development with a more modern toolkit. You can have some extraordinarily complex involved single page applications using some of those frameworks you're talking about, Matt, the ability to build and maintain that type of application is certainly non-trivial. It's definitely that it's an expertise developed over time, right? It has different limitations. For example, they are single user, right? You might not think of your application as a whole as single user, but in the context of the spa, you've got one person thing to do. And then they might be interacting with other people through the back end server architecture, right? But you're thinking about different constraints than when you're talking about an application API cluster that has to serve 10,000 concurrent users. It's a different set of constraints, different things to think about. And I mean, I have to agree with you. I feel like my efforts are misspent if I am doing a lot of UI-leveling. I feel like I'm not good at it. I feel like I am reasonably okay at user experience design, focusing on what the user needs, what they need to do, making things visible, hiding things that are irrelevant, et cetera. All of that, I feel like I've got an okay grasp on. But if you're like, and now the colors, I'm like, and I'm out.

[00:10:36] Allan Stewart: You're one of those developers who poisons the other people, like the Dilbert cartoon about user interface poisoning.

[00:10:42] Dave Adsit: I was literally just thinking that. And yes, yes, you would get user interface poisoning if you used one of my applications for too long.

[00:10:51] Allan Stewart: I think it's interesting. We think a lot about the differences, but there are also a number of ways where these two different aspects or disciplines within programming are very similar. Both of them can get very complex. Both of them, you need good naming, clean coding principles, more and more testing. We're seeing that becoming increasingly important. We can't just say, well, just look at the page and then we'll know if it works because the page has all kinds of functionality to it. There are definitely things that unify the two. And hence you come to this concept of a full stack developer. And really that speaks to this desire that some teams have to work on both sides of the fence, as it were, that you can work some in the front end, some in the backend. And so really that comes around to an organizational Why would you want to combine those things? Why would you want to have a full stack team instead of a front end team and a backend team? So for me, that comes back to the concept of

[00:11:54] Dave Adsit: getting the right software done sooner. Even if I don't have full stack developers, but I do have a full stack team, that means that I can let that team go do their work from ideation to delivery. If I have teams of developers who are specialists, now I have to coordinate. And not only does that, do I have to pay the higher costs of coordination, but everything is going to be delayed. And we're going to have a less good software overall because it's going to be harder for feedback to go between those two independent groups. So for me, full stack is about that organizational design and the If you go to the concepts of resource efficiency versus flow efficiency, having all of your front end developers in one group with a queue of front end work in front of them, that is a good way to keep your expensive front end developers working exclusively on the thing that they're the best at all the time. And you could do the same with your backend and the same with your database and the same with your infrastructure and the same with your PMO. I know you guys both love PMO. But at the end of the day, you're not likely to deliver software very often, which means that you're limiting your learning.

[00:13:22] Matt Baker: For the record, no one here loves PMOs. Dave's a dirty liar. What's interesting for me is like the stages these orgs go through to get to these points where they're either like a full stack team to a feature or an area of the product, or they go a different route and they have front end teams and backend teams. Trey Lockerbie , MD, MPH, I think every company, not every company, but lots of companies start out with a small team and oftentimes it's one person that starts writing code for a company and then slowly it expands out to maybe a team. This isn't even a discussion at that point. It's just people are working on everything together. But then at some point, ownership of the application or whatever it is your shipping starts to segment because it can't all be owned by one team anymore or one person. So you're faced with this decision. And then every time that happens, you're again faced with this decision. I think it becomes most acute when you try and push work through the system and you see it get hung up because you need some CSS done and the person doing CSS is working on something else. Or you need a database tuned or stored procedure written. I don't know. And the person who does that is else. Jeff Bullas Then you get drawn to this idea that you can form teams of specialists and then you'll never have to wait for a database specialist again, or you'll never have to wait for a CSS wizard again. You start to assign your work. A feature then becomes a thing that needs to be touched by n number of these teams. Because to ship a typical feature, often you need a database, you need a front end, you need some server code. Jeff Bullas If you separated your teams into database front end and server code teams, then it's got to go through each of those. And I think that's the coordination that Dave was talking about. And that handoff, at least in my experience, that handoff has never been as cheap as we think it is. Anecdotally, it's almost always been better to put all these people on one team and form this full stack team around a given area of the product, like a goal, right? I need you to accomplish this goal as a company, as opposed to signing n number of teams to that goal. Jeff Bullas And I don't know why that is. I know there's lots of theories. Jeff Bullas And surely we could talk a lot about flow efficiency here and queuing theory and all sorts of interesting things to try and explain why it seems to be that when you take a team and form it with all the expertise necessary to accomplish the team's goals inside that team, they tend to perform better. But that's definitely been my experience. That being said, there's still groups and companies that are very successful with front end teams, back end teams, or some variation Jeff Bullas I've worked in one of those places. It's just, it's always felt a little suboptimal to me, like, and most acutely felt when you're waiting for the CSS person to come out of that meeting where they're going to have to come in context switch with you and then try to build up your stack and be effective with you. It just that trade off or that like handoff. Obviously, I've maybe shown my cards here that I definitely favor full stack teams. And just in my experience, I was able to move feature squared.

[00:16:38] Dave Adsit: Preston Pysh Which really shows your cards about what it is you value. You're talking, Jeff Bullas about valuing getting things done versus squeezing the most out of every individual specialty.

[00:16:50] Allan Stewart: Jeff Bullas And it's something that we see in the industry as far as how we construct our teams. It seems like 10 or 15 years ago, the mode was that there were so many different specialties. There's development, which is separate from testing, which is separate from project management, which is separate from security and operations and all these things. Then the agile manifesto comes out, and we start talking about collaboration more. We start talking about cross-functional teams. I think that this is just kind of another step on that journey or a point in that spectrum, as it were, between everybody working separately, focused on their specialty versus working together. So you get concepts like DevOps. You get concepts like having developers writing their own tests and making sure that they feel some ownership over, does it actually work? Jeff Bullas Yeah. Uniting the front and backend teams is a sign of that happening. But I also think that there are these other constraints that come into play. For example, if you've got an application or a product that you want to serve a native iOS app, a native Android app, and there's a web experience, and it's all powered by the same backend, then it's really difficult sometimes to want to combine all of those specialties into one. You say, oh, well, couldn't we just, we can just have a really good API that all of these can talk to. And that way each front end can have its own specialty. It can do its work and they can focus in on the details of what it means to write a really good Android app. And another team can specialize on creating that API. But it also means that any given feature that you want to release is going to have to go through multiple teams, just like you were saying, Matt. There's always a higher coordination cost and transaction

[00:18:42] Dave Adsit: costs there than we realize. You've got me thinking about the architecture elevator to some extent. This might not be the right application of this, but when we talk to architects, we often talk about thinking of a problem for multiple layers of abstraction or at multiple layers in the stack simultaneously. And if I only know the front end, I can't consider the impact on the backend or the database or the underlying. So the more of the system I understand, A, the more places I have that I can apply leverage to solve the problem. But B, the more I can build a solution that meets the overall constraints. I mean, how many times have we built a beautiful front end that we just can't implement a backend to serve it effectively or vice versa? We've built a backend that it is glorious, it's got all of the design patterns right there. It's got every bit of inversion of control and all the testing. And then when somebody goes to use it, it is impossible because they have to call three endpoints simultaneously and pass them the results of each other or whatever. There's a lot of things that if we're not considering the constraints of the full stack of code, like front end, backend, database, infrastructure, if we're not considering all together. To some extent, we can get ourselves into traps that we can't get out of.

[00:20:18] Matt Baker: Yeah. It makes me think like, how far can you pull this idea? Like what about non-tech roles? Should we have salespeople be on a full stack team? Should we have marketing be on a full stack team? To me, it's an extension of this idea. Like how good are you at forming teams with every expertise necessary on the team to ship an idea? And I think traditionally we think about shipping as like post-sale. But what if we included them too? And I wonder if we would see, or I don't know what we'd see. I know I'm working at small startups. I've worked at some of those. This happens kind of by default, right? There's one salesperson, there's one marketing person. Those are the people you go out to lunch with and you all work together and you're kind of a team. And oftentimes you're fortunate enough to be focused on a small set of things.

[00:21:06] Allan Stewart: And there's only eight people in the company anyway.

[00:21:08] Matt Baker: Yeah. Yeah. And then as the company grows, that changes, right? But I do know, working in those environments, those are the times where I feel the most productive. Productive in a sense that like, wow, the company is like accomplishing a lot, right? So going back to what Dave was saying, it's not necessarily like I feel like a utilized resource productive, but rather like day by day, we're moving the company forward rapidly. And I think we all know that as like growth comes, that slows down and we could argue about why until we're all blue in the face. But it might be kind of fun at a bigger company to form this full stack team out of everything necessary to go and accomplish some new rollout of something. And I think that would include sales and marketing. And it'd be kind of cool to watch all those groups collaborate hour by hour, day by day.

[00:21:53] Dave Adsit: I think that to some extent, that is what a product marketing role becomes is bringing that marketing mindset closer to your product development team, maybe onto your product development team to help you sell or understand the message that you're sending to your product and the way that you sell the product that you're building. And so I think that you're onto something there. I think that you might struggle to get certain developers to work effectively side by side in the same room with certain salespeople, but I encourage the experimentation. Like I've been at small startups as well. And that, that, that is how it goes, right? The people are so key and all of them are working together towards one goal. I think, this is part of why we talk so much about alignment in business circles, right? And why we, why we talk about things, tools, technologies, if you will, like OKRs, objectives and key results. What is our objective? We have one or two at the most objectives and everybody in the company is aligned around those objectives. They're doing things to support those objectives. We're all, all of us, development, op, sales, marketing, whatever. We're all being measured on these three key results. And so now we're bringing kind of that single team, whole team mindset to a larger organization through the imposition of some of these tools or techniques. Not that I'm necessarily an advocate of doing OKRs and not that I've seen OKRs done horribly many times, but, but I think that there's something there that kind of brings that concept of not just full stack developer, but full company developer, full company mindset team. Let's all be aligned around one objective as opposed to each group going off and setting their own goals and going in different directions.

[00:24:01] Allan Stewart: And I don't think that there is a perfect answer for this because you can't get people who have all of the specialties trying to learn a lot of things. Inevitably it pushes something else out. If I'm spending a lot of time in the front end learning about front end frameworks and certain patterns that happen there, then I get a little bit rusty in my backend skills. If I'm really learning about product management techniques, then I'm not writing code. Or if I'm doing code, then I'm not thinking about sales. And so it's hard to get a person to be able to fill all those roles. And there's a lot of different roles. And so, you know, you have to kind of choose how much of each specialization do you want on the team so that the team can operate well. And we've seen some of the problems that happen when you silo. If you say, okay, all, you know, engineering, QA, ops, all these things are separate. There's the handoffs, there's the throwing things over the wall, not working in production. It's like ops problem now. All those kinds of memes, like we know the pain of that, but it's very difficult to get people together and even just the number of people that you can have on a single team. The communication structures break down really rapidly. The geometric networking problem that when you only have four people on a team, then there's only a few ways that each person can interact with each other person. But when you have 12 people on a team, it gets too big. And you start forming these other kinds of communication structures that are not perfectly distributed.

[00:25:38] Dave Adsit: Yeah. I should be the leader here at the workloads. I should be the leader here at the workloads. I should be the leader here at the workloads. I should be the leader here at the workloads.

[00:26:02] Matt Baker: I should be the leader here at the workloads. I should be the leader here at the workloads. I should be the leader here at the workloads. problem of how do you take this like magic that happens at a small startup where what we've been talking about and how do you replicate that as the company or how do you keep that maybe as the company grows or or how do you go install that in a company that's lost it i don't know i i know we've seen a ton of like cottage agile industry stuff come out of here like safe and those things and as an attempt to like scale this idea i've never seen one of those work well um and i have tried a few of them or like had them try it on me let's try it's more more accurate um you were more of the guinea pig and less of the scientist yeah more than definitely like less of like the voluntary guinea pig more like they do you like your job then you'll do it kind of guinea pig

[00:26:58] Dave Adsit: hopefully they pass that through the uh the institutional review board for testing

[00:27:03] Matt Baker: yeah but i but i wonder of course like i can't i can't help but think like if there's a solution to this problem of like uh preserving this full stack mentality as the team grow as the company grows i have to think it looks like kind of a maybe like a recursive or a self-repeating model right where there's like uh and what changes is the degree of scope that the the thing has so like maybe you have a team then a team's within an org and an org's within a and it all rolls up to this company how big i don't know but um i wonder if there's just this i'll discover at some point in the future where there's an optimal way to sort of recurse the size of the org um and then have different ways of operating at those different levels and i don't know i like i i can't believe all the crap i just said that like that's a lot of magical thinking but for some reason it sticks out to me that the best designs have this recursive or the self-similar quality to them and what changes is the scope and so i wonder if we'll we'll see something like that emerge with the north and we see it a lot in nature so i mean it's pretty

[00:28:08] Allan Stewart: successful in nature right i mean a whole tree looks a lot like a branch looks a lot like a twig yeah

[00:28:14] Dave Adsit: well i think there is something to that and i think that we as an industry don't necessarily have deep enough knowledge yet to make it effective i think that you know as much as we say you shouldn't reach for technology to solve a people problem sometimes you need technology as well and there's probably a technology or an architecture that enables these independent self-replicating type teams and enables these full stack developers to operate successfully with their product manager user experience designer their product marketer their database design database management person they're like the whole layer of ops to to front end and having these cross-functional teams and cross-functional developers or full stack process that you have to put in place to make them effective you know at a very small scale it's just the whole company and we're all doing the same thing but then like you're saying matt as you start to scale out there has to be an underlying infrastructure to support that or an underlying architecture that supports that and and i think that that's a problem that we are working towards as an industry but not one that we have solved yeah and the the variants of like

[00:29:36] Matt Baker: are rather the different attempts that are out there i think have a lot of impact coming back to this full stack engineer have a lot of impact on on whether or not your org even supports full stack engineers right we've already talked about if you choose to like split your org design based on these specialties as opposed to something else at that point you've made your decision to form teams around front end and back end and and so on and then or you form your teams around products and features and you get more of the full stack but for someone going into a company some of these things do matter you look at the composition of the company and that can tell you what kind of engineer you need to be there lately i feel like i shy away from companies the group around specialty myself like at their front end back end but it's it's actually been a while since i've worked in one of those kinds of companies so maybe it's time to go try one now but what's interesting right now in this conversation is that i wonder how how many companies get to this design intentionally and how many companies get here just by like uh they just threw it in reverse and they based on that dynamic it's interesting thing about its implications on like what kind of engineers you can hire and what type of people are going to want to work at your company and if that's true then maybe you might benefit from some more intentionality in designing your org to support whatever sort of philosophy you want to promote yeah well and if you think about some of

[00:30:55] Dave Adsit: the technical constraints a web application is the perfect place for a whole bunch of similar teams repeated horizontally the web is just hrefs and html and routing with web parts or URL parts or even third-level domains. And you can put a whole bunch of things together and make them look like one cohesive unit on the web. But what if you flipped the problem and instead of having, how can I take all of these engineers and apply them to one really big web problem? And you said, what if I have to solve the problem of delivering my product on 300 different devices, but it's literally always the same product? You're going to come up with a different technical solution. You're going to come up with a different arrangement. If you're that company, maybe that company delivers, I don't know, streaming video over the internet. Maybe you don't need a bunch of full stack developers. Maybe you need a whole bunch of developers who specialize in this particular iOS device, this particular flavor of Samsung device, this particular flavor of Google Android device. And then you also are going to need a group that's going to be able to deliver that backend. That sets you up for a different constraint and you're going to extract different patterns from that constraint.

[00:32:21] Allan Stewart: Yeah, looking at what your problem is and how you want to organize your people and what architecture you build. That all wraps together into Conway's law. So a lot of times we see people in various companies try to change their software architecture, and it fails because they're coupled to their org chart. And they're not realizing the impact that that has on the software and on how it can get built and what kinds of structures get created. Or sometimes we see people pulling the inverse Conway maneuver where they say, this is the architecture we want. And so we're going to change how we set up our teams to support that instead. There's really some interesting connections there, but no matter how you do it, I think one of the keys is, especially for software architects is figuring out what does this business need? How can we organize ourselves? How can we create things so that we can be flexible in the right ways to enable business value, but also being rigid enough in other ways that it can support the company. And you're not diving deep into like building frameworks like we talked about on a previous episode where, oh, well, we'll just solve this by making the one true framework to rule them all. Because that also has its own set of problems. And so coming back to those constraints, like what are you trying to do? Or even are you in the same organization, right? I know Dave has railed B-Times on GraphQL, but there are maybe are situations where that makes sense, right? If you're GitHub and you have no idea how everybody in the world wants to use your APIs, then it might make sense to spend some time building out a really flexible API, that can work well for a lot of different groups. Because you don't care if it works really well for any one particular use case. You care that it works really well for a lot of different use cases, which means that you're always somewhere on this spectrum between being completely generic, which if you go too far in the completely generic, then it's like, it's not right for anyone. But if you're too specific, then you can only help one person.

[00:34:31] Dave Adsit: Yeah. I like to think that GraphQL, and backends for frontends are two reasonable patterns with different scope of applicability, different context of applicability, and they're on opposite ends of the spectrum from each other. If you're building a full stack team, then paying the cost of implementing GraphQL is unnecessary. Because you have a full stack team, you're building a frontend, and then you build a backend to support that frontend, and a database, et cetera, right? You've got one group and you're deploying all of that as one, one cohesive unit. If on the other extreme, you are building one API to serve dozens, hundreds, tens of thousands of users with specific needs, but all constrained within the scope of that data, then GraphQL is a good solution for that type of problem. Like everything in software, you need to find the solution or the pattern that applies in the context that you have, not the context you wish you had. So I typically try to hire full stack developers who are going to work with a custom frontend with backends for frontends with, you know, the backend is built specifically to support that front end that they are also building and they're deployed together because that's the scale, the scope, the type of application that I'm building. And that is a super effective way to iterate on that problem. If I'm building public APIs for people, to consume, I probably don't want to change my API two or three times a day as my teams release, because that's a really good way to irritate some enterprise customers. Oh, you're calling that end point. We haven't supported that end point since Thursday.

[00:36:22] Matt Baker: So if I'm like a new engineer or if I'm a engineer who's trying to decide what part of the stack they should work in, one of the things that sticks out to me, I think is it's probably good. build something yourself, spending time in each areas of the stack and just get a sense. I suppose my personal opinion on this is that it's good to at least have a familiarity with all these specialties that are adjacent maybe to the specialty you choose. So if you choose front end, it's good to know how to write some server side code. It's good to know how to ship an API and build a database for it. If you're building kernel software, I don't know how this applies. I'm sure there's full stacks in there as well. Like people who, um, um, ! Write code that interfaces with registers are probably, probably have like a holier than thou attitude than someone else. I don't know. But I think whatever area of the software chain you're in, at least some familiarity with the specialties that you regularly integrate with seems valuable. So apply that, you know, however you will to, to wherever it is you work.

[00:37:27] Allan Stewart: And I'd extend that to include other things, product management, testing operations. That's kind of the basis of the whole dev ops movement is that we want to have interactions and collaboration and some shared understanding between these different groups. That's what dev ops is about. It's not a title that you slap on to a person that who's basically an operations guy that you put onto a developer team. Cause I've definitely seen that happen and it's better than not having them there. It's better than having the wall fully constructed between the two and you're just throwing stuff over. But, but still it's, it's not the same as the cultural evolution of dev ops and dev ops is kind of morphing to the point where it's, I don't even know if that's, that's right. At one point I heard a gene Kim say that maybe it should be star ops. Cause we want to bring all the specializations together with ops. But that's cause he was coming from like this operations mindset as he was talking about it. So maybe it's just start out star. Like everybody has to know a little bit about a lot of things. I like how you put it, Matt, like the, the things that you integrate with regularly, those are the ones that you want to have some understanding, some empathy for so that you can understand why they're making those changes, why they're doing these things to you. That seems so terrible or why they're mad at you because of what you've done.

[00:38:50] Dave Adsit: I like the analogy of dev ops because in the operation space, it's so big that everybody has a specialty. You know, the longer somebody has been in that space, the more things they know, Right. And I think the full stack development is kind of the same way, but focused on the coding side of things. And I think there's something to what you're saying there, Allan around there was SIS ops. And that was a different group, different department, different CLO. I mean, they were under the CIO, not even a CTO. And so you didn't talk to them and you gave them things and they hated you for it because they didn't work when you gave it to them and they had to support it somehow. And production. And then we moved to, we kind of tried to move down the spectrum to this dev ops where it's developers doing ops on a team, delivering value together. And I've seen a lot of groups that have kind of ended in this, what I think of as captive ops, where it's like you found a wild ops person and you somehow managed to capture them onto your team. And now they're held, held potentially against their will. Still doing inter interacting primarily with these folks. You're now our ops person. That's why your title is dev ops engineer for a while. I was like, dev ops is the title you give yourself when you want to get a 15% raise. Yeah. Yeah.

[00:40:18] Matt Baker: Yeah. Like dev ops is how the ops like community writ large got a bonus.

[00:40:25] Dave Adsit: And good for a good forum too. Yeah. But it's the goal is, is, is that we're all collaborating together to deliver this value. And that's going to require a bunch of specialties, each doing the best they can in their specialty. And sometimes it might be one person who has two or three specialties. We want to find all those full stack developers so that we don't have to find front end developers who know how to work effectively with back end developers who know how to work effectively with front end developers. Right. We want the full stack developer. Cause now you're considering, you know, but we also want you to be thinking about the ops impact. And so bringing all those things together on one team, whether it's individual people filling different titles or whether it's individual people with multiple roles or specific roles, even it's like the idea is to build an effective team by considering all the things necessary for that team to deliver their product. Well, and you know, you'll find over time, that you might've missed one and then you bring them onto the team. Maybe you didn't have a product marketer. Maybe nobody on the team knows how to write good ad copy or send a bulk email. And you have to go find somebody who can help with that and learn the constraints that they're operating under.

[00:41:48] Matt Baker: It's interesting watching the twists and turns our conversation has taken where we started out talking about like a full stack web dev. This is going to be super abstract. So warning, but it's fun to also, I also think about some other skills that come into a full stack engineer, given like the way we've stretched this definition. I think you could also include someone who knows how to talk to people, someone that understands like the perils of estimates, someone that one thing we've been talking about here today is someone that at least has an opinion on how to move value through an organization they've learned to, or they've realized rather in their career, like what's valuable is me to do work that translates into dollars for this company. Assuming that that's your situation again, like I, I we've stretched this definition a little bit, but the point we're at now, I would include these in this idea of a full stack engineer. Like maybe you're not, you know, the best communicator in the world, but you have to be able to talk to people, especially given like the team dynamic we've been talking about where you're interfacing with so many people. And you have to understand like that shipping early and often, or at least you have to know when you should be focusing on shipping early and often you have to understand whether or not you should refactor or rewrite. I don't know. All these things, all these things that you pick up along the way that, that make you better engineers that are definitely not technical. Anyway.

[00:43:06] Dave Adsit: Yeah. I'm thinking back to your question about sales. Do your full stack engineers, do your full stack developers know the go-to-market strategy? Do they know what they can do to help with it? Were they all just triggered by me mentioning the go-to-market strategy? Maybe, but it's important if you are working in a business, it's important to understand, like, how does this business make money? And am I contributing to that? And if what I'm doing, isn't contributing to that, should I be doing something else? Or are we intentionally doing exploration in this area, knowing that it's not currently valuable from the perspective of dollars coming into the balance sheet?

[00:43:50] Allan Stewart: To me, what you were just describing, Matt, is basically the software craftsmanship manifesto. You should be able to be part of a community of professionals. And that doesn't mean only just other coders. You need to be steadily adding value. You need to have productive partnerships and of course, well-crafted software. One thought I had from something you said a little bit ago, Dave, that has helped me think about some of these scenarios is an idea around API categorization, which is basically the concept of you don't have to just have one API. There are different consumers with different needs. And so if you've got a full stack, team, then you might want to have an API that changes as rapidly as your product changes. You're the only consumer of that API. So the front end code that you write has a bespoke back end, right? Does that back end for front ends idea? And so it can change as rapidly as you need it to. The endpoint that you deprecated on Thursday won't be called by anybody else because it's just you. But there's another category of APIs that is the public facing developer API that anybody, with an account to your system can use. And that one has to change at a very different rate. You don't know what those other people are doing, and you may not even have a good way of communicating with them. And so you have to have a different kind of contract with those people so that you're not breaking the things that they're building on top of your API. Because honestly, you want those to work. You don't want people to stop using your API and stop getting that value and move to some other platform. There's probably other types of APIs that you can use. Don't make that public facing API that external entities use be the same one that your mobile apps and Android apps and iOS apps are all connected to. Because they have different needs. They change at different rates for different reasons. That's one of the strategies that I think can really be impactful for you to create a better experience for everybody rather than trying to just make it generic and hope that it meets everybody's needs. I love that.

[00:45:59] Dave Adsit: I really like that direction. I like to think about three different broad buckets of APIs. There's the API that my team builds for us to consume ourselves. There's the API that my team builds for customers to consume. And there's the API that my team builds for the team that sits in the next pod to consume. And each of them is going to have different types of constraints around changes, etc. If you're building enterprise software, your customers are probably not going to want you to change. And if you say I'm going to build one API and I'm not going to change it more than once a quarter, that really hampers your ability to do anything new and fun with your interface. You know, your web interface is not going to change very often if you only update your API layer once a quarter. But just because you change your front end and your API that supports it every day. That doesn't mean that the team in the next pod over wants you to change the API that they're calling every day. Because they also have their own work, which is different than yours. But they might want it more often than once a quarter, like your external customers. There's probably a lot of nuance and a lot of other categorizations you could come up with. But I think of those as like three primary buckets. And a full stack developer should have the ability to understand and understand. Prioritize changes along those three different layers based on understanding the consumer. Understanding the go-to-market strategy. Understanding the operational deployment strategy. Understanding that, oh, we're doing a SOC 2 audit. And so we're not going to let you provision like 50 new servers today. Everyone who works in ops and DevOps and the captive ops guys as well, they're all off doing a thing for the SOC auditors. So, yeah. So please don't request 50 new VMs.

[00:48:00] Allan Stewart: So it seems like to summarize this whole discussion, it's not really about front ends or back ends. Or even that anybody can really be the full stack. Nobody's making their own processors or writing their own OSs. And also applications that are on top of those things. But it's having an understanding of enough of the things that you are connected to so that you can be professional. So whether or not you are a full stack developer, it behooves everybody to think about the full stack at least from time to time. As always, we recommend that you join up with a community of professionals by attending a software crafters group or meet up near you. The Utah SC group at utahsc.org meets the first Wednesday each month in Draper, Utah. Maybe we will talk about full stack development with you there.