
I Don’t Believe in Full-Stack Engineering - jxub
https://robinrendle.com/notes/i-dont-believe-in-full-stack-engineering/
======
warent
This article is conflating junior developers with full-stack engineering.

I work on the entire stack. Can I work with databases and write queries? Sure.
Can I do it as well as a data architect? No. That's not what's expected of a
full stack engineer.

We can have meaningful, productive discussions with everyone on all parts of
the stack. We'll talk with the data architect, write/tweak a query if we need
to, we'll talk with the product manager and collect some features, we'll
communicate the requirements to a backend engineer if one exists and help
prepare the API as necessary to ensure the frontend can query for only what it
needs when it needs it, and we'll connect it to the frontend which we built
(yes, even using data chunking, semantic UI, and accessibility, all of which
are expected in professional front-end development)

To the purist engineer, none of this is part of their reality because the
purist doesn't have business requirements or tradeoffs. In the real world of
business, these skills generate profit and are especially useful with new
products and prototypes. If you're experienced enough and have a great team
with you, you can execute on this with minimal technical debt that doesn't
create long-term problems while still providing users with a great experience.

~~~
bcheung
Agreed. I would also add, I don't think frontend vs backend accurately
describes how skillsets are clustered anymore -- especially with JavaScript's
increasing ubiquity.

I would cluster skillsets into: ops, development, and design.

Ops: making things highly available, logging, performance monitoring,
reliability, deployment scripts

Development: Writing code on both frontend and backend.

Design: Visual design and CSS/HTML

Most developers I've interacted with at various companies write both APIs in
the backend and user facing UI. In my experience it's becoming increasingly
rare that a frontend developer doesn't also write backend code.

They typically aren't very good at making their apps deployable and highly
available, and they also aren't very good at making things look good with CSS.
Sure they can do it, but it isn't their specialty and it would be quite a
learning curve or it just takes them much longer than someone who does just
that.

When hiring people, I like to find people who are strong individually in those
3 areas (ops, programming, design). I don't try to find programmers who can do
ops or design. I don't worry so much about a frontend engineer being able to
do backend work and vice versa, the crossover is generally smooth and
interchangeable.

It is generally easy to find ops, and programmers who specialize and are
talented. Designers who can do visual design and code it up are a bit rarer,
so sometimes it is needed have 1 person do design and another person code it
up.

Also, a very senior person is obviously going to be stronger in each of those
areas, so full stack is highly correlated with working experience.

~~~
spdionis
I think the crossover between frontend and backend is less effective than you
imagine. Generally a backend dev writes horrible frontend code and viceversa.

A very senior backend person will probably know many things about ops and
frontend, but probably not about design.

A very senior frontend person will probably know a lot about design, UX and
have a good enough experience with backend, but is probably not going to
implement good ops practices.

~~~
bcheung
In the React / Node world I haven't seen this to be true. I can imagine it
being more so if the languages and tooling are different like in the case if
someone was doing Java backend Angular frontend.

~~~
greenhatman
Same with Vue. I used to be more back-end, but frameworks like Vue and React
make front-end feel more like traditional back-end, and are a joy to work
with.

I'd separate the client side scripting and styling / layouts, actually. While
JS and JS frameworks are fun and enjoyable to work with, and I can architect
the JS stuff well to make maintainable code bases, CSS is still a mess for me.
Though getting better at that as well. Flex-box and CSS Grid changes the game
completely from using floats to do layouts.

------
tylerjwilk00
I disagree with the article. It's a 1,000 word false dichotomy between Full
Stack vs. Insert Specialist Here.

Sure, if you're a Fortune 500 company, go ahead and hire a DBA, Cloud
Architect, Backend Engineer, UI/UX Designer, Graphic Artist, Social Media
Marketer, etc.

You'll have a few million $ in salary overhead. It may take longer to produce
a final product.

BUT, it will probably be way better than a product that a full stack developer
knocks out.

BUT, if you're a startup or SMB or lean department and have a 100k budget and
a 6 week deadline a full stack developer is a huge asset to your company.

Obviously when you take the same project and give it to a highly specialized
team of people with lots of time they produce superior results. Do we really
need an article about it?

PS. Giving a 10 person team a 1,000 hour time budget would not be a huge deal.
Try not laughing when a single Full Stack developer asks for 1,000 hours.

~~~
ranit
Unless your numbers are completely random just for the example, deciding to
run an 1,000 hour project with 10 people is a disaster by itself. How would
you involve 10 people in a short 3-4 weeks project?

~~~
tylerjwilk00
The numbers were only to make the point that hours are more easily accepted
when it's split among a larger team. Yet the same quality is expected when a
single Full Stack dev does the project in 1/4 the time and budget?

------
inestyne
Full stack to me is more about ownership and responsibility than pure
expertise. He's the guy that can literally carry the entire thing on his back
if he has to. Technically speaking, usually because he's the one that created
it, by himself, made it work, made it scale, and made it make money without
any help. In my case he becomes the guy in charge trying to figure out how to
hire people to just little parts of his job. And finding out he now has to
learn how to hire people, just like everything else...

:)

~~~
jugg1es
This is probably the most accurate description of a full stack engineer in
this comment section.

------
chrisabrams
I once met a software engineer who said I was not full-stack because I didn't
know how to add to the Linux Kernal. I once met a hiring manager who said I'm
not front-end because I don't know how to vertically shard MySQL and "every
front-end developer knows how to do that." Technology stacks differ per
company and the definition of the title will also differ. That doesn't mean it
doesn't exist.

~~~
omni
You should do everyone a solid and name-and-shame the frontend/MySQL company
because dear God that's horrifying.

~~~
chrisabrams
They don’t exist anymore, they didn’t have what it takes :O

~~~
omni
And nothing of value was lost

------
DanHulton
The misunderstanding the author makes is that a Full Stack Engineer is a
specialist in all roles. They're not. They're simply Intermediate to Senior in
most.

I'd defer to a specialist in essentially every field, but if you require a
broad range of work to be done without hiring a half-dozen people, I'm who
you're looking for. The best title we have got that kind of experience is Full
Stack.

(It's also a well-understood recruiting buzzword you can use to quickly
indicate the work you want and the salary you expect.)

