
I don't want to be a full-fullstack developer - gentleterror
https://artur-martsinkovskyi.github.io//2019/i-dont-want-to-be-fullstack/
======
ebiester
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.

~~~
mntmoss
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.

~~~
ebiester
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.)

------
root_axis
> _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.

~~~
exfaang
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).

~~~
root_axis
> _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.

------
jon-wood
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”.

~~~
marcus_holmes
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.

------
tetha
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?

------
wolco
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.

~~~
spraak
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

~~~
nicoburns
Indeed, I'm not really a designer. But I spent about a year reading Smashing
Magazine
([https://www.smashingmagazine.com/](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.

------
choeger
> 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.

~~~
marcus_holmes
> 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.

~~~
choeger
> 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.

~~~
marcus_holmes
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.

------
nicoburns
> 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.

~~~
ellius
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.

~~~
lioeters
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.

~~~
ellius
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.

------
alfonsodev
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.

~~~
hinkley
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.

------
paulddraper
> 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.

------
antoineMoPa
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.

------
tzhenghao
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.

~~~
mamon
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.

------
cutler
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.

------
11235813213455
For me, Fullstack is only enjoyable when using JS or TypeScript both in
backend and frontend

~~~
hinkley
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.

------
thrower123
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.

~~~
fernandotakai
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.

------
hartator
Try to make a company. You have to be full-full-fullstack.

~~~
taneq
Ugh, so true. The hard part is building the non-tech part of the company so
you can hopefully do some coding ever again.

~~~
hartator
Haha that rings so true.

------
scarface74
_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.

------
austincheney
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.

------
rashthedude
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.

------
andrewingram
I disagree with the argument that you can't have a high level of skill in
multiple parts of the stack without sacrificing a personal life. But I do tend
to believe you can't operate at that skill level for each discipline at the
same time.

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.

------
justaaron
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.

------
crawfordleeds
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.

~~~
hinkley
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.

~~~
crawfordleeds
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.

------
bobjordan
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.

------
je42
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.

------
ryanthedev
I totally understand where the author is coming from. Though a full stack dev
like an ER doctor.

------
anotherevan
So is a full stack programmer someone who can write javascript for the server
AND the browser?

