
Full-stack developers are in fact stuck at mid-level. Don’t go down that path - atomlib
https://habr.com/en/post/436596/
======
pavlov
I consider myself "full-stack" because my average work week nowadays seems to
include a constant mix of four kinds of development: back-end performance-
intensive rendering services (C++ inner loop kind of stuff), back-end "devops
light" service design work and glue scripts, back-end automation work (random
shit like PHP/Hack scripts to wrangle data), and plain old front-end (SPA
React nowadays).

The post author seems oddly upset that someone corrected his TypeScript design
choices. If you want to do full stack, you can't take feedback personally. I
regularly get code reviews where I've done something that's standard practice
in one language but a no-no in another, and I just didn't remember. (PHP/Hack
is like ground zero for these gotchas.) That's absolutely ok — that's why we
do code reviews after all!

My real expertise is the C/C++ level stuff, but I write the other code because
I'm basically the domain expert. The value of that code is that it's doing
something useful and nobody else had to be assigned to write it; not that it's
"ideal PHP" or "beautiful React" right off the bat. That can always be tweaked
and refactored in code review.

Summary: in "full stack", you can't afford ego about your code, but you need
conviction about the value of your contributions. That often means you need to
spend time understanding stakeholders or user needs rather than e.g. reading
TypeScript release notes.

~~~
ptero
> I write the other code because I'm basically the domain expert

I think this is a key point. In my experience there are two paths for
engineers to senior level positions: (1) management, which is usually easier
(more openings available, engineers may find it unattractive) but slowly moves
one away from technology development, or (2) domain expertise which is
technically harder to achieve (need to be _recognized_ as expert) but often
provides more freedom and allows staying science / technology focused.

Each path requires some (different) soft skills which are more important than
maintaining either a super broad or a super focused "stack". My 2c.

------
harel
That is a load of rubbish. I've been coding for various platforms and
languages for over 20 years. My understanding of how software is built
surpasses any language specifics, however I'm very proficient at a senior
level with both front (JavaScript) and backend (Python) development and I can
jump into Go, Java or PHP when I need to and set up complex server
infrastructures. What I do, absolutely requires me to fully understand all
sides of the software product. Not just for my clients, but for my own
businesses which I could build because of this understanding. I'm not special
here. Many full stack devs are very good (to a senior level) on both ends of
the stack. This article is the writer's projection of his own failure to
progress while dancing in both weddings. There should be an ethical disclaimer
on "advice" given in authoritative tone that are purely based on one's own bad
experience.

~~~
XCabbage
When you say

> My understanding of how software is built surpasses any language specifics

do you mean that sure, you don't understand all the language specifics, but
that's unimportant because you understand the high level? Or do you mean that
you keep track in detail of developments in each of the five languages you've
listed (to the level of detail of reading all their release notes and testing
every new feature, knowing about the characteristics of all different flavours
of index in SQL databases, and knowing best practices for managing state in
React components, as suggested in the article)?

If the latter - if you truly have an encyclopaedic knowledge of every tool you
use - then, well, congratulations, but I hope you realise that nearly all of
us who work with a diverse array of technologies never achieve that mastery.

But if, on the other hand, you're casually conceding that you _also_ don't
have the low-level mastery of the tools you use that you would if you worked
with only one of them every day, then... maybe you shouldn't be disdaining the
author as a failure for failings that you also have?

~~~
darkerside
What does being "senior" mean? I think it can entail many different things,
from understanding the business, to work relationships with your stakeholders,
to architectural expertise, and on and on. Compared to these, knowing the
latest and greatest updates to any given programming language is fairly minor,
especially when it's not the one you're working with at that given moment. You
can catch up JIT when you approach a given problem on a given language
instead.

There's no reason to think you came be senior in multiple languages. Even if
they were unrelated and separate, you could do it, it would just take
multiples of time. But the fact is, they are related. Concepts apply, and
actually enhance when you apply them, across different paradigms. It doesn't
work in a way that easily conveyed in passing comments (otherwise being a
senior might be way easier!), but as you progress, your pattern matching brain
will start to see and expect certain things from the languages you work with.
That's what makes you am effective programmer in a language. The sense that
"there has to be a better way to do this". Not knowing immediately what that
way is.