~~~
robertAngst
I barely understand why you would have more than a few full stack engineers
ever.

The guy talked about having beautiful SCSS. At some point, you are talking
about design and less about engineering.

Full stack is a job to be taken on by a small team. Having a large team with
lots of full stack makes 0 sense.

~~~
icebraining
CSS might involve design, but it also involves engineering. Optimizing code
size and rendering speed and fluidity are certainly engineering tasks.

------
andrewingram
Hmm. Maybe full-stack engineering doesn't need you to believe in it?

Though to be fair it probably does, because having your entire professional
community believe you don't exist creates ridiculous amounts of frustration,
anxiety and imposter syndrome.

I do (with skill levels ranging from competent to highly regarded):

* UI design

* Data architecture

* API design

* HTML/CSS/JS/React/GraphQL/etc

* Front-end accessibility (not the best, but I don't just do div/span soup and call it a day)

* Front-end performance (i'll spend weeks optimising the hell out of everything I see in browser devtools if given the chance)

* API performance (see previous).

I tend to draw the line at devops and sysadmin stuff, mainly because I don't
find it interesting. But for everything listed, I do it because I enjoy it.
And there plenty of aspects of engineering professionalism i'm not great at,
which offsets the fact that I apparently have an impossible unicorn set of
skills.

Honestly, I wish I didn't and was happy doing just a subset. But if I'm
spending my time doing just design, I get frustrated that i'm not coding, and
if I'm just coding i'll be dreaming of design. Also, the context-switching is
hell. I wish my interests would let me specialise, but they don't.

~~~
yelloweyes
So basically you're a front-end guy who can do some basic back-end stuff. If
that's full-stack then 80% of developers out there are full-stack.

~~~
andrewingram
I apologise, it was 1am and I miscommunicated, I listed a subset with a very
front-end heavy bias. I transitioned from back-end roles to front-end in the
second half of my career. I also do (have done):

* Recommendation engines (less relevant now a lot of it is easily achievable with tools like Spark)

* Data processing pipelines

* Search indexing, optimisation, and relevancy tuning for millions of products

* Actual database model definition and business logic (possibly where the confusion was, i kinda meant to say everything between database and request/response layer, when all I really said was data modelling).

* Weird stuff like integrate Django’s model layer seamlessly with RPC frameworks. Essentially you could define “foreign keys” that worked across service boundaries and they’d work transparently and decently optimised.

* Systems architecture. Defining service and communication boundaries, message queues, pub/sub etc.

There’s probably a bit more I’ve forgotten about. Does this address the
imbalance a bit?

My point is that if you define full-stack as merely having the skillset to do
these things at an intermediate/senior level, then there are plenty of people
who fit the bill. The issue is time management, I don’t think it should be
someone’s _job_ to do all these things, quality will suffer regardless of
ability.

------
Illniyar
I don't believe in Specialized front/backend development when it relates to
web development.

Web development is and should always be a full-stack affair. Otherwise your
frontend developers would request apis in a way that destroy performance and
create a database model or logic that is unmaintainable on the server-side.
Your backend developers would make apis that make the requested front-end
design make a hundred api calls or api calls in the wrong places (like during
a transition/animation).

It's not just about communication either, though that's also important - it's
exceedingly hard for specialized developers to understand the reasons for
another's requests, being full-stack means you can see the full-picture.

It's about owning the feature/product from beginning to end. It's about
knowing what tradeoffs to make in the serverside, clientside, database or ops,
which you can only do effectively if you are familiar with each. It's about
never being stuck waiting for your backend to fix an api that isn't right, for
your dba to build that query so it won't take a year to run.

That isn't to say that you can't specialize while being Full-stack or that
specialized roles outside of web development shouldn't exist (for example game
development, big data, machine learning).

~~~
sumedh
> I don't believe in Specialized front/backend development when it relates to
> web development.

Do you really expect a backend java developer to be comfortable with
angular/react and vice a versa?

~~~
Illniyar
Indeed. These aren't very complicated subjects, it's easy enough to learn and
doesn't require full-time work to become an expert with (and the same goes for
backend web development), it merely requires constant practice and dealing
with production.

~~~
hobs
The constant practice and dealing with production your java developer would
not have unless that became their job focus.

So are we agreeing that being extremely broad is an anathema to quality
because you cant possibly constantly practice will all things?

~~~
Illniyar
No. You can be a senior java developer with great expertise with only a part-
time job. There's nothing that prevents you from being at a senior level in
multiple technologies or fields of study. More then that though, doing both
complements each other, so that a senior level full-stack developer often has
better insight about server-side issues then someone who only ever knows how
to provide back-end solutions to product level problems.

------
vbezhenar
I'm the only competent developer in our company. So believe it or not, but I'm
doing it all, from tinkering in disassembled Oracle 9i JDBC driver, to
planning Oracle migration to writing SQL queries, reverse-engineering stored
procedures, modifying Delphi sources, writing Java code, writing Kotlin code,
writing HTML, JavaScript, CSS, Objective C, rolling out some tiny PHP website,
writing brute-forcer to crack P12 private key because someone forgot password
LoL. Sure, I'm not an expert in any of those fields. I don't even like most of
them. Give me task to write Kotlin library (reimplementing React!) and I'd be
happy sitting in the corner for the next few years. But I don't have that
luxury and generally stuff I'm doing works well enough. And given our income,
it's just not possible to hire few competent developers and they would do
nothing most of the time anyway. But if I can do it all, I'm busy most of the
time and I can have some money as well. Full stack, that is.

~~~
nickpeterson
I'm sure your reasons are valid, but I laughed a bit when I read that you use
Oracle and don't have the budget for more people.

~~~
mmt
> I laughed a bit when I read that you use Oracle and don't have the budget
> for more people.

Why? Because you believe the former causes the latter?

There are many valid criticisms to be levied against Oracle the company,
enteprise software in general, and especially its pricing.

However, it's important to remember that, for many businesses, it's either
impractical or downright impossible to hire enough engineers to make up for to
lost features of replacing Oracle with even somethig as relatively feature-
dense as PostgreSQL.

~~~
stickfigure
_for many businesses, it 's either impractical or downright impossible to
[...] make up for [...] features of replacing Oracle_

