I don't want to be a full-fullstack developer(artur-martsinkovskyi.github.io)
artur-martsinkovskyi.github.io
I don't want to be a full-fullstack developer
https://artur-martsinkovskyi.github.io//2019/i-dont-want-to-be-fullstack/
87 comments
I have the (admittedly subjective) sensation that I read a similar blog article just about every week.
As the author aknowledges the various opposing points, we could, perhaps, sensibly surmise that it's contextually dependent.
From my experience, as a backend engineer develops more frontend/javascript skills, the solutions tend to become more intertwined. We now have some parts of our app where you couldn’t change the tiniest detail in a view method, without thinking about how that’s going to break client side. I’m not sure that’s moving in the right direction.
you need a team for larger applications, however the members of the team should have overlapping skills. so you don't always need to do everything all the time.
it is fine to be a specialist in some areas. actually, a team needs specialists, to solve difficult blocking problems.
However, when you got someone with excellent frontend skills, they still should know how the backend works since they interact with it. they should also be able to pick up changes there. since amount of work is not always balanced. further, doing work in a particular area outside of the main expertise raises the understanding of specifics there as well increses the overview of the complete system.
in the end, being full-stack dev is a strategy to prevent local optimization and comm-overhead and emphasize global optimization to develop a good application for the customer.
However, when you got someone with excellent frontend skills, they still should know how the backend works since they interact with it. they should also be able to pick up changes there. since amount of work is not always balanced. further, doing work in a particular area outside of the main expertise raises the understanding of specifics there as well increses the overview of the complete system.
in the end, being full-stack dev is a strategy to prevent local optimization and comm-overhead and emphasize global optimization to develop a good application for the customer.
I totally understand where the author is coming from. Though a full stack dev like an ER doctor.
So is a full stack programmer someone who can write javascript for the server AND the browser?
> the rabbit hole of developer-focused engineering process and developers go on to combine more and more responsibilities beneath the surface of single cranium.
(1) There's a strong reason for this desire. Software systems are very interdependent.
We you can see from front to back and side to side, and you can recoginze the potential for improvement or optimization.
(2) "Full-stack software developer" is more specialized then you might think.
As a "full stack" web developer, I can count on one hand the number of times I've looked at a browser's source code. Same for databases. I understand the basics of DNS, IP, TCP, UDP, BGP, but not the details. And my knowledge of common ISAs is laughable. And I have essentially no knowledge of hardware: physical CPUs/GPUs, displays, fiber optics, etc.
(1) There's a strong reason for this desire. Software systems are very interdependent.
We you can see from front to back and side to side, and you can recoginze the potential for improvement or optimization.
(2) "Full-stack software developer" is more specialized then you might think.
As a "full stack" web developer, I can count on one hand the number of times I've looked at a browser's source code. Same for databases. I understand the basics of DNS, IP, TCP, UDP, BGP, but not the details. And my knowledge of common ISAs is laughable. And I have essentially no knowledge of hardware: physical CPUs/GPUs, displays, fiber optics, etc.
For me, Fullstack is only enjoyable when using JS or TypeScript both in backend and frontend
I thought I’d feel that way but it turns out I need a break from Javascript sometimes. Doing a backend story once in a while got me a little break from that before Node. Now I’ve only got the build system and docker as relief valves and it’s not enough long term.
Allow me the exaggeration but I think that if everybody would be full stack, frameworks would be much simpler, there is a lot of gratuite complexity that grows because people have the time to dedicated just to one side.
I stumbled into the realization that teams should be full stack instead of horizontally sliced. Once I figured out how to map out data dependencies end to end
as part of our planning process we made huge gains in productivity and similar reductions in stress.
Agree with all your points, but in my experience, early-stage startups require full-stack competency due to rapidly changing priorities and a small team.
Generally they don’t require the entire team to be full stack. But being able to flip priorities from 2:1 to 1:2 front end vs backend is often necessary to maintain velocity between milestones. Prettying up the interface is a lot of work. So is scaling up your backend for the new customers your facelift just got you.
In a small place having a third of your team being full stack takes a lot of stress off the planning people.
In a small place having a third of your team being full stack takes a lot of stress off the planning people.
Agree 100% on that, I didn't mean to imply startups want a team full of generalists. But engineer #1 likely has to be full-stack. As you say, once you have 3+ engineers, a mix of full-stack and domain experts can ease planning challenges.
We had this role back in 1997 We called those roles webmasters. It involved everything frontend / backend plus running a server on your bedroom floor that powered a company
I'm fine with all of those roles. I've been able to pick them up along the way and others (report writer use to be a separate role).
The one role I can't master is designer (not frontend developer). It isn't logical and it can't be learned through instructions alone. And the rules change.. what looks great today looked alien yesterday and boring tomorrow.
I'm fine with all of those roles. I've been able to pick them up along the way and others (report writer use to be a separate role).
The one role I can't master is designer (not frontend developer). It isn't logical and it can't be learned through instructions alone. And the rules change.. what looks great today looked alien yesterday and boring tomorrow.
Have you spent any time trying to learn design? I agree there is some part that is one's own artistic style, but much of design can be viewed and learned systematically - ratios, patterns, color theory, etc
Indeed, I'm not really a designer. But I spent about a year reading Smashing Magazine (https://www.smashingmagazine.com/) regularly a few years ago, and I have the basics down now.
Turns out it's a lot like good code: keep everything consistent (padding, colours, etc) and clear, and simple and it'll ussually look decent.
Turns out it's a lot like good code: keep everything consistent (padding, colours, etc) and clear, and simple and it'll ussually look decent.
Full stack engineers wear multiple hats and they have a strong incentive for picking just the right (sufficient?) tools for the job. The upside for full stack engineers are that things aren't overengineered.
I think from the client point of view the advantage of having "full-stack" developers is that it saves you some trouble of team management. With more specialized team you need some fronted developers, some backend developers and an architect to ensure that the pieces fit. And you have some inneficiencies, when front-end peoples are swamped with work, and backend guys are sitting idle, or vice versa. In a team composed solely of full-stack devs people are more interchangeable.
Try to make a company. You have to be full-full-fullstack.
If you like to ship business value for your employers, you will want to be full full stack.
If you want to be partially responsible for your work and put up “not my job” boundaries, then sure, proudly hail the part stack flag.
If you’re an architect or a lead engineer and you are not coding in the front end (and I don’t mean designing its visuals), then you are dodging solving hard engineering problems (let others do the toil), and you are on your road to losing useful perspective.
If you want to be partially responsible for your work and put up “not my job” boundaries, then sure, proudly hail the part stack flag.
If you’re an architect or a lead engineer and you are not coding in the front end (and I don’t mean designing its visuals), then you are dodging solving hard engineering problems (let others do the toil), and you are on your road to losing useful perspective.
Yup, I like to call it “true stack”. Sales marketing, design, development. Whatever needs to be done I’ll do it.
> 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.
Why do you think developer salaries are so high? As the advancement and sophistication of open-source and SaaS offerings increasingly empowers individual developers to do more for businesses, so do developers leverage those capabilities to demand higher salaries and become more and more integral, as individuals, to the business process. The natural consequence of this is that companies have increased their expectations across the board because they ultimately get more value out of a highly paid full-stack than paying three moderately smaller salaries to a FEE, BEE and a manager/architect/SME to coordinate their efforts.
Why do you think developer salaries are so high? As the advancement and sophistication of open-source and SaaS offerings increasingly empowers individual developers to do more for businesses, so do developers leverage those capabilities to demand higher salaries and become more and more integral, as individuals, to the business process. The natural consequence of this is that companies have increased their expectations across the board because they ultimately get more value out of a highly paid full-stack than paying three moderately smaller salaries to a FEE, BEE and a manager/architect/SME to coordinate their efforts.
I disagree with that assessment. Sophisticated open source, IaaS, and SaaS offerings greatly lower the barrier of entry in this industry and ought to have a negative effect on wages as dictated by supply and demand.
Your argument undermines itself by highlighting that a single open-source-equipped person can do the job of 3 grey beards of old. That automation of labor runs counter to rising wages.
As another data point, some of the highest paid engineers in the industry - those manning in the private battlements of the FAANG citadels - are specialist steeped in closed source arcana. I myself have been such an acolyte for many years.
My own take on the situation is that the distribution of skillets will further take on a bimodal distribution: the specialists and the generalists.
For now both the supply of sophisticated tools and capable practitioners has not kept pace with the demand from modernizing business. When the demand is met and equilibrium reached, I expect salaries to normalize back to what other technical professionals command (e.g. aerospace and civil engineers).
Your argument undermines itself by highlighting that a single open-source-equipped person can do the job of 3 grey beards of old. That automation of labor runs counter to rising wages.
As another data point, some of the highest paid engineers in the industry - those manning in the private battlements of the FAANG citadels - are specialist steeped in closed source arcana. I myself have been such an acolyte for many years.
My own take on the situation is that the distribution of skillets will further take on a bimodal distribution: the specialists and the generalists.
For now both the supply of sophisticated tools and capable practitioners has not kept pace with the demand from modernizing business. When the demand is met and equilibrium reached, I expect salaries to normalize back to what other technical professionals command (e.g. aerospace and civil engineers).
> Sophisticated open source, IaaS, and SaaS offerings greatly lower the barrier of entry in this industry
I would question this assumption. In my view, the existence of these tools actually increases the barrier to entry because they represent additional skills that developers are expected to posses in order to be competitive in the job market. This is actually a common complaint among developers whenever a new technology gains viral popularity (e.g. AWS, react, k8s).
> That automation of labor runs counter to rising wages
Well of course it does, except for the people who are paid very well to build the automated systems (i.e. programmers). Fortunately for programmers there still isn't enough supply to meet demand, so senior developers on the frontiers of popular technologies can command outsized salaries but still can't do enough work to eliminate the need for their less sophisticated colleagues (yet).
> specialist steeped in closed source arcana
Sure, that doesn't really contradict what I'm saying, but I'd also note that whatever closed source project one might be working on is almost certainly benefiting from a gigantic open-source force multiplier in some form or another.
> When the demand is met and equilibrium reached, I expect salaries to normalize back to what other technical professionals command (e.g. aerospace and civil engineers).
On this we agree. I tell developers all the time that they should enjoy it while it lasts because this definitely won't last forever. I'm pretty bearish on things like AI programmers, but I think open-source and commodity B2B software solutions are rapidly approaching the point where the costs associated with running an engineering department will appear much less imperative.
I would question this assumption. In my view, the existence of these tools actually increases the barrier to entry because they represent additional skills that developers are expected to posses in order to be competitive in the job market. This is actually a common complaint among developers whenever a new technology gains viral popularity (e.g. AWS, react, k8s).
> That automation of labor runs counter to rising wages
Well of course it does, except for the people who are paid very well to build the automated systems (i.e. programmers). Fortunately for programmers there still isn't enough supply to meet demand, so senior developers on the frontiers of popular technologies can command outsized salaries but still can't do enough work to eliminate the need for their less sophisticated colleagues (yet).
> specialist steeped in closed source arcana
Sure, that doesn't really contradict what I'm saying, but I'd also note that whatever closed source project one might be working on is almost certainly benefiting from a gigantic open-source force multiplier in some form or another.
> When the demand is met and equilibrium reached, I expect salaries to normalize back to what other technical professionals command (e.g. aerospace and civil engineers).
On this we agree. I tell developers all the time that they should enjoy it while it lasts because this definitely won't last forever. I'm pretty bearish on things like AI programmers, but I think open-source and commodity B2B software solutions are rapidly approaching the point where the costs associated with running an engineering department will appear much less imperative.
You argue that powerful open-source tools should lower the barrier to entry. That's probably true. But I think there is also some differentiation that happens: the best developers are able to learn more tools and squeeze out more productivity. So a highly motivated and somewhat clever engineer can do a passable job of ops/db/backend/frontend/design on their own, which makes them quite valuable to businesses.
FAANGs are a bit of a different story, as you point out. But they also have a lot of infrastructure and culture in place that allows specialists to work efficiently.
FAANGs are a bit of a different story, as you point out. But they also have a lot of infrastructure and culture in place that allows specialists to work efficiently.
[deleted]
Automation usually reduces the number of jobs, but increases the pay of those jobs which remain.
The problem that I have seen is most companies don't want to pay a skilled full-stack developer what they are worth. They think $100k is the going rate and unfortunately a lot of junior developers are calling themselves full-stack and jumping at that salary. Then the lines get blurred and the true value of a full-stack developer gets diminished.
I recently was looking for new work. When trying to apply to Developer opportunities, I realized that recruiters largely didn't know what they were talking about.
Many times I was told that my Computer Science degree, large school projects, personal projects such as random apps and maintaining an Arch Linux setup, awards such as winning 1st place in a Google Hackathon, several years of student work including iOS development work, and my 3 years industry experience as a Technical Lead somehow was less valuable than people graduating from coding bootcamps.
I was told by many people that I was not qualified for a Junior Developer position, but people coming out of these bootcamps were considered "Seniors". I was told by one recruiter that my "degree is almost useless".
Many times I was told that my Computer Science degree, large school projects, personal projects such as random apps and maintaining an Arch Linux setup, awards such as winning 1st place in a Google Hackathon, several years of student work including iOS development work, and my 3 years industry experience as a Technical Lead somehow was less valuable than people graduating from coding bootcamps.
I was told by many people that I was not qualified for a Junior Developer position, but people coming out of these bootcamps were considered "Seniors". I was told by one recruiter that my "degree is almost useless".
When you graduated how familiar were you with Twitter Bootstrap, X popular framework (Rails / Laravel / Django), any experience using Vue or React?
My brother graduated 4 years ago (he's a stock boy now) with a degree in Digital Design and Development (Flash, PHP, JS, CSS, Adobe CS), he leans more frontend/graphics but never once was taught anything about CSS frameworks or bootstrap. I'm self-taught laravel dev since 2013, I've used vue, jquery, bootstrap, vuetify, bulma, tailwinds, on frontend even though backend is my strong suit.
I think the point I'm getting at is bootcamps teach exactly what companies need in terms of frameworks and 'hot ticket' skills. You could be a kick ass java developer after you graduate college but if you've never used Spring or Clojure or some other Java framework you're just useless to most companies.
Bootcamps also do quite a bit of bridge building with companies/recruiters to keep their job placements high, where most colleges wipe their hands after you get your diploma and it's on your own good graces that you find your first gig... 2-3 years in it gets way easier though.
My brother graduated 4 years ago (he's a stock boy now) with a degree in Digital Design and Development (Flash, PHP, JS, CSS, Adobe CS), he leans more frontend/graphics but never once was taught anything about CSS frameworks or bootstrap. I'm self-taught laravel dev since 2013, I've used vue, jquery, bootstrap, vuetify, bulma, tailwinds, on frontend even though backend is my strong suit.
I think the point I'm getting at is bootcamps teach exactly what companies need in terms of frameworks and 'hot ticket' skills. You could be a kick ass java developer after you graduate college but if you've never used Spring or Clojure or some other Java framework you're just useless to most companies.
Bootcamps also do quite a bit of bridge building with companies/recruiters to keep their job placements high, where most colleges wipe their hands after you get your diploma and it's on your own good graces that you find your first gig... 2-3 years in it gets way easier though.
Unbelievable. Three years of industry experience alone would qualify you beyond a junior position. https://www.altexsoft.com/media/2018/09/unnamed-14.png
These are basically code for "reject them for silly reasons to get back to screening cheap candidates"
dgzl probably dodged so many bullets that they should be in the Matrix by now
dgzl probably dodged so many bullets that they should be in the Matrix by now
I recently had a recruiter questioning my application for a "senior developer" role as "You seem to have no background in software".
I told her I have "a background" of well over 10 years as a developer, and consider it my profession.
"So why did you study Biology"? she replied.
I told her I have "a background" of well over 10 years as a developer, and consider it my profession.
"So why did you study Biology"? she replied.
HR drones focus on qualifications because it frees them from the responsibility of actually having to evaluate and corroborate that a candidate is competent in a field.
Well, for a company that wants someone to hit the ground running in their chosen stack, your degree is useless as well as your ability to do well in hackathons, and unless they are looking for an iOS developer, so are your iOS skills.
Most jobs don’t need or care that someone can do leetCode or invert a binary tree.
Most jobs don’t need or care that someone can do leetCode or invert a binary tree.
yup :/
i mean, i never did well at hackathons, never got first prize at anything and i'm not graduated.
but, i do have real-world-experience with early/mid/late stage startups as well as corp jobs (i did a project for a local bank working with mainframes). due to that, most companies don't even care about my lack of graduation -- but they do care that i know when to cut corners, when to do crunch-time/overtime, how to take care of customers (including answering support emails!).
real world experience is always much more important.
i mean, i never did well at hackathons, never got first prize at anything and i'm not graduated.
but, i do have real-world-experience with early/mid/late stage startups as well as corp jobs (i did a project for a local bank working with mainframes). due to that, most companies don't even care about my lack of graduation -- but they do care that i know when to cut corners, when to do crunch-time/overtime, how to take care of customers (including answering support emails!).
real world experience is always much more important.
A lot of recruitment processes do unfortunately
That’s why I avoid those companies and I’m both in an area of the country where it’s not part of the recruitment process and have nurtured a network over a couple of decades that allows me to jump through fewer hoops.
Holy, what region are you in? That definitely wouldn't happen over here in the Seattle area, not at top tier companies or even startups that know what they are doing.
This happened in the PDX area, so... Yeah.
Eh, Portland has always been a weird place, maybe coding bootcamps are taken more seriously down there than they are up here?
A senior full-stack developer has so many opportunities that they have the privilege of only considering positions with a compensation level acceptable to them.
> They think $100k is the going rate
Okay. So get a different job.
Okay. So get a different job.
But it is the going rate for senior developers in fly over states.
But it does not work that well. Some individuals(not many) do apply to higher standard while the others just slack on the trend wave. And they can do more harm because their responsibility is almost everywhere.
Then by your own logic developers salaries are low. If you're replacing three people and not being paid three salaries then the company has just found a way to squeeze more blood for less.
That's competition. In a properly functioning market, in the long run, the company's reduced costs should be passed on to consumers and not captured by developers. (Unless we're talking about an exceptionally talented individual, rather than changes in the industry, leading to one person doing the job of three.)
> Why do you think developer salaries are so high?
H1B visa limit?
H1B visa limit?
Developer salaries are high across the globe (relative to local salaries)
This is absolutely true. In Eastern Europe, developers literally make 6-10x typical income, but that's because it's impossible to find say, a mechanical engineer job.
I do wonder if dev salaries are going to start declining though. Everyone semi-competent with a non-lucrative degree is trying to get into dev now. I am sure the MIT-grad stud with a 135 IQ and a 5 years - decade of experience @ FAANG jobs are safe.
As far as typical "senior" developers who can write LoB applications / web apps, I am not so sure - I think at best, salaries will stagnate.
I do wonder if dev salaries are going to start declining though. Everyone semi-competent with a non-lucrative degree is trying to get into dev now. I am sure the MIT-grad stud with a 135 IQ and a 5 years - decade of experience @ FAANG jobs are safe.
As far as typical "senior" developers who can write LoB applications / web apps, I am not so sure - I think at best, salaries will stagnate.
I do have to agree with this article insofar as to what companies are expecting from potential candidates way more than is feasible that's unless the BE and FE use the same language. But as a technical founder you just do not have a choice but to wear all hats.
If you're a solo freelancer full-stack is exactly what you want to be. Being in charge of the whole development process is a big win. I'm not sure full-stack needs to include being an artistic graphic designer, though. Usually it's enough to be able to wield Photoshop well enough to produce business-grade (read boring) graphics. Farm it out to art school students if you need anything more exotic. They'll be glad of the extra income to supplement their grant.
I've worked with very few developers that I could even begin to call full-stack. They either segment themselves as front-end or back-end only, and can't cross the divide. I don't much like it, because that interface between the two is usually terrible as a result, with pieces that don't match, APIs that don't even work, and generally a huge amount of work to integrate by somebody that actually understands both pieces, that rivals rewriting it completely.
Owning an entire vertical slice is so much easier, and produces a better quality product.
Owning an entire vertical slice is so much easier, and produces a better quality product.
most fullstack developers i know have a strong expertise into something and ok knowledge (as in, they can write features, review PRs, fix bugs -- but they are not super experts) in the other areas. which makes sense, it's quite hard to be amazing at everything.
I've been considering and pondering similar things for my own career. I think there are two things going on.
First off, there are assumptions that full stack developers are 100% amazing at all points in the stack. That's not the case. I consider myself more of an operator this day an age, but I still could take AWS or an empty linux box and build and deploy a java/go backend with a VueJS frontend for something. It won't be pretty, I can promise that. At the same time, that's why I have a great time with the other full stack developer who is much stronger on the frontend/backend side and kinda doesn't want to deal with the infrastructure and deployment.
And from that follows something that has taken a lot of stress from me. If the company is small, it's fine to have a full stack developer deliver something. There will be deficiencies in the stack somewhere, but who cares, there will be a minimally viable product.
Once the company scales however, people can start specializing into the areas they are good at. Why should I struggle too much with a JS frontend if I can make the entire application faster by thinking about the database? Why should the mentioned other dev struggle with one of the many ways to deploy the application if they could spend their time on features?
First off, there are assumptions that full stack developers are 100% amazing at all points in the stack. That's not the case. I consider myself more of an operator this day an age, but I still could take AWS or an empty linux box and build and deploy a java/go backend with a VueJS frontend for something. It won't be pretty, I can promise that. At the same time, that's why I have a great time with the other full stack developer who is much stronger on the frontend/backend side and kinda doesn't want to deal with the infrastructure and deployment.
And from that follows something that has taken a lot of stress from me. If the company is small, it's fine to have a full stack developer deliver something. There will be deficiencies in the stack somewhere, but who cares, there will be a minimally viable product.
Once the company scales however, people can start specializing into the areas they are good at. Why should I struggle too much with a JS frontend if I can make the entire application faster by thinking about the database? Why should the mentioned other dev struggle with one of the many ways to deploy the application if they could spend their time on features?
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
I like working with the users directly to make sure I’m writing what they need. If I don’t, I encounter too many instances of the “XY Problem”.
Who should be doing the integration and unit tests if not the developer? Why wouldn’t the developer be doing his own QA before he passes it off as “done”?
I work for mostly small companies so I can do the full stack - except for designing the interface. I can code the front end, backend in three or four modern languages well, know how to design and manage databases - RDMS (OLAP/OLTP) and I know my way around infrastructure at least with AWS. I can do passable Devops CI/CD pipelines. But, this is from a long career at working at mostly small companies.
I like working with the users directly to make sure I’m writing what they need. If I don’t, I encounter too many instances of the “XY Problem”.
Who should be doing the integration and unit tests if not the developer? Why wouldn’t the developer be doing his own QA before he passes it off as “done”?
I work for mostly small companies so I can do the full stack - except for designing the interface. I can code the front end, backend in three or four modern languages well, know how to design and manage databases - RDMS (OLAP/OLTP) and I know my way around infrastructure at least with AWS. I can do passable Devops CI/CD pipelines. But, this is from a long career at working at mostly small companies.
So, it seems like the pendulum is swinging back. I remember companies with more dedicated specialists, and it could be challenging to ship small features due to large coordination efforts.
Further, sometimes the work is unbalanced. In my current company, we recently had a backend-dominant release in a way that the frontend team didn't have as much work. That team rolled up its sleeves and dug in to solve problems, even if they weren't specialized in it. They weren't happy. It wasn't what gave them joy, but it was what was necessary for everyone to release what was needed. Now, we made sure that they had access to backend developers who could pair or guide work, and we knew the work would talk longer. (After all, these were developers who were stronger in the front end!) With our next release, we look to be more balanced, but we're looking at having developers with more backend competencies contribute to the frontend this release.
I think it's too much to ask for developers to be equally brilliant in multiple areas, but I don't think it's too much to ask that people have the willingness to develop minimal proficiencies in multiple layers and the willingness to contribute and learn.
Further, sometimes the work is unbalanced. In my current company, we recently had a backend-dominant release in a way that the frontend team didn't have as much work. That team rolled up its sleeves and dug in to solve problems, even if they weren't specialized in it. They weren't happy. It wasn't what gave them joy, but it was what was necessary for everyone to release what was needed. Now, we made sure that they had access to backend developers who could pair or guide work, and we knew the work would talk longer. (After all, these were developers who were stronger in the front end!) With our next release, we look to be more balanced, but we're looking at having developers with more backend competencies contribute to the frontend this release.
I think it's too much to ask for developers to be equally brilliant in multiple areas, but I don't think it's too much to ask that people have the willingness to develop minimal proficiencies in multiple layers and the willingness to contribute and learn.
I think the broad historical sweep here is sort of along the lines of:
* From the early microcomputer era onwards, applications development focused on getting developers that knew the base platform or operating system(e.g. if you knew "Win32" dev, that was solid in the mid-90's) - and it was one platform per category of application, and for applications that integrated a database you also had platforms like Foxpro, Access, or Hypercard. Specialization beyond that was typically the domain of big-iron computing, which had an older market and talent pool that was used to a certain model and infrastructure of scaling to solve the data processing needs of the era.
* Increased usage of computer networking pushed all development towards a multi-tier setup(e.g. LAMP stack or the multifarious forms of Java and .Net), meaning that more applications needed "front-end" vs "back-end" division, regardless of their needs. We addressed the problem at a local level by gluing together big-iron concepts and microcomputer concepts to get an awkward-yet-servicable jumble of domain competence, with the Web as the dominant frontend. A very small number of Internet companies pushed the boundaries and set the standards on data processing and frontends, and the market followed in their footsteps and used their leftovers.
* Now that we have built out a lot of leverage towards all the possible speciality roles and computing is firmly in the hands of a few giants that can leverage all of that specialization, commoditization is creeping in and pushing smaller development teams back into more consolidated platforms. "The browser is the OS" is effectively true today, except that it's a terrible OS, scarred by numerous wars to control the platform and enable only specific categories of applications.
What developers are moving towards, but are having trouble reaching because of the sheer number of established layers and protocols and required features, is another Hypercard that consolidates concepts into a single consumable, more uniform package, without requiring you to know all the boundaries and sharp edges that exist when going between the JS type system, the SQL engine, the browser engine, serialization protocols, network conditions and hardware status, etc. This is not a project that can be accomplished by lightly papering over the existing systems with framework glue - it requires attention to detail to clean up and simplify each part of the whole. So it takes time.
But at the same time, I think we're also going to get where we want to go, faster than we think. The introduction of, and adoption of Web Assembly, is a major milestone because it raises the level of local processing and hence local platform consolidation, which in turn limits browser-specific APIs to importance in terms of their core I/O functionality, and not one-off standardized features. New platforms can carve out more and more space from that starting point, ultimately resulting in applications that have replaced the browser with a custom native runtime, but still ship WASM binaries.
Simultaneously, native code development is getting better. The bottom of the stack is getting attention after leaning heavily on the traditional C/Unix model for decades and accumulating features without major revision - Rust and systemd are two healthy(if polarizing) examples.
And at that point, the classical Open Web is dead, but it's due to be replaced in turn with a second coming of specialized, decentralized and federated protocols - new takes on Usenet, IRC, FTP, etc. The wheel will keep turning, though all the formats might churn.
* From the early microcomputer era onwards, applications development focused on getting developers that knew the base platform or operating system(e.g. if you knew "Win32" dev, that was solid in the mid-90's) - and it was one platform per category of application, and for applications that integrated a database you also had platforms like Foxpro, Access, or Hypercard. Specialization beyond that was typically the domain of big-iron computing, which had an older market and talent pool that was used to a certain model and infrastructure of scaling to solve the data processing needs of the era.
* Increased usage of computer networking pushed all development towards a multi-tier setup(e.g. LAMP stack or the multifarious forms of Java and .Net), meaning that more applications needed "front-end" vs "back-end" division, regardless of their needs. We addressed the problem at a local level by gluing together big-iron concepts and microcomputer concepts to get an awkward-yet-servicable jumble of domain competence, with the Web as the dominant frontend. A very small number of Internet companies pushed the boundaries and set the standards on data processing and frontends, and the market followed in their footsteps and used their leftovers.
* Now that we have built out a lot of leverage towards all the possible speciality roles and computing is firmly in the hands of a few giants that can leverage all of that specialization, commoditization is creeping in and pushing smaller development teams back into more consolidated platforms. "The browser is the OS" is effectively true today, except that it's a terrible OS, scarred by numerous wars to control the platform and enable only specific categories of applications.
What developers are moving towards, but are having trouble reaching because of the sheer number of established layers and protocols and required features, is another Hypercard that consolidates concepts into a single consumable, more uniform package, without requiring you to know all the boundaries and sharp edges that exist when going between the JS type system, the SQL engine, the browser engine, serialization protocols, network conditions and hardware status, etc. This is not a project that can be accomplished by lightly papering over the existing systems with framework glue - it requires attention to detail to clean up and simplify each part of the whole. So it takes time.
But at the same time, I think we're also going to get where we want to go, faster than we think. The introduction of, and adoption of Web Assembly, is a major milestone because it raises the level of local processing and hence local platform consolidation, which in turn limits browser-specific APIs to importance in terms of their core I/O functionality, and not one-off standardized features. New platforms can carve out more and more space from that starting point, ultimately resulting in applications that have replaced the browser with a custom native runtime, but still ship WASM binaries.
Simultaneously, native code development is getting better. The bottom of the stack is getting attention after leaning heavily on the traditional C/Unix model for decades and accumulating features without major revision - Rust and systemd are two healthy(if polarizing) examples.
And at that point, the classical Open Web is dead, but it's due to be replaced in turn with a second coming of specialized, decentralized and federated protocols - new takes on Usenet, IRC, FTP, etc. The wheel will keep turning, though all the formats might churn.
I think there's truth to that when looking at internal software, but external (B2C) software will continue to live in this division. (Think of hotels.com as an application, for example. There's no world where you can build a hypercard app that meets those needs.)
> Further, sometimes the work is unbalanced
My team has just grown my two backend developers to three. We also have six frontenders. Yes, the work is unbalanced, hire for it.
My team has just grown my two backend developers to three. We also have six frontenders. Yes, the work is unbalanced, hire for it.
Last release, I was unbalanced on the back end. This release is different. The work changes. Do I lay people off and rehire each quarter based on business need? (No.) do I tell business we can’t do more valuable work while less valuable work is happening?
I have a budget as a manager. I can’t always just hire more.
I have a budget as a manager. I can’t always just hire more.
My two cents: you don't need "full stack developers", but you also don't want "front end developers" and "back end developers". You want people who can play either role (and many more) as needed, but with training friction in between.
I think of it as T-shaped developers who have the attitude that they can learn what is necessary, have a culture of collaboration that reduces the friction of learning, and still allow people the ability to shine in code.
I think of my teams as "primarily front end" and "primarily API/back end."
Many people would call that "full stack." Some would call a developer like me "full stack" as in my career I've been a backup sysadmin, Db (pl/sql) dev, back end, front end, and a few other things as needed. But at any one time, I can really only be proficient in two of these - everything else decays.
I think of my teams as "primarily front end" and "primarily API/back end."
Many people would call that "full stack." Some would call a developer like me "full stack" as in my career I've been a backup sysadmin, Db (pl/sql) dev, back end, front end, and a few other things as needed. But at any one time, I can really only be proficient in two of these - everything else decays.
Can you stream multiple releases in parallel instead of doing them in series?
E.g. release A has 75% back-end, release B has 75% front-end. You can have front-end devs finish their work on release A and then start on release B before release A is out. (Though, obviously, not that simple. You'll need at least one front-end dev to stay on release A to solve integration issues, and you'll probably need a back-end dev to create endpoints, etc, on release B. But the principle holds, still).
It's more efficient to keep everyone working at their fastest, most productive (and enjoyable) tasks whenever possible. But it does take more (and better) management to handle it.
E.g. release A has 75% back-end, release B has 75% front-end. You can have front-end devs finish their work on release A and then start on release B before release A is out. (Though, obviously, not that simple. You'll need at least one front-end dev to stay on release A to solve integration issues, and you'll probably need a back-end dev to create endpoints, etc, on release B. But the principle holds, still).
It's more efficient to keep everyone working at their fastest, most productive (and enjoyable) tasks whenever possible. But it does take more (and better) management to handle it.
The best way I've learned to build working software is to have a group working together driving at the delivery of it rather than organizing a series of handoffs. Not only do people have context switching concerns at the task level, but teams and organizations have context switching concerns: more tasks in progress mean more organization thrashing and things drop on the floor.
Assuming no slowdown from all the context-switching (a generous assumption), and equal sized features, splitting the team would make the high priority feature take twice as long to deliver.
In the context of a large web application what many people describe as back end is hardly such. Typically that stuff is middleware. The actual back end would be things like payment processing, database access, internal services, and so forth. The code sitting on a service that issues server calls and into the business logic that builds anything client facing is middleware. I call that stuff middleware because at a large enough company they would not let anything on a webserver go remotely close to anything storing data for security reasons.
That being said fullstack doesn't actually mean the entire stack as the name would suggest. It really means the front-end plus the middleware, or both ends of HTTP. For developers experienced enough to write on both sides of HTTP it makes sense to tidy that up into a single position to lower labor costs.
That being said fullstack doesn't actually mean the entire stack as the name would suggest. It really means the front-end plus the middleware, or both ends of HTTP. For developers experienced enough to write on both sides of HTTP it makes sense to tidy that up into a single position to lower labor costs.
An early stage startup probably doesn’t have enough money to hire specialists, and doesn’t have the workflow down to make optimal use of them even they could afford someone in every position. At that scale you need one or two people who can do everything - probably they won’t do the best job of everything, but they’ll get your company off the ground.
Once a company starts scaling up they’ll find that they need someone with a deep knowledge of one particular specialism, such as mobile development, or backend, or maybe infrastructure. They’ll pick someone like that up who likely ends up taking ownership of it.
Over time they’ll end up with specialists for everything, but that comes with its own set of problems. At this point probably everyone can do a really good job in isolation, but there’s someone needed to coordinate the work to make sure people aren’t being blocked. That’s when the first dedicated project managers start arriving and getting the team moving in one direction. Probably at this point you’ll also start seeing product managers, because there’s no one around with a unified high level view of what customers need anymore - everyone else is down in the weeds.
At least in my experience scaling a technical team is at least, if not more, complex than scaling the actual product that team is working on. It shouldn’t be underestimated, and you should aim to have someone around who’s done it before and understands when it’s time to stop saying “we should just hire people who can do everything”.
Once a company starts scaling up they’ll find that they need someone with a deep knowledge of one particular specialism, such as mobile development, or backend, or maybe infrastructure. They’ll pick someone like that up who likely ends up taking ownership of it.
Over time they’ll end up with specialists for everything, but that comes with its own set of problems. At this point probably everyone can do a really good job in isolation, but there’s someone needed to coordinate the work to make sure people aren’t being blocked. That’s when the first dedicated project managers start arriving and getting the team moving in one direction. Probably at this point you’ll also start seeing product managers, because there’s no one around with a unified high level view of what customers need anymore - everyone else is down in the weeds.
At least in my experience scaling a technical team is at least, if not more, complex than scaling the actual product that team is working on. It shouldn’t be underestimated, and you should aim to have someone around who’s done it before and understands when it’s time to stop saying “we should just hire people who can do everything”.
Totally this. The difference is not "full-stack" vs "specialist" so much as "early/small company employee" and "corporate employee".
In small/early companies, there's just a few people. The same tasks need to be done (someone has to design the database, ensure the SSL certs work, and get that checkbox looking good in Firefox). But there's less people to do it.
"full-stack" in this sense means someone who is prepared to roll up their sleeves and solve whatever problem presents itself. It might not be the best solution, and a specialist can almost certainly do a better job, quicker. But it works for now, and moves the product on to the next step.
Corporate employees can be true specialists, because there's enough work and enough team to allow them to be. But this comes with an additional required skillset: corporate communication. To be an effective member of a large team requires a communication mindset that is completely different from the "roll up your sleeves and get it done" mindset of the small/early organisation.
I'm a small/early organisation guy - I can't stand corporate communication, and love rolling my sleeves up and getting it done, whatever "it" is. I know people who are totally the other way; they just want to focus on crafting amazing UI's, or designing perfect databases, and shudder with horror at having to deal with the "full stack" in all its nightmarish complexity. They're comfortable dealing with lots of meetings and reports in return for being allowed to do their one thing.
In small/early companies, there's just a few people. The same tasks need to be done (someone has to design the database, ensure the SSL certs work, and get that checkbox looking good in Firefox). But there's less people to do it.
"full-stack" in this sense means someone who is prepared to roll up their sleeves and solve whatever problem presents itself. It might not be the best solution, and a specialist can almost certainly do a better job, quicker. But it works for now, and moves the product on to the next step.
Corporate employees can be true specialists, because there's enough work and enough team to allow them to be. But this comes with an additional required skillset: corporate communication. To be an effective member of a large team requires a communication mindset that is completely different from the "roll up your sleeves and get it done" mindset of the small/early organisation.
I'm a small/early organisation guy - I can't stand corporate communication, and love rolling my sleeves up and getting it done, whatever "it" is. I know people who are totally the other way; they just want to focus on crafting amazing UI's, or designing perfect databases, and shudder with horror at having to deal with the "full stack" in all its nightmarish complexity. They're comfortable dealing with lots of meetings and reports in return for being allowed to do their one thing.
I agree with the small vs large. Would be interested in at what head count you’ve seen this transition happen? Especially the need for project/product managers.
> 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.
What about GPs?
Just like the medical field, software needs both specialists (to go really deep down the rabbit holes), and generalists (to tie everything together).
Personally I love being a generalist. Sounds like the OP just isn't in quite the role for them.
What about GPs?
Just like the medical field, software needs both specialists (to go really deep down the rabbit holes), and generalists (to tie everything together).
Personally I love being a generalist. Sounds like the OP just isn't in quite the role for them.
Architectural coherence is such an important part of software design. I agree with your point completely—you need specialists for deep, specific problems, but you also need people with a view of the entire system.
Great point, and I think it relates to the market need for a "full-stack developer", an all-around generalist who understands (more or less) the entire stack and areas of endeavor.
It also made me think how, typically, the problem with "design by committee" is that it's often a mere collection of specialists, without the necessary generalists (those with an understanding of architectural coherence, system-level thinking) with the power to tie it all together.
I think the reason why many great software projects are created by an individual or a small team, is that coherence and consistent vision across the system.
It also made me think how, typically, the problem with "design by committee" is that it's often a mere collection of specialists, without the necessary generalists (those with an understanding of architectural coherence, system-level thinking) with the power to tie it all together.
I think the reason why many great software projects are created by an individual or a small team, is that coherence and consistent vision across the system.
This is actually discussed very intelligently in "The Mythical Man-Month." The author explains that large software projects have an inherent tension between coherence and efficiency. A small team maintains coherence, but cannot get the required amount of work done in a reasonable amount of time; a large team works faster at the expense of coherence. Balancing those two aspects effectively is what makes large projects successful.
If you are doing web dev, it is normal to require a wide set of skills (but not very deep). You are not a researcher or PHD student. Also, you are not working on a pacemaker or anything with life/death consequences, so cutting some corners like merging UI/UX/QA can only be profitable. Communication is faster within a single brain than within 'n' amount of people with slightly different jobs.
> you don’t expect the dentist to cure your heart and neurosurgeon to fix your hemorrhoids.
That's your problem right there. Your frontend is not as different from your backend as dentristy is from neurosurgery. If you think it is, you might lack some understanding of how things work.
Tbh., whenever someone hails the specialization and how their particular field is so special, I hear them saying "I really do not want to be bothered with all these nasty details". And that's fine. But it's not something to be proud of. Personally, I would love to have a better understanding of how user interfaces or database work internally. I think the understanding would only make me better.
That's your problem right there. Your frontend is not as different from your backend as dentristy is from neurosurgery. If you think it is, you might lack some understanding of how things work.
Tbh., whenever someone hails the specialization and how their particular field is so special, I hear them saying "I really do not want to be bothered with all these nasty details". And that's fine. But it's not something to be proud of. Personally, I would love to have a better understanding of how user interfaces or database work internally. I think the understanding would only make me better.
> That's your problem right there. Your frontend is not as different from your backend as dentristy is from neurosurgery.
I'm not a neurosurgeon, or a dentist, but this doesn't strike me as true. Front-end dev uses totally different tools and languages, and a different set of design principles, than back-end dev. It didn't use to be this way, but it definitely is now. There's almost no cross-over in skills now, especially with Elm-derived front-end frameworks taking over.
I'm not a neurosurgeon, or a dentist, but this doesn't strike me as true. Front-end dev uses totally different tools and languages, and a different set of design principles, than back-end dev. It didn't use to be this way, but it definitely is now. There's almost no cross-over in skills now, especially with Elm-derived front-end frameworks taking over.
> totally different tools and languages
do they, though? What's distinguishing JavaScript from, say, a poorly implemented lisp? What's the main difference between typescript and a poorly implemented ML? Syntax? Come on! There are maybe a handful of really different programming languages designs. And only three of them are really widespread.
> There's almost no cross-over in skills now, especially with Elm-derived front-end frameworks taking over.
If you are talking about Elm the language then it is very clearly influenced by Haskell. It is literally rooted in FRP. So to understand elm you need to know something about functional programming and type systems. Then you read the docs and you are in the game after a few days.
do they, though? What's distinguishing JavaScript from, say, a poorly implemented lisp? What's the main difference between typescript and a poorly implemented ML? Syntax? Come on! There are maybe a handful of really different programming languages designs. And only three of them are really widespread.
> There's almost no cross-over in skills now, especially with Elm-derived front-end frameworks taking over.
If you are talking about Elm the language then it is very clearly influenced by Haskell. It is literally rooted in FRP. So to understand elm you need to know something about functional programming and type systems. Then you read the docs and you are in the game after a few days.
yeah, I bet if you talked to the average front-end dev and told them they spend all their time writing poorly-implemented lisp, they've have a few choice words to say about it ;)
From the CS point of view, sure, there are only a half-dozen languages. From the IT point of view, having a few years of experience dealing with the exact details of the "poor implementation of lisp" makes a massive difference in productivity and effectiveness.
There are also widely separate concerns between front-end and back-end. UI patterns is a whole discipline in itself. Deployment and CI, AWS vs DO, not to mention containers and swarms, is just a subset of one aspect of "dev ops" these days. There's also the entire subject of database design, of securing HTTP/S/2 traffic, data encryption schemes, logging strategies. It's endless, on both sides. And none of the skills are transferable. Knowing AWS doesn't help you implement a UI, and knowing React does nothing to help you design a database.
I dare you to try implementing a complex UI in React after learning FP, reading the docs and a "few days" ;)
But to get back to the analogy... I can easily see a neurosurgeon saying "teeth, they're just specialised bones! Give me a few days to brush up on the basics, and I'll have that wisdom tooth out in a jiffy" in the same manner.
From the CS point of view, sure, there are only a half-dozen languages. From the IT point of view, having a few years of experience dealing with the exact details of the "poor implementation of lisp" makes a massive difference in productivity and effectiveness.
There are also widely separate concerns between front-end and back-end. UI patterns is a whole discipline in itself. Deployment and CI, AWS vs DO, not to mention containers and swarms, is just a subset of one aspect of "dev ops" these days. There's also the entire subject of database design, of securing HTTP/S/2 traffic, data encryption schemes, logging strategies. It's endless, on both sides. And none of the skills are transferable. Knowing AWS doesn't help you implement a UI, and knowing React does nothing to help you design a database.
I dare you to try implementing a complex UI in React after learning FP, reading the docs and a "few days" ;)
But to get back to the analogy... I can easily see a neurosurgeon saying "teeth, they're just specialised bones! Give me a few days to brush up on the basics, and I'll have that wisdom tooth out in a jiffy" in the same manner.
Front- and back-end are very different things. I’ve worked with some brilliant engineers who couldn’t make a serviceable UI to save their lives, never mind the intricacies of overall user experience.
I’ll balk at UI/UX people who can’t code, but I’ll stand by the value they can add to a project.
I’ll balk at UI/UX people who can’t code, but I’ll stand by the value they can add to a project.
This is based on my own personal experience of course, but in any given job I tend to be full-stack, but with a bias towards a certain area of the stack. My contribution to the other areas of the stack is in more of an advisory/consultant role.
On the other hand, I know full-stack devs who are far better at context-switching than I am. Subjectively I don't think their output is at the same quality as mine, but there is definite value in what they're able to do.