~~~
harel
When I hire, I never say "senior" or "junior". I don't care for those titles.
They mean nothing. I meant "senior" in the "conventional" sense to match the
language to that of the original post.

~~~
darkerside
Likewise. Is it not still worth defining the inherent characteristics, even if
it's not a job title?

~~~
harel
Characteristics yes. As in what will one be doing during working hours, or
what one delivers. However, I've seen "seniors" who really had no business
being in software development. No idea how they claimed the "title". While at
the same time I see what the industry labels as "Juniors" due to number of
years in the job market, being so amazingly good at what they do that they put
said seniors to shame. Yet the "business" needs those labels to justify a pay-
grade of sorts. This is wrong in my opinion. Compensation should match the
ability, not the number of years someone had the fortune of being employed at
this or that capacity or how good they can blag through an interview.

------
szggzs27
Sounds like the author is blaming his shortcomings on full-stack development
and is making a poorly thought out generalization of what full-stack
development entails. Thinking that he can best people who boast many years of
experience puts him right where he belongs in terms of experience and being a
laughing stock.

More likely than not, he is stuck at mid-level because of his lack of humility
and arrogant approach to seniors, traits that would make a terrible technical
manager.

~~~
jypepin
> I once cranked out a design based on abstract classes in TypeScript, and got
> ridiculed because apparently nobody does it this way in TypeScript. I
> certainly pretended that my colleagues were hopeless idiots. It used to help
> before, but that time it left me with a bad aftertaste.

seems like both he and his coworkers would need some help in humility.

~~~
seattle_spring
Are you suggesting that abstract classes are a good idea in TypeScript?
Because to me, abstract classes suggest that you're doing a lot of
inheritance, which is the opposite of a good idea in JS.

~~~
XCabbage
Why? Old-school pre-ES6 explicit prototype wrangling was confusing, but what's
wrong with using inheritance if you're writing in TypeScript (or, for that
matter, a JavaScript version with classes)?

~~~
perrohunter
Too much abstraction can be bad as well, many times I’ve written a nice class
diagram to discover no one really needed to reuse certain functionality, a
function would have sufficed :P

------
seanwilson
I'm assuming this is aimed at people wanting to be hired by companies with
large teams as a developer where you can focus mostly on a single area?

If you're working freelance, as a consultant or building a product, people are
paying you to spare them the technical details. They don't care what language
you claim to be a guru in and you shouldn't shoe horn in your preferred tech
stack when something else is more appropriate. Also, if you frame yourself as
just "an expert in language X", you're only setting yourself up as a
replaceable commodity.

I think having the skills to understand business goals combined with the
ability to design and develop solutions where you're flexible about what tech
stack is used is much more valuable to businesses.

Also, I don't understand the false dilemma of having to choose between being a
"jack of all trades and master of none!!!" vs "super guru in one area". It's
very practical to get to expert level in several languages and frameworks,
especially given the similarities between many of them. If you spend all your
time on one language/framework, you're going to quickly reach diminishing
returns in terms of what you're learning vs how useful in general it is.

How much better are you really going to get at Python after spending 1 year, 5
years and 10 years with it? Surely at some point you're just learning obscure
tricks or the ins and outs of libraries that are going to be outdated in a
year or two anyway? Why is that valuable compared to being more well rounded
and learning transferable skills?

If someone has been programming for a long time and they only list they're
highly proficient at one language, that's a red flag to me they lack
perspective and are unlikely to be able to architect solutions that require
the bigger picture.

~~~
robodale
_I think having the skills to understand business goals combined with the
ability to design and develop solutions where you 're flexible about what tech
stack is used is much more valuable to businesses._

Very well-said, and needs to be repeated here every time someone posts on HN "
_What language, framework, shiny-new-object should I learn to get the best
job..._ "

------
jypepin
I'm a full stack developer. I thought I was going to agree with the article,
at least for some parts, but I actually disagree completely.

What the article says is true, but you could replace fullstack with any other
role, name the article "You'll never be the best" and the article would still
be true.