I would have granted you this if you'd said "for a few specialized
businesses", but you're waaay overselling it. 99.9% of businesses using Oracle
would do just fine with a "lesser database".

~~~
mmt
> would do just fine with a "lesser database"

And I would grant you _that_ if you could make the credible argument that a
"lesser" [1] database could be a suitable replacement on a drop-in basis,
without significant engineering effort.

As I pointed out in a downthread comment, a very useful feature is that
existing stored procedure that encode business logic already work.

Are you really saying that only 0.1% of business database users fall into even
that category? My second-hand (DBA I know) experience contradicts this, but if
you have a better source, I'm certainly interested.

[1] I don't actually intend to make any overall value judgment, since my point
isn't that Oracle has feature/performance superiority over any other database.
Instead, I'm saying that it has specific features that the business needed at
the time it was chosen that may not be offered by a different one.

~~~
stickfigure
Of course once you already have application an built around a platform, the
switching costs can be high. See also: IE6. No argument from me there.

But Oracle doesn't sell their product with the pitch "hahaha too bad you're
stuck with us". They try to convince the next generation of ill-informed
technology leaders that it would be a mistake to choose anything else. I've
heard the pitch, and by the third time I heard "invest in Oracle RAC" I was
consciously suppressing the urge to punch the salesman.

I'm saying that 99.9% of Oracle customers would have been _significantly_
better off from a cost, flexibility, and support perspective going with an
alternative like Postgres when they started building their product. And most
of the remaining 0.1% would have been better off with MSSQL.

~~~
mmt
> I'm saying that 99.9% of Oracle customers would have been significantly
> better off from a cost, flexibility, and support perspective going with an
> alternative like Postgres when they started.

Although I agree that some huge proportion [1] of businesses _today_ would do
very well to seriously consider Postgres as the first option before even
looking at Oracle, I don't recall this being true 17 [2] or even 10 years ago.

Remember, we're likely talking about non-tech businesses here, ones where
they're sustaining operations with a single developer. You mention "ill-
informed technology leaders" but it's hard to imagine there are any
_technology_ leaders actually involved on the buyer's side.

I don't think it's helpful to look back at such a decision through the lens of
today's technologies and the kind of talent/expertise that is, today,
available to a business whose core competency is tech.

I'm no fan of "enterprise" anything, so don't mistake my critique as
cheerleading Oracle. I just feel the context of technology decisions is
paramount. It also seems especially germane to the overall thread topic, which
is whether a generalist can possibly have enough depth in key areas to be
considered competent enough in them.

[1] your repeatedly asserted claim of 99.9% is extraordinary, requiring
extraordinary evidence.

[2] Oracle 9i was released in 2001. EnterpriseDB wasn't founded until 2004.

~~~
stickfigure
I was building enterprise apps 10 years ago. 20, actually. I made the same
arguments then, and I will stand by this evaluation now.

It reminds me of the early 2000s when IBM and WebLogic were selling 5-figure
appserver licenses hand-over-fist into enterprises. I would have to dig, but I
do recall a study sometime later finding that almost all of these customers
were just using them as servlet containers. It's not that WebLogic, Oracle et
al have no purpose, it's just that the people buying these things tend to have
no idea what they're doing.

~~~
mmt
> I made the same arguments then, and I will stand by this evaluation now.

To whom? This particular business? 999 out of 1000 businesses (each of whose
needs you evaluated and found only one of whom really needed Oracle and
therefore excluded)?

What was the argument? That they could do it cheaper by hiring (possibly then
non-existent) Postgres DBAs and using Postgres instead of Oracle DBAs and
spending exorbitant amounts of money on Oracle?

To us, technical people, that argument might sound perfectly reasonable, but
to a non-tech executive it might sound cuckoo-bananas crazy.

> It's not that WebLogic, Oracle et al have no purpose, it's just that the
> people buying these things tend to have no idea what they're doing.

This strikes me as a dismissive stereotype. As you admit, it's not as if they
made a choice that failed to function at all. Social proof is a thing. They
merely paid a very high price.

Where were all the people who _did_ have an idea of what to do, those 20 years
ago? Busy trying to educate them, or separate them from their money? How about
you?

~~~
stickfigure
Me? 20 years ago I was busy building ROLAP engines that ran cross-RDBMS,
because the customer had already decided to blow a million bucks on Teradata
et al before I even got there.

I'm not quite sure what your point is. It's all understandable because
nontechnical people were making technical decisions? That doesn't make it ok.

And yes, quite a lot of those overpriced appserver installs failed to
function. Let me tell you about the time I wrote the backend for Sprite's
Sublymonal campaign; their IBM-operated datacenter couldn't provision
WebSphere capacity in time (lead time > 2 months), so I ran the thing off a
couple VPS nodes (IIRC rackspace), hiding the whole project from their IT
staff.

~~~
mmt
My point is that overall context matters.

My point is also that making sweeping, moralizing statements like "doesn't
make it ok" (nor the repeated forays into other enterpise software topics)
isn't helpful in general, and it certainly isn't helpful in furthering
understanding or intellectual curiosity on the specific topic, as it relates
to Oracle and a single, generalist (arguably "full-stack") engineer performing
a sustaining and development role.

------
jchw
What makes you a "senior" engineer, anyway? I feel confident calling myself
fullstack. I'm not going to list all of the things I have done and know how to
do because honestly it would feel arrogant. But what lead to the thought
process that backend and frontend developers should be separate anyways? Yes,
it is complicated and time consuming to keep up with both backend and frontend
development, but there's no way you're telling me some people believe it's
actually impossible to do that. If you dismiss the frontend as unimportant,
what the hell are you writing the backend for to begin with???

I like coding and I definitely find programming enjoyable. But, importantly, I
don't write software for the hell of it. If you actually give a damn about
software development, I don't understand how you could simply dismiss one side
of software development due to where it gets executed in the stack.

~~~
gridspy
> What makes you a "senior" engineer?

You've spent enough time designing software that you can take a vague spec,
design a solution avoiding common pitfalls and following a very easy path.
Then you hand back a prototype followed by a complete and maintainable
solution to a happy client.

At that point, your services should no longer be _required_ to keep the
product working.

