Why you should do web development full stack

I've been a professional developer for nearly ten years at this point and for most of that time I have been a front-end developer. This was kinda by accident; I left collage in 2013 with an ok amount of coding experience, but it took me a while to understand the mentality of being an effective developer. Somehow I got a internship with a shop that used Angular v1, and so before I started I wolfed down a egghead course and went on my way. About 2 years later, stuck with the worst jQuery spaghetti I will ever see, I learned React off another online course, spending my evenings it instead of playing Witcher 3. Even back then though, I knew TypeScript and ES6 were the future, so even though the course material was in plain JavaScript I was taking a lot of extra time to get TypeScript to get working.*¹ I started working professionally with React in 2017 but only started doing TypeScript in 2020*².

For that initial period I had been 'pure' frontend; I did my client-side JavaScript (with some early forays into SSR), used redux-thunk to fetch data, and otherwise made sure to be friends with the Java devs in the office to get the API blockers unblocked. The job I started in 2020 would be somewhat... different: I started my first day in the office in March already expecting to be put on WFH later that week. My second day in that office was in August 2021.

The new job had a fair bit of chaos due to the pandemic affecting it's business but the people working there were able to pull together to keep working effectively on Slack, GitHub and Google Meets. It was at this point I would be starting to make edits directly to Ruby on Rails*³ backend code (mostly controllers, models and GraphQL resolvers) as we had slower communication on Slack with the backend teams and sometimes writing up the API we needed and have the rails engineers review it was just faster.

Since then, while I've still done 70 to 80 percent of my work in browser-side code, I've dabbled in Express.js monoliths, Next.js API Routes, Drizzle ORM on top of Postgres (with some RLS shenanigans) and even a bit of Java Spring Boot recently. It's moslty the same goal; get my work done without having to wait on the backend guy. My managers, and the customers of the company, don't really care why something is a blocker if they don't get what they want/paid for.

And to be honest the split has gotten way more annoying then it used to be because of how unnecessary it is now. For a full-TypeScript house, something like tRPC or oRPC in a monorepo with the React front-end, using Tanstack or Next.js server functions in a Rails like monolith, or enjoying the elegance of the beautiful Convex is peak end-to-end typed DX. But even without those, any back-end these days can use OpenAPI to document there functionality and something like Hey API to generate the client SDK*⁴. GraphQL of course get this typed DX for free, and it's the one thing everything above realised should be copied for those that couldn't commit to the GraphQL church.

But even besides that, what do you think is faster if your a front-end dev twiddling his thumbs on a change to an FastAPI end point. Instead of a Slack message say "When will this be done?", what about getting Claude to make a PR to get what you need? It won't and shouldn't be merged as is*⁵, but to quote Cunningham's Law:

the best way to get the right answer on the internet is not to ask a question; it's to post the wrong answer.

Assuming you repeat each other's expertise and time*⁶, this should be a very fruitful exchange. But even leaving the AI out of it for a moment, the end-to-end typing to tools to take data out of one computer into another and have the client computer know what it is, complete with per-field comment, is stupidly powerful.

Point is, the old silos really don't make too much sense now. So whatever company you have:

• All engineers should have read-write access to all code they need to deliver irrespective of language, runtime or device location*⁷
• They should be able to take a feature and deliver it end-to-end
• Specialization and deep knowledge are still very important for the team as a whole to learn from and to set good standards, but:
• Everyone should be a bit of a "jack of all trades" to some extend. In the case of AI, they should still know enough of the whole system to prevent most foot-guns in tech that's not there "native" specialty*⁸

I honestly think you can only still run separate teams for both back-end and front end if you are a larger company able to put work into making the inter-team communication processes work and have solid processes around your OpenAPI or GraphQL layer to make the API layer as seamless as possible. Even then, it should be understood as a trade off between nimbleness and a more formalized SDLC prioritizing stability. Under 200 employees, you can't leave nimbleness on the table

If your hiring in this environment as well, especially if your gung-ho on agents, you also shouldn't be too picky on previous technologies as well. If a candidate knows enough fundamentals and is willing to not be a total elitist about there favorite language, they should be technically good enough*⁹

But yeah, just... write applications. Figure out how to collaborate with different people on applications. Figure out where an agent helps (or hurts) in the process. Just do things, I guess and ship.