Even if you specialise in something, there will still be others that are
better (and if they ridicule you, they are just assholes) and more things to
learn anyway.

The author is mentioning a lot of specific technologies (react, databases,
python) that, even as a pure "backend engineer" or even a "database
specialist" would still face the issues mentioned in the article.

Specialising and going deep is great, as staying broad and doing more stuff.
You just need to understand where you stand and what your strengths and
weaknesses are. You can always specialise more, and more, and more. Specialise
in backend, or actually .NET development, or actually databases, no I mean
SQL, actually I mean scaling SQL databases, etc.

------
supermw
Don't listen much to this guy. Full stack developers aren't doomed to fail,
the only thing that happened here is that _this_ guy failed miserably. He
failed because he focused on the wrong things.

If you want to be a full stack developer, the quickest way to get there is to
build an entire application all through it's layers by yourself. Front end,
backend, and databases. And the more complicated and demanding that
application is the faster you will learn. Learn how to do migrations and
backups, learn security concepts and how to harden your application, learn
about the intricacies of UX and UI design. Know the seven layers of OSI and
get your hands dirty with them. Learn actual system programming. Stop using
fucking ORMs for your SQL.

Don't do what this guy did and master languages deeply and then think that's
what makes you full stack. You could actually get away with lesser
understanding of languages and technologies if you are very skilled in knowing
how they fit together.

~~~
Novashi
This is a good technical approach but if you get this far, your salary won't
match the value delivered by your actual skillset.

Companies know this. There's not appropriate compensation for people who can
get comfortable with this breadth of stuff. Fullstack is currently "exploited"
because of this IMO.

~~~
Slartie
That is true. Your salary will most likely not reflect your actual value, but
will be way below what you should actually earn.

But - if you do it right (and with a bit of luck), you can work yourself into
a position in which you've got a lot of freedom to choose what you want to
work on, and that freedom is worth a lot in itself. Because you're the one guy
that can "get everything to work smoothly together" and that is able to
deliver entire working solutions, while practically all the others may be able
to get a single part into good condition, but they stumble when it comes to
getting to something working in a greater context. Their solutions will
inevitably be less polished than yours.

People are not indifferent to this. It takes a while, but they notice it. And
you will be in high demand because your solutions have this really nice
tendency to "just work". And nobody will really understand why it is that way.
Which means you'll be able to largely direct what you're going to work on
next, because since nobody has a real clue why your stuff "just works" all the
time, they are doomed to rely on your opinion when it comes to where your
specific skill set is most valuably used next.

~~~
james_s_tayler
This is the direction that my career is taking. Definitely the benefit is you
eventually get to work on the good projects that you want to because people
trust you to deliver a level of work they don't seem to get very often.

I've always felt relatively underpaid compared to what I wind up bringing to
the table, but I would say there have been subtle but noticable perks in other
ways and it's definitely translated to comp over time too.

It clicked for me a while back that the vast majority of devs just working on
line of business applications have never and will never put together an entire
enterprise grade system end to end by themselves in their career. So all you
really have to do is (a) have a relatively good head on your shoulders and (b)
just hack away at building out a fully fledged system end to end in your own
time. A sort of reference architecture of your own. Then when you need to
implement stuff at work, you've already solved the problem once before so
instead of taking a day to wrap your head around how a particular part of it
works, you just whizz through it relatively quickly. It looks like magic from
the outside, but it's nothing more than being prepared ahead of time.

------
alexandernst
The author doesn't understand the actual value of a full-stack developer.

A full-stack developer is not a 10x ninja developer in every
language/technology in the "stack". A full-stack developer is a developer that
has good enough understanding of a stack of technologies (say Django for the
backend and Vue for the frontend, maybe Swagger in the middle, and PSQL for
the database) to help the team fix integration issues between each layer of
the stack.

~~~
delinka
"Full-stack" is the jack-of-all-trades. Ergo master of none.

~~~
c17r
In truth it’s more like jack of all trades, master of one or some. 20
something years ago you didn’t hear the term full stack, you did everything —
database to UI — because that’s just what you did.

These days as a consultant, I tell people I’m full stack with more emphasis on
the back end.