~~~
robertAngst
"But can you just change this?"

~~~
gridspy
;)

Of course, it's software. We can change anything!

Even better, I'm not busy trying to keep your current software working - so I
can get right on it.

------
Glyptodon
In my view this is off base because it's a bit intentionally obtuse.

I think the real maxim is more along the lines of "if you need actual full
stack engineering, you don't want a full stack engineer."

Because full stack engineers are not there for large, highly engineered,
Amazon/Google scale sites.

They are there for the MVPs, the startups, the moderate scale internal line of
business tools, your local city government, or one-off moderate projects.

A full stack engineer is not there to have expert knowledge of every single
micro detail of front-end, back-end, databases, site performance, SEO and
such.

They're there to have a general knowledge of them, produce something
reasonable, and know enough of all the ends to ship in a timely manner,
hopefully with design decisions that can be easily tweaked, meet requirements,
and don't have boatloads of technical debt, until 'till it justifies a larger,
more specialized, engineering investment, or just putters on with light
support 'till end EoL because it's good enough for the scale of operation.

------
badasstronaut
what's the takeaway from this blog post? There's no such thing as a full stack
engineer so don't bother learning about databasing and server concerns and
devops; just focus on front-end? Are we just criticizing people for doing
their jobs to the best of their ability?

A full-stack engineer is not always going to write the best front-end ever;
there may be some kludgey stying and some non-semantic HTML (divs and spans!).
As a non-DBA, queries may not have optimal execution paths. There may be
questionable backend design decisions.

This is an obvious conclusion and does not really speak to the value that a
developer brings to an organization. Development is a means to an end, and
there are plenty of business cases that an experienced full stack developer
can solve in a 'good enough' manner.

We run the risk of letting the perfect become the enemy of the good. Any
mature developer should have one or two areas of deep expertise and have
enough skill in other domains to get a job done.

------
strken
I don't tell people I'm a full-stack engineer because I'm equally good with
every random piece of technology at use in a product, but because it signals
willingness to apply the imperfect human skills that I do have to different
parts of a system.

The front end of a single-page React application is a lot more complicated
than just HTML templates and CSS, and you can get all sorts of productivity
and developer happiness gains from being able to jump between front end and
backend - consider implementing the network layer in Redux, breaking out
validation logic into a shared library, or fixing a bug that can only be
understood by looking at both a front-end request and the endpoint that
handles it.

------
shp0ngle
This is a weird rant.

He is complaining that someone who does many things won't be as good in front-
end as someone who does only front end.

...ok?

Nobody expects full stack engineer to be _all that great_ in front-end. That's
why he is not a front end engineer.

Vice versa he won't probably be all that good in SQL or in administration and
devops.

I am not even sure what is this guy complaining about exactly

~~~
ricardobeat
Disagree. I expect full-stack developers to be _great_ at frontend, and
_capable enough_ to build the backend. When resources are constrained you want
the customer-facing side of the product to be a priority.

~~~
Terr_
> _great_ at frontend, and _capable enough_ to build the backend

I think that bias says more about the particular kind of company you're in
than the general label of "full-stack".

------
nidx
Whenever I interview someone I explain what Full Stack means to me. As a small
team we have to support the full stack of development. That means

    
    
      * provisioning and updating servers
      * installing and configuring software on those servers
      * keeping server system software up to date (Apache/MySql/Php/etc)
      * maintaining and developing custom frameworks
      * writing all the admin tooling for getting sites up and running and configured
      * working in our backends including writing queries
      * designing databases and migrations
      * maintaining deployment of new code and version control
      * setting up build systems for our apps
      * designing frontend systems (how they use api's, deployment of them, stores, etc..)
      * writing components and styling them
    

and that is just the web stuff. Not including the VR/AR/App stuff we get
tasked with building.

While I am a Senior/Team Lead and don't expect people to be experts in all of
that stuff, debugging requires at least being willing to take on any of that.

The author seems to think that just frontend development requires all your
mental capacity. I really don't want this to come off as me being arrogant but
feel very confident in my skills in everything he described AND I do all of
the above web stuff and more. I also manage a team and meetings and timelines
and quotes and resourcing and sales questions etc... It's not that hard. And I
know I am not a 10x or 100x dev (maybe 2-3x)

------
phektus
Even in a team of specialists, some of the work they do can be off-loaded to a
full-stack developer to free them up for tasks that require more of their
expertise.

For example, a front-end specialist would be better off optimising the slow
page response times of the product's news feed or implementing a new
application page altogether than, say, adjusting css that break on a few view
ports. In a big team, you can push the CSS fixing job to a junior; but in a
lean team, it's better if this goes to a generalist in your team.

If your backend dev is busy on implementing OAuth, he can off-load fixing a
bug that has a small fix but is hard to test like a minor refactor. You
compound this "minor" jobs and you will need a lot of junior staff to help on
the load, or you could hire a full-stack developer to help with the whole
team.

Eventually this generalist gains a good understanding of the full stack, as
his title implies, and can contribute good ideas that affect all parts of the
system. They also make good tech leads because they can interact and empathise
with all members, and can call out decisions that may seem good on one part of
the stack but could have horrible implications on the other end. Some progress
to Architects simply because they have the bird's eye-view of the whole
system.

Lastly, if you are a fledgling web startup, it would work against your
business interests to hire an expensive specialist right away.

~~~
taurath
The difference in flexibility between having 4 backend and 3 frontend
engineers on a team and having 2 backend 3 flex and 2 frontend engineers is a
huge gain in what that team can commit to in any given period.

------
unrealchild
Ha! Referencing your own tweet, from earlier this month. Awesome!

I disagree mostly. I’m pretty full stack from UI down to circuit design, but
that’s after almost 20y in the business.

~~~
throwaway756
I know, right? :)

To fully prove my point, here is a quote... also written by me. Huh?

Is that supposed to be convincing? Odd assumptions here. Like that guy on FB
that always likes his own links.

------
anonytrary
> Of all the engineers I’ve met over the years only one has come close to what
> that title, full-stack engineer, implies: the ability to easily navigate the
> back-end and front-end with a senior level of expertise.

