On today’s episode we chat with Mrinalini Sugosh, Developer Relations and Community Manager at CKEditor and TinyMCE. She discusses how today's full stack developers have to master both front and backend technologies, stitch the two together, and sprinkle in adjacent skills like data analysis and security compliance.
From her early days coding on a TI-84 calculator, to working as an engineer at IBM, to pivoting over to her new role in DevRel, speaking, and community, Mrina has seen the world of coding from many angles.
You can follow her on Twitter here and on LinkedIn here.
You can learn more about CK editor here and TinyMCE here.
Congrats to Stack Overflow user NYI for earning a great question badge by asking:
How do I convert a bare git repository into a normal one (in-place)?
[intro music plays]
Ben Popper Maximize cloud efficiency with DoiT - an AWS Premier Partner. With over 2,000 AWS customer launches and more than 400 AWS certifications, DoiT helps you see, strengthen and save on your AWS spend. Learn more at doit.com. That’s d-o-i-t dot com. DoiT - Your Cloud Simplified.
Ryan Donovan Welcome back to the Stack Overflow Podcast. I'm Ryan Donovan, I edit the blog here at Stack Overflow, and today I am joined by a great guest, Mrina Sugosh, who is Developer Relations Manager at CKEditor. Today we're talking about the evolution of full stack engineers. Welcome to the program, Mrina.
Mrina Sugosh Thank you so much, Ryan, and it's really great to be here today.
RD So at the top of the show we like to ask everybody, how did you get into software and technology and how did you get to where you are today?
MS My story started way back in high school when I actually had this TI-84 calculator, and I was coding on that calculator because I hated doing math and I just wanted to make my life a lot easier then. And then I realized I could do more than just math on a calculator when I started doing things on the computer. I started with C++ as my first language back in the day and slowly moved into front end which is where I really found my love for front end with Adobe Dreamweaver back in the day and things like that. And then I chose to take a technical path in college. I went to school for computer science and got a job at IBM Cloud where I was a full stack developer working on all parts of IBM Cloud monitoring. I worked my way up to senior engineer, and after that moved into developer relations at DigitalOcean– well, developer marketing at DigitalOcean, and now DevRel here.
RD So we've been talking about full stack since I've been at Stack Overflow, but it's always been sort of like you do the front end and you do the back end. What does full stack look like today? How has it evolved?
MS I would say that today we still have folks doing the front end and the back end. But how I would say full stack has really evolved is in those startups and smaller companies where you have this limitation of resources, and you see that there are developers out there who are not only specialized in a front end or back end, but they can do both. They can handle both the client side and the server side tasks, and if you ask them to set up an application end to end, or if you assign a ticket for them to, let's say, fix something in the data pipeline, they understand how to do that, but at the same time, the next ticket, they can also work on the front end. And that's just a very valuable resource if you think from an engineering company perspective, because even if you're a data scientist and data engineer today, you need to understand how to visualize it. And there are libraries that make it simple like Streamlet for those data folks out there, and that enables them to just be that full stack engineer.
RD The front end is sort of an entry point in development for a lot of people, and then they sort of pick up the back end. We've talked to Ryan Dahl who wrote Deno and Node.js before that, which is a JavaScript server-side server. Do you think the fact that front end and back end are the same language now in a lot of cases, does that make it easier to be full stack?
MS Yes. I do think it makes it a lot easier. There is less of a distinction on what you need to learn, especially if you're creating something like a web application, to understand what Node.js needs. If you understand JavaScript in general, you should be able to code in Node.js, as long as there's the REST APIs and other sort of basic functionalities that you need to wrap your head around. But that just sort of comes with the learning curve. So yes, I do think that the technologies these days, as you mentioned, Node.js is a huge one, and ExpressJS even on top of that, are really revolutionizing the way even I have coded before. Because back in the day, you were using PHP and things like that, and now server side things look like Node.js. So I do think there's a huge difference in where the technology has come.
RD And I think on the other side of that, with these big frameworks like Angular and React, the client side has gotten heavier on the application too, where you're building a lot of the application there too. Do you think there was a point where the back end was less focused on because of that?
MS I think there's still a lot of work for the back end folks, because yes, there are capabilities today where you can do everything from the client side. I agree with powerful frameworks, but we also see this trend with these frameworks to optimize. If you do too much data pulling– and I used to work in cloud monitoring, so just imagine pulling data from hundreds of resources, plotting graphs, even if you have things like Grafana, it's going to take a lot of rendering time and space. So we see this evolution in the front end of lazy loading– only load the things that you want. We also see these things in front end technologies. I think it's in QuickJS that I was looking at where it loads very specific pieces, not components, but subparts of the components as you scroll on the page and things like that. So really you're trying to optimize the front end, but from a technical perspective, if you really look at it, is it safe to have all of your data on the client side, and do you even want to have that? And that's where I think something like GraphQL, which is a query language for API, you understanding even how traditional REST APIs work, you just need to understand how to query them so you can get very specific data on what you need to render. And I think a lot of web applications these days, yes, there's a lot of different things that you do in the client side, but it's also a lot of just rendering data, real time data and nested data. So using those kinds of query language APIs can be very powerful as well.
RD That's a good point. This is the age of data. With concerns around privacy and various regulation and compliance frameworks, securing that data is pretty important. So if somebody is moving from the front end to the back end, what are the sort of security things that they need to think about?
MS If you think about front end security risks, there is a huge slew of front end security risks: cross-site scripting, clickjacking, even CDN tampering. The company I work for is a kind of front end component company, and you often see that when you're selling a component for the front end, there's a lot of issues with cross-site scripting and being able to inject client side code. So if you ask me, if you're moving to the back end, just really think about when you're building out these things, what are you requesting, how is account information authentication handled? Even if you're creating a simple login page, these days you have things like Auth0 that provide authentication out of the box, so maybe think about using something built-in rather than trying to build it from scratch. I think that's what I would say, because there's just too many variables if you're moving from front end to a very back end-focused thing. So I think front end has a lot of security risks. Back end, you can really avoid a lot of those risks because you're sending requests through backchannels server to server. You're not getting any of those major risks compared to front end.
RD So if somebody is looking to become a full stack engineer, move from either front end only and pick up back end skills, or go from back end only to pick up front end skills, what are the sort of paradigms that they need to learn, skills they need to learn?
MS It really depends on where they're coming from the stack. Are they a front end engineer trying to learn back end work or a back end engineer trying to learn front end work? And I'll start with the front end. If you're trying to move into front end, let's forget the frameworks. Frameworks are just a wrapper, in my view, on JavaScript. So understanding core vanilla JS. If you can deploy a full application with vanilla JS, then maybe move into web components and really understand the core functionality of how things work on the web. How does it interact with the Dom? What does the whole tree structure look like? That's really core to understanding how the web works. Also, think about accessibility. I would really spend some time thinking about accessibility, because if you want to be a full stack developer and you're working for a company that's going to be big, cross browser compatibility is going to be big. And I think those are the things I would start with, and then of course build tools like Vite and things like that that are new. Start to learn them, start to understand how to set things up, and that would be where I start. If I was a front end engineer moving to the back end, then I would actually start, as you mentioned, with Node.js. It's the simplest thing to sort of transition and get your server up and running, server logic, handling requests, processing data, and all of that. And then I'd start working with some kind of database. I personally like flexible document based database storage. I love MongoDB. I use it for a lot of personal projects. And then also try my hand on other different types of databases. Data is big today, understanding how to work with a server plus a database I think is really key. And then connecting it all together, understanding RESTful APIs is great, but then how do you use something like GraphQL on top of that to make it faster. I think that's where I would sit as a back end engineer. And maybe if you want to get into deployment and things like that, start learning Docker, Kubernetes, one of the cloud services. You don't need to be a master of all of the cloud services. I think if you understand one of them, you'll understand all of them. They all sell the same services, just a different name.
RD I wonder if the front end engineer has some advantage just because some of what the back end is doing is server-side rendering. Is that true or am I missing something?
MS I think there's a lot more that the back end engineer does. I think there's a good part of their job that definitely does server-side rendering where basically it's the idea of your server rendering that page rather than your browser itself. You just send them the HTML content. While that's great, I also think that a lot of the back end can also be processing data. For example, when I was working as an engineer at IBM, we ran calculations. When you're monitoring, you're running calculations on loads and load balancer workloads and things like that and we didn't run all of those calculations on the front end. We actually had a service on the back end that we called to and said, “Hey, given XY input, give me an output for what the predictive load would look like.” Then that service kind of went on and did its own thing, and asynchronously, once we had all the data, we would say, “Hey, your new data report is ready for this specific instance.” There's computational loads that I think a lot of back end engineering work does. There's a lot of algorithmic problems, so if you take an algorithms boot camp, if you're not in college, if you're already an engineer, just taking an algorithms boot camp if you like solving those sorts of complex problems, I think that's also something that's really fun in back end engineering.
RD That makes sense with the extra processing. And I think a lot of it is that we're trying to make the front end as light as possible, because around the world, not everybody has the same capabilities to download big stacks of JavaScript. What do you think about edge deployment as another way to kind of speed up those web metrics?
MS So there's an interesting thing about edge deployment. There's always a fine line of overuse of edge networks. So I think edge deployment is definitely going to empower people to receive content or data faster because it's technically geographically closer to them. But I also think that with edge deployment, it was great when we used it for a graphical use case like a real time graph, but when you're doing some of these one-off services, do you really want to use that much compute on the edge? That's the real question. How much load would you want to put on an edge device? An edge device also has limited capacity, so you can say that edge can be a solution, but I think it's just picking and choosing. I still believe there's a huge use case for heavy computational work that should happen in the back end. And if it's an asynchronous report, why are we running it at the edge? Might as well send it back to a server.
RD There's been a few folks talking about edge and edge computing where it's like, “Run your AI loads on the edge,” and there aren't that many use cases for that besides real time image processing.
MS I would imagine IOT. That's also a huge catchphrase. I worked with IOT. I did an internship with a company called Whirlpool back in the day and they did a lot of IOT work. So if you don't know about Whirlpool, they're your washing machine stuff. And I remember they had this idea of, “Oh, once your washer is done, send a notification to your TV,” connected experience type of thing. Find out where you are and send a notification to that place, which is pretty cool. I could see a lot of use cases of that sort of computation within the house on the edge. And I'm wondering if you take that sort of use case and say, “Let's apply AI to it. Predict where they would be in the next five minutes,” and things like that. So I see smaller compute levels on the edge being powerful, but generative AI is still very computationally heavy. Well, not the mini models like GPT-4o mini and all of the Phi from Microsoft, but some of the large language models still need a lot of bandwidth so you're not going to be able to run that on the edge.
[music plays]
Ben Popper Hey there, it's Ben Popper. Listeners of this show are obviously interested in software, so I wanted to recommend checking out the Web3 with a16z Crypto Podcast. Brought to you by venture capital firm Andreessen Horowitz, which first coined the phrase ‘software is eating the world,’ this podcast is your definitive resource on the future of the internet, from the latest trends and research to insights from top developers, scientists, and creators. This show is about more than crypto and Web3. It's for coders seeking more ownership of their work, for business leaders trying to prepare for the future today, and for others trying to understand the next innovations and tech trends. Be sure to find and subscribe to Web3 with a16z Crypto wherever you get your podcasts.
[music plays]
RD Do you think there is a place for full stack engineers in larger organizations? So you mentioned earlier that it sort of came about because of limited resources, but if you have a team of hundreds or thousands of engineers, is it still worth being full stack?
MS Yes. I was a full stack engineer at an organization as large as IBM– IBM Cloud specifically. I think there is a huge scope for full stack engineers at organizations that are big because– let me go back to this. If you're focusing on a very specific thing like front end, let's say you're Meta and you have React.js framework to maintain, or you’re an open source project, then you would want someone to, if I say, “Style a CSS pseudo element with JavaScript,” they should be able to do all of that. But I don't need that technical depth of knowledge if I'm working for a larger team in a larger organization where my task as a junior or a mid-level developer is to get tickets done, get the job done, get the sprint moving. And if that's the goal of that organization, then I do think full stack engineers can be very efficient because sometimes sprints can be back end heavy. And I've had friends and colleagues of mine who have said, “Yeah, I think there's a lot of tickets that are lined up for us, but this is a sort of light sprint,” and you can actually get more value out of your engineers if they're full stack just by getting more things done is what I'd say. They would lack the depth of knowledge in those individual areas, and I really think it depends on the project that they're working on, and it's going to vary from project to project and how it's set up. If it's a concise enough project and the team is close enough in the sense that there's not too much time from getting all of your authentication set up for accessing some back end database and things like that, I think really it's going to be a lot more agile versus if you have a back end team and a front end team, there's coordinations of the tickets, there's a lot of testing, and then you have a whole set of QA engineers for both teams and it just multiplies how much time you get to production.
RD You talked about how full stack engineering has evolved today. How do you think it'll keep evolving? Do you think there'll be full stack engineers who are also data scientists, also database engineers, also SREs? How full stack can you go?
MS Ooh. I've seen teams of full stack engineers, especially at startups, who've been data science engineers, and data engineers, ML engineers, AI engineers. AI engineering is very much accessing AI APIs if you really think about it at the end of the day. It's a fancy way of saying that. And yes, you can definitely go into that depth. SREs is a very tricky place because I think SREs should still be its own team. I'm not sure if that's a controversial opinion, but they kind of identify and they are really on call for infrastructure and ops problems, and they're looking at incident reports and management and very quickly analyzing, “How do I revert a version?” and things like that, and I don't know if a full stack engineer’s role really fits into that. So maybe right before an SRE and QA team is where that role sort of ends. I've also seen teams do DevOps, so if you're interested in the orchestration, CI/CD pipelines, I think you can do that level of work as well.
RD Sort of a possible controversial question: Do you think AI will make it easier for people to do the full stack coding?
MS The answer to that is, “Do I think AI can code today?” and that's “No,” but I think AI can be a great assistant to helping you code quicker. I think AI makes you more productive. I use coding assistants all the time. Copilot is great. I do feel like I've been more productive. I've also used other coding assistants like Sourcegraph's Cody, which you can actually pick a very specific model that you want to code with, and they're pretty secure about your own data and all of that. But I think it has improved my productivity as a developer, especially as a dev advocate, getting out demos, just setting things up very quickly, it's been great. But I was also reviewing an article recently that we just tried to see if AI could come up with something for us and it just hallucinated. It came up with all of these configurations that just don't exist within the initialization. So I think we're not there yet, but maybe there's a future there where it could be your pair programmer companion almost. I don't think it's ever going to replace a full stack engineer, but I definitely see it becoming your own personal pair programmer.
RD Is there anything we haven't touched on before we go to the outro?
MS I would just say that if anyone is here listening to this podcast, I'm not saying there's a 100% move towards full stack engineers. I just think the role has become so much more prevalent in the industry than it was 10 or 15 years ago where there was definitely a clearer distinction. And make sure you continue to do what you're good at and what you're interested in because it's not necessarily always about industry trends, but it's more about what you're passionate about.
RD So basically not everybody has to be full stack. Just follow your bliss.
MS Yes. You don't have to be full stack. It's just a trend that's happening.
[music plays]
RD Well, it's that time again, folks, where we shout out somebody who came on Stack Overflow, gave us a little curiosity, shared some knowledge, and earned a badge for it. Today we’re shouting out a Great Question Badge: somebody who asked a question that got a score of 100 or more. And today's badge winner is NYI for asking, “How do I convert a bare git repository into a normal one (in-place)?” If you are curious about that, perhaps there's an answer there. I have been Ryan Donovan. I edit the blog here at Stack Overflow. You can find it at stackoverflow.blog. If you want to reach out to us, you can find us at podcast@stackoverflow.com. And if you want to find me, you can find me on LinkedIn.
MS I'm Mrina Sugosh, again. I am a Developer Relations Manager and Advocate at CKEditor. And if you want to find me, you can find me on LinkedIn, Twitter, Dev.to. My handle is @MrinaSugosh on all of them. And I write blogs, I write technical articles, I'm on podcasts, and I'm definitely at conferences, so if you happen to see me as a speaker at a conference, definitely stop by and say hi. I would just love to chat with you.
RD Well, thank you very much everybody, and we'll talk to you next time.
[outro music plays]