~~~
james_s_tayler
I like to say "some parts of the stack are fuller than others"

------
shove
The comments here are (predictably) negative, but it takes a lot of self-
awareness and courage to not only say, “I used to think X, but now I think
that was a mistake” but also to publish it publicly and invite feedback and
ridicule.

~~~
C1sc0cat
Though the author seems to be laser focused on career progression and $$$ (I
suspect due to cultural bias's)

"I had practical skills in all aspects of professional software engineering."
I don't see any layer 1-3 skills there.

I would expect a full stack ie layers 1-7 developer to be able to design and
get implemented a small network.

~~~
james_s_tayler
Not really?

It typically just means front-end, back-end, database. Not networking? I know
it says "full" but it's not that full.

~~~
joelbluminator
They also have to build their own computer and a small generator that creates
electricty, and probably their own wifi router. otherwise they're mediocre and
don't understand how stuff REALLY works.

~~~
C1sc0cat
I do seem to recall as a child making a small generator Dad got me a kit
designed for kids for Christmas on year.

Though I think Layer one assumes power and the pys media exists :-)

~~~
AstralStorm
Power is assumed, yes, but it deals with physical media directly. That's what
1 is. You make or design the RF level hardware. Layer 2 is where PHY is a
separate entity - driver stack starts at the lowest point of this. (Used to be
higher but now more things are offloaded to firmware or hardware.)

------
jackcosgrove
I think on one level the author has a point. Fullstack developers make sense
for early startups who can only hire 1 or 2 developers, or who only are 1 or 2
developers. However once you start growing and probably need to rebuild your
app, it's time to hire multiple specialized developers.

If an established company is recruiting fullstack developers it could be
because there is a manager who thinks, "Why hire two developers when I can
hire one?" Which is magical thinking as there is always a trade-off.

------
james_s_tayler
This guy is painful. What a junior attitude. And please never "retrain for
management". Just don't. Please don't. You are exactly the wrong kind of
person for it.

------
o12v
If you expect to be a generalist by somewhat half heartedly knowing how to use
a number of technologies you're doing it wrong. What makes you a generalist is
not just being able to use tools, but rather understanding how they work. That
means for web frontend work you should rather step towards understanding how
the dom and v8 works instead of jumping on the newest hyped framework or
instead of just learning react's api maybe also understand how and why they
are building their own virtual dom. If you do backend work you eventually want
to look into compilers and understand the difference between interpreting,
compiling and jit-ing code. If you do database things you may want to start
thinking about how you would implement your own and touch on things like
transactions, consistency, how a query optimizer works or what structures data
is stored in. Not that you will ever be tasked with building your own frontend
library, language, compiler or database; but all that helps you immensely to
understand and evaluate the tradeoff space and also quickly jump on the newest
hyped thing if it actually is a good idea.

------
tetron
The codebase at my job is usually complex - Python, Ruby and Go, along with
JavaScript/Typescript and a little bit of Java and R. I used to be in the "all
programming languages are basically the same" camp but jumping back and forth
between technologies has given me more appreciation for the details. Some
knowledge I've wished I had at my fingertips: semantics of Go channels
including all the edge cases, the scoping semantics of Ruby blocks, anything
in the JavaScript standard library, the ecosystem of Java build tool and
helper libraries. Having to stop and look up things lowers my development
velocity compared to a specialist. In the other hand, as a generalist I can
trace a request across component boundaries and go as deep as needed into a
system to diagnose issues. So I think it depends on what kind of projects you
are working on. A "serial generalist" that goes from one tech to the next is
always going to be behind the curve, but that isn't really what I would think
of as a full stack developer, either.

------
steve_adams_86
Another side of this is that there's demand for full stack competency. Even if
it isn't perfect comprehensive knowledge, it's enough to get difficult jobs
done. I think this person was striving for perfection where it's not really
feasible for most people, or even necessary for most jobs.