In the first paragraph, the author sets up a really weak straw man for himself
to defeat. If you define "full-stack engineer" as "an _expert_ at front and
back end", it's pretty easy to not believe in it since you may as well be
restricting the category to people who are 3σ. If you define "full-stack
engineer" as someone who "can do front and back end moderately well". This is
much easier to believe in.

~~~
icebraining
Is it a straw man? The job openings I've read for full-stack developers
certainly seem to ask for experts in both.

------
gonyea
Yes, there is such a thing as a full-stack engineer. They'll cost you a lot of
money (or equity), but will spare you from herding an entire room of
specialists early on.

As products and teams scale up, cross-stack expertise becomes far less
valuable than domain expertise and institutional knowledge.

This post also leaves off another area that I'd expect of a senior full-stack
developer: Infrastructure/Ops.

------
ivanhoe
I think people don't understand what full-stack dev/engineer really is (or
should be). It's not a person who knows everything about everything, that's of
course impossible, but it's also not a person who knows only a little about
everything either. In my eyes a proper full-stack engineer is someone who's
currently deeply involved with X, while having a previous experience (of being
deeply involved) in Y and Z. As you move from one area of expertise to another
you, of course, forget a lot, you fall behind with the latest features and
approaches, but you still know enough about it to, first, be able to
communicate efficiently with an expert, and the second to be able to
relatively quickly get back into the saddle, if needed.

~~~
dexterdog
That just sounds like an experienced developer. X Y and Z could be Bootstrap,
React and Angular. In that case you have an experienced front-end developer.
In my view a full-stack developer is somebody who can write front ends, middle
tier logic and design and use databases efficiently. In various phases of his
career he should have worked specifically in each of these areas in depth. My
view also includes the idea that a full-stack dev should understand how
computers really work and should be able to spec a server/VM for a specific
purpose. There are not many of these people out there. Heck, I was shocked 20
years ago at how few devs that seemed like nerds to me didn't even know how to
take apart a desktop and diagnose a problem. Maybe I'm just an old guy and
should worry more about the kids on my lawn.

~~~
ivanhoe
I totally agree, that's exactly what I had in mind, X-Y-Z being a broader
areas, not just a framework or a lib. For instance, I worked (in the span of
now almost 20 years) on back-end, front-end, DBA and linux admin positions,
and I'm not counting in that all the C++ and Delphi desktop programming that I
did as a kid. This gives you a wider perspective on how things operate, and I
find it very helpful when consulting clients on sys architecture, since I know
how hard is to implement something in any part of the system and can plan for
that ahead.

