I am a fullstack web developer.
Well, used to be. Back when I started, it was enough to know PHP reasonably, then a bit of HTML (v4), CSS (v2), and some MySQL. The complexities of HTTP were well hidden by the MVC framework I was using at the time (Nette), SVN was as easy as update, add, and commit and there was this shell script that deployed copied files from the repo to the vhost dir. This was enough to be productive and make something that generated profit.
You needed to decide whether to switch from the three column 768px layout to the trendy 1024px width two column layout. Fixed-width, obviously.
To be on the cutting edge and provide "interactive pages"1 you used jQuery, and partial page update utilising AJAX.
Your greatest enemy was the IE 6.
Nowdays? Well...
Everyone wants interactive pages expects interactive web apps now.
To provide, you need to grasp a JavaScript/ES interactive tech like React, Vue, Angular. Or all of them. You need state management, event handling, routing ... you are basically building an application with almost everything that desktop apps need in place. It's nothing like "web pages" 10 years ago. And the JS eco is crazy. You can code in several syntaxes, then transpile, preprocess, bundle, postprocess.
Responsiveness. You need to understand a CSS framework like Tailwind, Bootstrap, Bulma, Material. Or all of them. Pick the proper one. They come with Scss or Post CSS to master too. Your apps should look good on 2 inch wide phone noodle-screens with holes in them and corners eaten by mice, 32" 4k desktops and 80" TV screens alike.
As a fullstack developer, you need to understand search engine optimization and optimize page load speeds. You did need to optimize in the past, but it was relatively simple because most of the heavy code was server-side.
Once you have a shiny single page app drafted, you need to teach it to talk to your backend. Here you deal with the complexities of HTTP protocol, RESTful APIs or the overestimated GraphQL. On both sides.
Almost forgot about databases! While relational SQL ones have not changed so much in principle, you now have a ton of NoSQL flavors and you should at least understand when to use or not use one.
Once you have written a piece of code, you need to understand Git. And GitHub, GitLab, BitBucket or whatever your teams use (merge requests, pull requests, you name it). Git is awesome. But it is fundamentally more complex too, being decentralized. It's not just the commands, it's branching strategies, rebasing, merging...
And then you need to deploy the code. Everything is in the cloud2, you need specialized tools to deploy your work. No longer is FTP enough. CI/CD, Docker containers, lambdas, buckets. You need to fiddle with that too.
You need to set many of these things up before you even showcase a working draft.
They call it DevOops for some reason. I've had most experience with the Oops part so far.
As a fullstack developer, you, my reader, you are expected to master all of that.
Sure.
...
Who are the mythical fullstack developers these days anyway?
I would estimate the number of tech and tools I regularly use for development has doubled over the last few years, and it only seems to be gaining momentum. I wonder what my dev routines will look like by the end of this decade.
I'm not offering any solution here. I just wanted to put these thoughts on paper. So that I can laugh when I stumble on this article in 10 years or so.
Top comments (2)
These are exactly my thoughts about the “fullstack developer”!
In my opinion, there are 2 kinds of them:
The first kind are super skilled developers with most of the knowledge you described, I’d call them gods of developers and I presume the ratio is 5 %.
The second kind, well… those people have sufficient knowledge but are not experts in any of the listed fields.
It’s a tough question: Is it better to be sufficient full stack dev or expert in some particular field?
From my professional point of view, it is very useful to have at least one area of expertise, which clients with special needs will seek and value accordingly.
I, for instance, am mostly able to create a whole page, with modern JS, SPA and stuff, but would never be able to compete with frontend devs. However, being hired for PHP backend stuff and still being able to understand frontend development creates much less backend-frontend friction, because I am better able to understand what the frontend devs need or expect and am also able to help them draft stuff they polish afterwards. Same goes for devOps and other areas.
So I think it is good to at least try to understand what "the others" do and ditch the hands-off approach some devs tend to favor, as this can help bridge the gap between different areas of expertise.