I've tried several times in my career to focus on a skill but because I was
able to do many other things, I was asked to by my employer. I rarely say no.
My last job was originally supposed to be 'make these products faster' with a
focus on the backend, but it turned out the frontend and anything in between
the two was as much a part of the problem. Not only did I fix issues on the
server, but I re-architected the frontend to a degree, moved all assets to a
CDN, significantly improved the js code's tree shaking, code splitting, and
lazy loading, tackled minutiae like compressing images better, using a faster
and more secure alpine image, and the list goes on.

I didn't really want to do that stuff, but I could and it needed to be done.
And the reality is that even though I'm not a master of anything I do, no one
else at that company had done those things despite having the opportunities
(indicating they didn't know how or didn't even know it needed to be done),
and the main application I worked on was sped up a ridiculous amount. I
remember we had accounts that took an actual honest to dog minute or more to
perform an action, and when I was done it did the same thing in a few seconds.
It was a game changer.

The people I worked with were awesome at what they did, and in a sense I was
only standing on their shoulders. But they don't understand the entire stack
well enough to connect the dots like I did. So that's where full stackers
really shine, I think. Sometimes I think I get too much credit on teams for my
contributions because all I do is make sense of things and break it out into
tasks that most of the team is already able to do. But I suppose there is real
value in bringing the bigger picture together for your team.

------
perrohunter
Once my architect wanted everything on python so I obliged, because of the
size of the data I went with spark, but since we were using python I had to
interface with it using pyspark, which still uses python 2, after a few months
we start having all this problems with the py4j bridge in spark collapsing and
us having to restart the service every few hours.

Fed up with the situation I rewrote the thing in Java/Scala and we haven’t
touched the service ever since.

My point here is that using the right tool for the task can mitigate a myriad
of issues, all the python knowledge in the world was not good when working
with a java tool.

What is needed is balance, not every language is good for everything, not
every framework can do it all and certainly not one engineer knows it’s all
(either the individual contributor or the manager)

~~~
Aduket
hi, when did all this happen? isn't pyspark almost on par with scala
implementation now ?

------
TheCycoONE
As a fellow full stack developer, I can relate. I have been called out for
using Optional too broadly in Java because I was trying to treat it like Rust,
and I too need to research specific syntax and API on a daily basis. On the
other hand, when our company was bought out and I had to change technologies
fast I think it was an asset. A year and a half in and I am clearly a senior
dev again. Not the owner of any domain anymore, but like the article says,
someone they come to to bounce ideas off of, and someone who can identify the
cross domain architecture deficiencies with a concept of how to fix them. Also
because I have to research constantly, once in a rare while I stumble across
an elegant solution the domain experts weren't aware of.

------
karmakaze
At my last startup, we tried full stack development in conjunction with pair
programming. Fullstack dev is hard essentially have to be great at both back
and front end and some UX. Pairing helped. In the end many didn't want to
continue preferring to specialize. That was a shame because like pairing, full
stack is a nonstop dev flow, no pauses for talking to other 'end' nor code
review delay.

Because it's hard to build that culture it's ew rely done and so there's no
market for it. What full stack means in the market is front end with a little
back end and doesn't pay specialty rates. Actual full stack is a specialty
just so rare it's not even 'a thing' in the minds of employers.

~~~
nickstefan12
> What full stack means in the market is front end with a little back end

So much this. I believe in full stack development skills, that someone can
have them, but I don’t believe in the job role of full stack developer.

At small medium scale, there’s just so much more front end work on a lot of
apps. Let’s say 70%. My experience with full stack as a job role is that it
turns into “what backend change can I quickly make in order to get back to the
front end work which is most of the work.” Which then means no ones manning
the ship / design / scope creep / perf risks etc of the backend. I think
separate roles lead to more even evaluation of best feature implementations.

------
justaaron
Unless one literally does not care about computers AT ALL, and is content with
front-end development, having no hobbies involving any OTHER kind of
development etc, one will end up being a bit of a "full stack developer".

I, frankly, don't trust career coders who don't have an active interest in the
broader activities around coding, software, hardware, maybe HDL's and FPGA's,
or low-level stuff with microcontrollers etc.

as it appears that a career coder who specializes and then expresses no
further interest in branching out is merely milking a perceived cash cow and
not going to show an interest in how even the specialized piece they are
building inter-relates with the other pieces of the puzzle.

