I am a Ruby Developer. I am a fullstack web dev. And I am tired of being one. I am also tired of being a business analyst and a manual QA at times. As years go by the industry is going deeper and deeper down the rabbit hole of developer-focused engineering process and developers go on to combine more and more responsibilities beneath the surface of single cranium.
Long time ago in the prehistoric Internet
There were DBAs long time ago, you are quite rare to find a beast like that in the shadows of cubicles nowadays. Indeed.com search yields 7k results on the term fullstack web developer and 40k for just web developer. The separate roles of UX Engineer and Frontend Developer are also slowly being blended together on the premise of working on essentially the same thing. More and more agencies are looking for people who can do both frontend and backend, also participating in the business requirement development, writing unit and integration tests, being everywhere and doing everything.
Cut the cost, take the rest
That seems like a great idea at first, a person knows and does everything needed from scratch to shipped feature, controlling the whole process. It is easier for the business: you need to check with one person and process of development does not get too complicated with 'who does what' issues, it also cuts the costs making a little tradeoff with quality and development time. Communication and context switching also don't influence the people anymore as they go through the whole process rather than picking it up from where their successor in the chain left off. That seems like a nice enhancement... ...if you don't know a thing about how those professionals you crammed into one person actually work.
Complexity strikes back
Backend development is a complex field, including understanding of network layer, the way servers work overall, deployment, AWS/Google/Azure services(they are vital to modern web applications), specifics of server application language and framework, protocols used, authentication, database connectivity and setup and a lot of other things. Frontend includes solid knowledge of web standards, quirks and oddities of particular browsers, ES5, ES6, CSS, HTML, frameworks, preprocessors, transpilers, build tools, UX, UI, networking from the browser perspective, browser storages, sometimes even specifics of mobile apps with Flutter, Ionic and React Native. Don't even get me started on business analyst and QA roles for they are completely different bowls or rice.
Each of this roles has its own learning curve and essential skills to master. You can't just expect a person to read a few articles or a book, write a sample app and start bringing a good result. The result will always be somehow substandard. If you hire a fullstack web developer, you don't hire an equivalent of two half-time specialists at once, you hire one normal and one impaired(in the best case, you may as well get the equivalent of two so-so half-time devs). It requires devotion and motivation to keep track and stay relevant and brilliant even in one field, put aside two or more. Time is finite. You cannot succeed in two unless you have no personal life and time for yourself.
Wider or deeper?
Don't get me wrong, I think it is good to widen up the field of knowledge and employ understanding of your parts surrounding to do a better job on your section, but making developers be Jacks of all trades directly influences code quality, choice of solutions and the future of the project developed. Space in our heads is finite. We may fill it in with either deeper and better knowledge of one or a few fields or start chewing information on the multitude of domains resulting in superficial knowledge of everything. This knowledge creates a bubble of confidence that unfortunately does not justify itself, resulting in worse solutions and reinventing the wheel/employing wrong technique/banging the nails with a microscope.
Not all cuts are equally healthy
Fullstack is interesting because is seems to be almost unique to the software engineering field. Other fields mostly have more division of labour, you don't expect the dentist to cure your heart and neurosurgeon to fix your hemorrhoids. The reason it is employed in software engineering seems for to be the fact of virtual and failsafe nature of the field. Your code quality does not directly influence the outcomes visible for users, so you can hack around with patchy solutions long enough before the thing falls apart(and frequently it does when you are not around anymore). Also, that idea seems appealing on the intuitive level for money spending, hiring person with broader skills(no matter quality) may look like doing more for the same cost.
We get mediocre solutions created by people who don't have enough expertise in the particular field to see the better way, with a sketchy knowledge filled with Stackoverflow answers and copy-paste. We get people who stay stale in their improvements, having to keep up with too many topics. We get the professionals that don't create amazing things because they don't have time to dig in enough time to actually create some value to the field. We get substandard products by lower development price that fades off after the bugs and lost customers come in because of issues the projects inevitably face when developed in such the fashion.
Fullstack may be worth it from the short-term economical perspective, but it is harmful for the industry overall and for the projects we build.
Top comments (2)
True. If you want to raise the bar on one particular field of work you cannot simply do lots of things and expect everything to be perfect. You need time to polish your quality of work and time to learn from other peers. Actually learning from other experts is the best way forward.
Take for example Typescript. It can be used plainly as it is just converting the existing JS to TS with the use of extra hacks or escape hatches to get by. But if you want to utilise it completely you have to understand the whole type system and how to properly assign types to components. You get substandard products when you just use Typescript as mere way to say that u use types but don't care about the type inference.
As another example take infrastructure and configuration management. Are you really confident as a developer that you can setup up a solid infrastructure deployment using the latest best practices such as Docker, Kubernetes, Packer, Terraform, reverse proxies, caching, AWS specifics,bastion Hosts, DB clusters, networking, VPCs, failover, backup strategies, business continuity plans, OS hardening, filesystems and volume management, secrets management and many other crazy DevOps tools? Those things take hell of a lot of time to do it properly and securely. You probably going to clone a ready made github project from some unknown dude and use that blindly.
When I see job descriptions blending all of those together I can see what sort of mediocre people they want (or Ninja wanna-bees that they think they know everything). That's BS, they probably have a system that now-one really understands and they want a saviour to help them and also knows how to code.
Rant over.
I can't really completely agree with the article. Having full-stack developer(s) on a project does not lead to a substandard product - but having bad management does.
In an early stage of a product, especially when building an MVP it makes most sense to start with a single full-stack dev.
As you said, it's cheaper and easier to manage project that way. Later down the road, when the product grows it makes sense to hire more specialized people and while the initial full-stack dev moves into a team lead position - for which he/she is perfectly capable because he/she has understanding of the system as a whole.
It's not that hard to do full-stack development, as long as you make right technical decisions and you don't shoot yourself in the foot by trying to use all the hyped up technologies at the moment. Rails app with some jQuery/Stimulus.js sprinkled on top hosted on Heroku will do just fine for an early stage product.