------
jypepin
I understand OP's views don't represent his employer's, but it's still funny
to see Gusto (OP's employer) recruiting for full stack engineers on the front
page at the same time!

~~~
mandelbrotwurst
Quite. I'd be curious to hear what conversations if any he's had w/ them on
the topic.

OP, feel free to chime in!

------
renlo
The first time I touched HTML I was ~19 years ago for my middleschool's
technology class, where we were to implement a very simple (and ugly) webpage.

Later, in highschool, the first real programming language I learned was Java,
and I did some personal projects with that on my own.

After graduating college without any marketable skills in the height of the
recession, my sister (a SWE) introduced me to Python and then JavaScript. I
weighed my options and found that going into front-end development would be
ideal for me; I had an eye for design and it was simple enough to begin. I
learned JavaScript through-and-through, but contemporaneously I learned
backend web-development (via Python, Django and Flask). When an opportunity at
work opened up, I transitioned to doing backend development (of which I was
already familiar from personal projects).

Having done both, I do not see why they are mutually exclusive. I think the
issue is that most people who call themselves full-stack engineers do not
actually fit the description; it sounds like a good thing to label oneself. I
see this often with bootcamp grads who know JavaScript only, and can run their
code with Node, so they believe that they are now backend developers.

To learn the backend, I built from scratch: * a simple (and crappy) ORM * a
simple (and crappy) db-backed session system * a simple form-generator
(similar to Django forms, for flask) * login / user handling (etc)

To learn the frontend, I built a simple single-page-application, using vanilla
JavaScript.

I have worked for years doing both backend and frontend development (JS
visualizations for SVG/canvas, data-heavy SPAs, backend APIs, Golang services
to process data, work with AWS, docker, etc), and I doubt that I am unique.
Full-stack developers do exist, though of course one only has so much time and
"jack of all trades, master of none" will apply to many.

Many of these new-bootcamp grads build a simple Node web-app without realizing
many of the problems (and solutions) inherent in the backend and label
themselves full-stack. That's the problem; not that the frontend is somehow
too difficult to master, or that the backend is somehow out of reach.

------
tdurden
The author seems to think "full-stack" means the developer is an expert in
everything; that is hardly the case.

I would consider a full stack developer to be someone who likely has one or
more areas of expertise, but is able to quickly move out of their comfort
zone(s) and contribute in a meaningful way towards any part of the stack.

------
tckr
I agree!

I blogged this with the point of view of a full-stack developer that _can_ do
front-end development, but rather didn't a while ago:
[https://coderbyheart.com/the-full-stack-developer-
trap/](https://coderbyheart.com/the-full-stack-developer-trap/)

------
cm2187
This is starting from the assumption that every website must be an SPA, which
I am not sure I agree with. Most of the time you really don’t need that much
stuff on the client.

~~~
Double_a_92
But but... reactjs :( /s

------
tboyd47
I would appreciate this if more front-end specialists actually had all four of
the skills that the author claims separates them from full-stack devs: elegant
CSS, high-performance web engineering, accessible markup, and in-depth
knowledge of React/Angular/etc. I've not observed this to be true. All too
often a person only knows the JS framework and doesn't know/care about any
other aspect of their platform.

------
justaaron
The author supports bloated stacks driven by trendy concepts. I highly
disagree with nearly every point the author raises. At the end of the day,
there is http where there is the request/response cycle, and knowing how the
machine works is essential, so obfuscation and nonsense should be eschewed in
lieu of greater clarity of understanding. One can pre-load data into a server
rendered template but then one essentially has to load new data (hello xhr or
websockets) and update the dom accordingly. Everything else is just noise.
Full stack engineering gives one a comprehensive overview of the virtual
machine. While SPA and serverless architectures (not to mention graphQL,
postgrest, and other attempts to basically agglomerate the backend server onto
the database) alter this equation, having full comprehensive knowledge of this
is the equivalent of a mechanic knowing her/his engine, or a soldier being
able to field strip his/her armament.

So, here we have a click-bait title and our reactions are feeding into the
apparent pretensions to fame engendered.

next.

------
cam-stitt
The article is titled "I Don't Believe in Full-Stack Engineering", yet states
"If you’re only hiring full-stack engineers" as though they are something the
author believes exist.

It seems that the real approach of this article should have been to outline
why hiring ONLY full-stack engineers may not be a good idea.

~~~
jfz
The author probably meant that they don't believe that full-stack engineering
is beneficial compared to hiring primarily specialists.

~~~
cam-stitt
Potentially. Which is why I believe that it is more of a click-bait title than
a meaningful discussion point.

~~~
pseudalopex
It's a common idiom. Someone who says "I don't believe in psychics" means
"people who call themselves psychics don't have the abilities that implies",
not that nobody claims to be one.

------
grosjona
There are full stack engineers, lots of them. This article is extremely narrow
minded. It's like saying that there are no nuclear scientists because you've
never met one personally.

I remember the last big company I worked for, they asked me "What are you:
Front end or Back end?" and when I said that I could do either equally well,
they said something like "Lots of people claim to be both but you can be
honest with us, which one are you really?“.

I ended up doing only front end at that company for a while then got bored and
quit. My next company I did full stack and they actually got to see the
benefits of letting engineers use ALL of their skills.

------
speby
Well if he met me, he could add one more person to his list of people he has
met over the years that meet his expectations of "full stack developer."

To be honest, I'm getting sick of the front-end/back-end bifurcation that I
see literally everywhere now. I'm even guilty of it. It has this notion that
you are either back-end only or front-end only. It really leaves no room for
actual expertise that allows a software engineer to actually build software.

In fact, the terms back-end developer and front-end developer imply neither
person on his or her own can actually build working software without the
other. And that's total crap.

These terms started appearing more frequently in the mid-to-late 2000s and
nowadays they seem to be all over. But back in the early and/or mid-2000s,
"Web Developer" or "Software Engineer" or "Application Developer" sufficed and
it was implied that you could build software from scratch, soup to nuts. Of
course, in a large organization you had multiple "Web Developers" who surely
specialized in one thing or another in order to help their comrades out so not
everyone was doing everything at the same time to maintain sanity. But still,
as a "Web Developer" it would be expected that you could build software and
everything that entailed for the web. Not "Oh well I built the backend... now
you just need one other person to do the rest."

------
tabtab
It depends what the organization is willing to sacrifice. If you want
everything done well, then you should get specialists, or pay well for one of
the rare persons who can master almost everything.

Internal software usually doesn't have to be as aesthetic on the front-end
(UI) such that you can maybe sacrifice there, for example.

Sometimes you can throw hardware at poor performance if performance tuning is
not a person's forte, but sluggishness may snag you at a bad time before you
have time to upgrade to a more powerful box(es).

------
k__
I have to admit, full-stack stuff sounded really horrible to me, coming from
front-end development.

Databases? Containers? VMs? I don't even know where to start!

But when I got into serverless, it wasn't that hard.

Sure, with DynamoDB and S3 I have to manage aspects of my storage, but not
much.

Sure, whith Lambda and API-Gateway I have to manage aspects of my back-end
API, but not much.

Setting up a DB cluster and microservices with containers is something a fully
fledged back-end dev needs to do.

But getting something decent up and running with serverless technologies is
something I can do too.

~~~
ssijak
I would never call someone who can only do serverless on the "backend" full-
stack.

~~~
k__
Haters gonna hate, I guess.

------
roburtguy
I think that definition of "senior level of expertise" is a bit too much for
full-stack engineers. I actually have worked with many engineers who are very
comfortable working front to back end creating wholistic solutions. To me,
full stack engineer is someone who can design and implement a wholistic
solution. If you can build a todo app, you're pretty much a full-stack
engineer (a junior one and also depending on the todo app implementation).

------
erikb
The initial assumption is wrong: Full-Stack engineers are not expected to
traverse the whole stack with senior level skills and ease.

Also if you become really good at something you'll realize that actually it is
not all about more skills. There's a point where strategic decision making
overcomes coding skills.

E.g. 1: I spent years to really learn vim and git indepth. I can write my own
git clone and did that before as well. However I have seen so many different
editors and IDEs that I'm at a point where I can take whatever is there. I use
nano with ease if the situation requries it. This makes me quicker than
installing my favorite editor, my configs and then start working.

E.g. 2: The more experience one gains the more one sees that the biggest drag
on progress is usually misunderstanding, lack of info, lack of responsibility.
So nowadays I do more for my team by creating meeting requests with the right
people. For that I need to be able to read all of the source code and docs to
figure out where the actual problem is and who really has the expertise to
solve issues there. But I don't need to be as good as the topic expert.

------
redleggedfrog
"Front-end development is important today and it will be important in twenty
years’ time, it’s not going away anytime soon."

That I don't think will be true unless it's pertaining the eventual
abandonment of the web browser as the run-time.

The awful tangled spaghetti that is the current code for a web site UI is not
tractable going forward. It takes _way_ too much effort to make a usable
interface for the value in return. It's also too limiting. And too difficult
to maintain. These are all problems caused by using a run-time originally
developed for document browsing that has been pressed into service as an
application platform.

As a full-stack developer, the front end _is_ the most annoying to work on
because it's the most deficient and under-powered. Consequently, we don't put
as much effort into it.

Eventually it has to come to something more sane. Maybe web assembly running
in a virtual machine - in don't know. What I do know is the advancement of
computing is being hindered by the lack of a competent UI system.

~~~
etaioinshrdlu
Haha. No. The tangled spaghetti mess will only get worse. We are only going to
add more layers. People are not going to be sane :)

------
EnderMB
I can understand the authors frustrations. I too have worked with loads of
full-stack developers that have been fairly standard at both, or people that
market themselves as full-stack, but are either Ruby/Python developers that
can throw together a React app, or front-end wizards that can barely navigate
enough Rails to build a basic CRUD app.

Where the idea falls flat is where you draw the lines in each discipline. Do
you expect a front-end developer to have domain knowledge of all the leading
frameworks out today? Do you expect them to be immediately productive on an
Node/Express project? Additionally, on the back-end side, would you expect
that person to have written production-ready code in a set of languages like
Ruby, Python, C# and so, with full domain knowledge of all their respective
frameworks? There are front-end devs that know a huge amount on the frontend
side, and backend devs with working knowledge in a whole range of languages,
but it's difficult to find a (sane) person that knows it all.

But, if you're a Rails shop, it's not uncommon for someone to know Rails
really well, and be a solid frontend developer. If Ruby/Rails is your bag then
that person is a full-stack developer, even though they might be completely
useless if you're a .NET shop. Using myself as an example, I was fairly solid
on the front-end, but as I got more involved with back-end dev I found my
domain knowledge falling behind. I reckon I could throw together a halfway-
decent front-end application, alongside a Rails/Django/ASP.NET MVC
application, but I'd feel uncomfortable calling myself a full-stack developer
because I don't consider myself good enough to know it all.

I'd be doing myself and a future employer a disservice by selling myself as
such, but it doesn't mean that people don't, especially more controlling
developers that want control over every aspect of an application.

------
nightski
He attributes bad web sites to lack of skills. I'm sorry, but in my experience
it generally is due to lack of _time_ and _budget_ , no matter how experienced
you are. Experience helps a lot but not every site is worth pouring in the
money required to make it top notch. Some times meeting business needs matters
more than technical perfection.

~~~
afarrell
It also often results from lack of clarity in communication about things like

* Why are we doing this?

* What is the business value we expect from this?

* What resources do we need to do this to a level of quality where it has that business value?

------
devereaux
I didn't believe in full-stack engineering either, until I had a very hairy
problem that required fighting with various interacting issues to obtain a
specific level of "web performance".

And yes, I know about "font loading, images, SVGs, animations, auditing third
party scripts". Still sometimes, you have to dig deeper in the stack to find
the low hanging fruit that will make the difference between meeting
requirements or not.

After throwing away the nice SVGs and replacing them by inline PNG (uglier,
but you need that 15% size difference and the precious milliseconds), what do
you do?

My current solution is a combination of various things - the last element
being VPS close to the customers to provide resources with a very low latency.

(and by the way, if anyone happens to know reliable VPS companies in South
America, Japan, South Africa, I would love some recommendations. I only know
about Hetzner ZA and Linode JP. I would love to find some good host quality
around Uruguay or Brasil)

------
pluma
Show me a front-end developer that has mastered every aspect of front-end
development, or a back-end developer that has mastered every aspect of back-
end development.

Everyone else only gets to pick a somewhat arbitrary subset of those aspects.
Some pick subsets from both front-end and back-end (in fact even for a front-
end developer having at least some understanding of back-end development is a
good idea and vice versa). If those subsets have no clear bias for one over
the other, congrats: you're doing full-stack.

Yes, the label is misleading, not every full-stack developer can literally
work at any level of the stack equally proficiently. And if they're relatively
new to programming they may have spread themselves too thin.

Heck, in the 90s most web developers were "full stack" by necessity (mostly
because there wasn't much of a frontend until CSS gained traction and AJAX
became a thing). Back then we just called them "webmasters".

------
aphextron
Completely agreed. "Full-stack" developers fall into two camps; that is the
"web developers" who know enough PHP/Node/Whatever to build a CRUD app with
UI, and the serious software engineers who treat front-end as an "oh whatever"
afterthought. Both end up with nothing but a huge mess at scale.

~~~
thebooglebooski
Web developers are not serious?

~~~
aphextron
That's not my point. I'm saying that there's a difference between the full-
stack generalist "web developers" who know HTML/CSS/JS/PHP/Ruby, and software
engineers who build complex systems, typically in Java/C#/C++.

~~~
nicoburns
There are also people who do both. I started out with JavaScript and PHP and
do a lot of React/Angular/Laravel stuff. But I have also worked on complex
performance-sensitive business systems written in a mixture of C++ and Rust.

My boss at my last job had done the opposite. Coming from a tradtional compsci
C/C++ background (many moons ago), he learnt Angular 2 for a frontend project
that required it. Both his C++ and frontend code were among the best at our
company.

Saying there aren't good fullstack engineers is like saying multi-
instrumentalists aren't good musicians. Sure, the very very best violinists
probably don't play other instruments at a high level. But the average multi-
instrumentalist (who plays the violin) is a lot better than the average
violinist.

------
qntmfred
"Those that say it can’t be done should get out of the way of those doing it"

~~~
bdcravens
And sometimes that who are doing it need to listen to those who are asking the
question, "Should it be done?"

------
mcv
I don't care what they call me, as long as I'm not stuck in a single
environment. I like programming, whether it's on the front-end, the back-end,
or somewhere else entirely. And I care more about programming than about
design, image optimisation, database optimisation, or configuring containers
and deploy tools. I understand those things come with the job, but they're
never going to be my strongest point.

I'm fine if people just call me a programmer or software engineer, but it
seems that these days, full-stack developer/engineer is what people need to
know in order to place me.

------
shapiro92
The article is lost from it's first sentence. "with a senior level of
expertise" No a full stack does not need to be senior in all, if you want a
Senior Full Stack engineer maybe.

The fullstack engineer or T engineer is someone who shows versatility when it
comes to the tasks given, he has an issue on the FE that is related to BE. He
doesnt need to solve it but if the understands and then can point to the
person who can fix it quickly thats key.

~~~
shapiro92
Also sorry did anyone see the bio of this guy? he is not even related to
engineering unless he lies in his bio:

"I’m Robin, a web designer, writer and typographer living in San Francisco."

------
flashgordon
Oh thank god! Finally glad to see this koolaid getting dispersed. I hope some
of the glory gets reimbursed to embedded and systems level engineers too :)

~~~
ssijak
You sound like someone who is not good or dislikes either backend or frontend
work and cheers for anybody who says that one person can`t do work. There are
many of us who can.

~~~
flashgordon
So on the contrary, I am a generalist and love poking around all over the
stack. But that's it. I am a crazy breadth person but dont like to go into the
depth at each level as that has way too much overhead for me. So that limits
my expertise (but not love to tinker) in any one area. In companies/places
where we need to go beyond POC apps, standardization (within stack and tech)
kicks in, and you are not going to be productive if you are not doubling down
on one or two areas. Worse are political problems where as an "apps engineer"
where you are implementing a bunch of interfaces but diving deeply requires
you to transcend org boundaries (again I am not a fan of that, just reporting
as I see it), limiting your productivity.

------
hideo
I've always wanted to build a server from scratch: build a simple chip running
a one-trick web server that can respond to a GET request and have it serve up
a single page application, and a not-a-lot-of-bauds serial modem connected to
the internet through a gateway of some sort. It'd probably take me a year of
nights and weekends, but at the end I would be comfortable calling myself a
full-stack developer.

------
dfrew
Click bait title with strawman argument. By this author's definition most
engineers are not engineers because they're not experts. The moment 'expert'
is removed from the definition the argument falls apart.

Some people want to focus on front end problems, some want to focus on backend
problems. I personally just want to focus on problems. I'm neither front-end
or back-end. I'm a software engineer.

------
Fire-Dragon-DoL
Pretty sure software architecture applies to both frontend and backend
development, but for whatever reason, most frontend developers seems to ignore
it (not everyone, but most public libraries are terrible architecture-wise).

Since the skill it's transitive and it's one of the skills that gives the
highest value long term, I don't see how there couldn't be a fullstack
developer.

------
dosethree
The best teams are T-Shaped (specialists who also generalize) that doesn't
mean they are specialists in everything, but as a team they have the expertise
they need collectively. Those teams work well because when someone is on
vacation you can still execute as a team because you cross train. It's not
rocket science here people

------
bradleyjg
In my experience companies looking for full stack engineers want a fully
competent front end engineer that’s willing to get his hands dirty with a CRUD
backend. Specifically not someone that’s mediocre at everything, and at least
for reasonable hiring managers, not someone that’s an expert at everything.

------
pjmlp
So I when write complete applications myself, native/web frontend, backend
system, stored procedure at the DB layer, talk with all parties, architecture
blueprints, what I should call myself then?

I know, consultant with expertise delivering delightful experiences.

------
dmritard96
meh. I consider myself pretty fullstack - plastic forming to css and most
things in between. Am I your guy to write the best ISR on some rando chipset -
no. Am I your guy to write the most optimized query and tuning with a deep
dive in the query planner - no. But I know enough about each respective domain
to go deep when needed (google makes this more doable today than ever before)
and I can get an MVP far faster than a specialist. I don't mean to knock
specialists but rather to say there are roles for both and believing in one or
another is the wrong place to focus.

------
ConcernedCoder
"Because there’s no such thing as a unicorn and there’s no such thing as a
full-stack engineer."

Ridiculous to find out I've been doing the impossible for 15+ years now?
Somebody give me a raise!

------
iblaine
Full stack engineer means knowing CS fundamentals. With that you can do most
anything, except good UI/UX development. Leave that to the web developers.

------
oooooof
Errr.... hold on ... I can build every component of a complete system, front
end, back end, deployment, database.

Maybe I don’t exist.

------
cobbzilla
As evidenced by the first dozen top-level responses (largely written in
defensive tones from self-proclaimed "full stack developers") it becomes clear
that everyone has a different definition for the term.

Thus, I find this entire conversation to be mostly useless, except as a survey
of what the term "full stack" means to different people, particularly those
who brandish it.

------
i6Respawns
Great article, lots of trigger in this thread but what you're saying
resonates.

If you read between the lines, you could pretty much say that as much time as
you split between backend and frontend you would need to become a solid
engineer in either of those domains.

------
ww520
Never says never. You'll be amazed how good some engineers are.

------
rboyd
what an awkward little article

------
trentnix
Specialization is for insects.

~~~
elliotec
One of my favorite Robert Heinlein quotes.

------
gaius
Full-stack cannot truly exist because of the clash of cultures. Front-end
values that which is shiny and new, the latest framework in the latest
browser, code 6 months old is already obsolete, code 2 years old has to be
rewritten entirely because all of its dependencies are broken now. Experience
is not valued because no-one has any in the current trendy tool, it's too new.
Whereas back-end values that which is mature and stable, code that is 10 or 20
years old is considered to be proven and reliable, experience is highly prized
because it shows its value in day-to-day work. When the cultures crossover you
get horrific things like node.js or MongoDB.

That doesn't mean there aren't front-end people who can write a bit of SQL or
back-end people who can throw together a simple website. That's fine, those
are basic commodity skills now. But everyone has to choose the culture they
are comfortable with and that will dictate where they fall on the technology
spectrum too.

------
throwaway756
Apologies in advance for the negativity, BUT....

I wonder how many people honestly believe that they are doing good "social
proof" work for their career when they publish pieces like this.

However, many of these read as insecure, pedantic, and a decent lack of self-
awareness on the authors part. Tone deaf. Pretentious SV "influencer word
salad". When reviewing resumes, I always do a ton of Googling. This would have
given me a bunch of soft data points that would potentially outrank his/her
resume

"Full-Stack Engineering" as defined by Robin Rendle - would have been a more
honest title, but no one would have clicked.

------
stuckinarut
All this talk of front end and back end and I'm just sitting here not knowing
how to do any of it.

At least I get paid lots of money.

------
the_narrator
This really comes off as a rant by a front-end developer complaining about
full-stack devs not being as good as them.

------
suff
A full stack developer is what turns into an Architect. If you cannot build,
operate, tune and debug the full stack, at scale, you are not an architect.

~~~
bdcravens
I wouldn't agree. A building architect isn't an expert at all the trades that
are required to fulfill his design; he just has a strong understanding of how
everything fits together and what is/isn't possible.

~~~
zaphirplane
Agree, and the mess is when an architect thinks they are the head and know
better than everyone else. I doubt there would be a mess if the architect said
let’s do x and someone said oh no y is a better approach and they lived
happily ever after ;)

------
winton
If you can build a web site with React + Firebase + Google Cloud Function +
CDN, you are a full-stack engineer.

~~~
ssijak
Not even close.