~~~
nkozyra
> I, frankly, don't trust career coders who don't have an active interest in
> the broader activities around coding

I think that's unfair and ends up feeling a lot like signaling to me.

Some of those things I'm very interested in, but there are tons of development
things I'm just not excited about. I don't care about containerization trends,
about kernels, not all that interested in chasing the new shiny front-end
stuff. I am curious about FPGAs but don't have enough reason to go farther
than that. I know devs who do not care about machine learning, about
databases, whatever, but are very adept at their areas of interest. If I talk
about my hobby work with robotics and microcontrollers and another dev isn't
interested at all, I'm not going to judge their general skills.

Expecting people to be excited about anything related to computers, hardware,
general engineering isn't very realistic. It's such an amazingly broad cross-
section of fields and interests.

~~~
Ragib_Zaman
I think OP was saying he would be suspicious of a coder who was not interested
in at least one area outside their professional domain, not any given area. If
that's the case then I have to say I agree with them.

------
danielovich
One problem is that people think about seniority as expert level in something.

In my terminology, when you are a senior you need to be a near expert in
whatever you call yourself a senior within.

If that's .NET/C# like the author refers to, you must know how all (the
esoteric) features of the language (e.g C#) behaves, you must know IL, WinDBG
for advanced debugging and the things along those lines.

So many developers claim something that they are absolutely not, which is
experts or senior in a technology.

It's IMO much harder to become an expert in something than to learn a subset
of a set of technologies. Much harder actually.

~~~
james_s_tayler
I would class your definition as expert rather than senior. It's a level above
what I'd expect.

Then again seniority has many dimensions. I often see a lot of senior devs who
have mid level skills or mindset but they have become domain experts or
experts in the product and seniority is conferred that way. I don't
necessarily think that is wrong or undeserving either. I guess if we are
talking absent any business/domain knowledge then seniority is judged more
closely off raw technical familiarity. For me it's about system
design/architecture. Having a strong set of principles that guide your
decisions etc.

------
justaaron
Here's some additional unsolicited advice: Work on your own skills instead of
dishing out advice on how to approach systems you appear to only superficially
understand :)

------
franzwong
I also have the same question about how to improve my technical skills. I
don't think it is related to full stack or not. I found that most of the
companies require developers with mid-level skills only. I don't have enough
chance to improve because there are no difficult problems in my job. I would
say if you think you are not good enough, simply move to companies which give
chances to solve difficult problems.

~~~
pintxo
The thing with programming, contrary to pretty most other fields, you have any
possibility to do something diffcult in your free time!

------
Griceraae50100
Personally, I'd prefer to have a broader albeit less competitive set of
knowledges as a full stack (this should be defined, though) developer. I do
not see it as a flaw.

Back to my backend days I was on the brink of the burnout but switching to
frontend gave me breath of fresh air. When I found a modern frontend as a
total mess I started to dig into devops and it surely improved my competencies
as a backend either.

------
lostjohnny
I agree with the first part of the title, the only thing I've read.

I completely disagre with the second part: full stack developers are not stuck
because full-stack is bad per se, they have chosen to not master one single
skill, preferring instead to learn many of them, with a varying level of
confidence, from master to "I can learn it, if needed".

------
joelbluminator
I see no reason why a backend web developer wouldn't know html/css and pure js
to an acceptable level. You don't have to be a Node.JS ninja on the frontend
but definitely have a good grasp of what's going on on the frontend. People
who can only do one thing will have a harder time leading teams or going to
management.

------
zachguo
I have a feeling that all developers working on product would become full-
stack developers eventually. Probably the dichtomy of backend v.s. frontend
would become product v.s. infrastructure. Product developers support business
units while infrastructure developers support product developers.

------
PretzelFisch
One take away, from the article and comments here. There is no industry
agreement as to what a junior or senior role is. Everyone seems to place
importance on a different set of skills.

------
evadne
I suspect the author really wants to quit management and roam the world on
two-week niche contracts, but is too afraid to do so? </s>

------
antibland
Is a snarky, jpeg code snippet at the beginning of an opinionated tech article
the new snarky, pop-culture gif?

------
ptah
this is nonsense

