7 ms·

Why the full stack engineer is problematic (2020)

51 points by DeathArrow 4y ago

wawjgreen 4y ago
the article seems to have been written by an immature MBA
spzb 4y ago
Pretty superficial article soliciting email sign ups to get the full whitepaper
- Joel_Mckay 4y ago
  yup, encounters with a convert-narcissist is emotionally taxing, and dangerous for anyone in proximity. At least you can spot the issue... many can't. =)
jokethrowaway 4y ago
A full stack engineer who knows all the latest BS releases of everything is rare. Especially in a company with a stack from a few years back. It's also unneeded. Frontend and backend development are not deep enough that you can't learn the important concepts and practice both. I know plenty of people who do just that and are good at adapting to whatever new framework or library we're using today. If you need to work overtime in the night, it's not because of cognitive load, it's because your job or your mental health sucks.
- zmxz 4y ago
  > I know plenty of people who do just that and are good at adapting to whatever new framework or library we're using today. And that's the secret sauce, the core of the full stack dev - or what I would consider - your basic programmer. Basic meaning someone who understands that the real deal is figuring out the problem and that languages and frameworks are tools, not basic as someone unintelligent or incapable. The quality to adapt to a tool means that one knows what the problem is and that's the quality of someone who's adept at solving problems. Such people are scarce, that's the sad truth. Many other devs go down the hard route - memorize everything, throw the buzz at the project, hope for the best, quit when sh*t hits the fan, lie to yourself that CV filled with many jobs in short time span means you're good and desirable.
Aeolun 4y ago
Hmm, not having full-stack engineers is also problematic. Much, much time is lost translating between disciplines. To the point that I’m kind of inclined to believe that the only way to build a decent product is with full-stack engineers.
- dx034 4y ago
  That's where I like the idea of T-shaped skill-sets they describe. A back-end developer should have enough knowledge about front-end to properly do their job, but they don't need to be a front-end developer.
- christophilus 4y ago
  Also known as “engineers”.
- weatherlite 4y ago
  Especially new startups. Trying to divide to backend/frontend/devops when you are a 5 people team is gonna handicap productivity. I'd even say full stack is good for up to 20 devs, maybe beyond that you can start having specialists.
Joel_Mckay 4y ago
I tend to like working with anyone competent at what they do, and have achieved a foolproof method to identify convert-narcissists prior to a hiring phase. "Six Blind Men and the Elephant" poem by John Godfrey Saxe: It was six men of Indostan To learning much inclined, Who went to see the Elephant (Though all of them were blind), That each by observation Might satisfy his mind. The First approached the Elephant, And happening to fall Against his broad and sturdy side, At once began to bawl: "God bless me! but the Elephant Is very like a wall!" The Second, feeling of the tusk Cried, "Ho! what have we here, So very round and smooth and sharp? To me 'tis mighty clear This wonder of an Elephant Is very like a spear!" The Third approached the animal, And happening to take The squirming trunk within his hands, Thus boldly up he spake: "I see," quoth he, "the Elephant Is very like a snake!" The Fourth reached out an eager hand, And felt about the knee: "What most this wondrous beast is like Is mighty plain," quoth he; "'Tis clear enough the Elephant Is very like a tree!" The Fifth, who chanced to touch the ear, Said: "E'en the blindest man Can tell what this resembles most; Deny the fact who can, This marvel of an Elephant Is very like a fan!" The Sixth no sooner had begun About the beast to grope, Than, seizing on the swinging tail That fell within his scope. "I see," quoth he, "the Elephant Is very like a rope!" And so these men of Indostan Disputed loud and long, Each in his own opinion Exceeding stiff and strong, Though each was partly in the right, And all were in the wrong! Moral: So oft in theologic wars, The disputants, I ween, Rail on in utter ignorance Of what each other mean, And prate about an Elephant Not one of them has seen.
paradite 4y ago
> When asking engineers how long it takes for a new hire to get up to speed, a common response is six to twelve months. Not sure where the stats are from. In my experience it is much shorter, like a few weeks max.
- yurishimo 4y ago
  I think it highly depends on the company and product you’re working on. If you come into an agency as an IC to be rented out as a consultant, sure it’s easy to onboard because you’re essentially doing greenfield. Currently I work for a large org doing 100M+ of online revenue. I work on a team that builds tools for internal staff to manage orders. Our business is also somewhat seasonal. If someone onboards in February, its not uncommon for them to be unfamiliar with the seasonal parts of our codebase because they are only used 2 months of the year. Will they be contributing code and closing tickets in a few weeks? Yes, but they won’t be confident about the flow of the entire application and all the real world gotchas until working through at least one holiday cycle, if not two.
- Xylakant 4y ago
  That really depends on the complexity of the app/environment in question and on the definition of “up to speed”. If you consider it sufficient that the hire can contribute code changes, then a few weeks is probably enough. If having a good model of a moderately complex environment is the goal, a few month doesn’t sound off.
- Joel_Mckay 4y ago
  Depends, but in general: "Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure" ( Melvin E. Conway, https://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conway%27s_law)
- BlargMcLarg 4y ago
  It's a bad saying either way. It's too context-sensitive and riddled with semantics to draw anything of use from. Sibling comments already showcase this. Not only that, it doesn't take into account you don't jump from 0 to 100 in a single go. It's more of a curve where you'll be decently productive early in the journey, and spend most of your time getting the remaining 20-10 figured out. And with most companies generating pretty decent profits, I'd wager being halfway your full productivity is already close to a net profit for most established companies, which negates the entire "the company runs at a loss for several months!" spiel. That's not to mention that saying makes it very easy for companies to deflect responsibilities onto ICs, as if expecting everyone to know everything is "just how it should be".
ZiiS 4y ago
The name is problematic. My mind jumps strait to trying to remember enough chemistry to produce the plastic suitable for molding into keycaps. Or is 'full' rather selectively applied to exclude the hardware, firmware, client os, networking, middle-boxes, hypervisor, guest kernel, most of the guest OS, compiler, most third-party libraries.
twirlock 4y ago
MadSudaca 4y ago
Why do we keep referring to engineers as full stack, frontend, or backend? I guess this is a relic from times when the predominant software architecture was tier-based. Does this distinction still apply? Why?
- lmarcos 4y ago
  Because it's easier for companies to hire and fire based on roles.
- soco 4y ago
  In my mind (aka experience) the job ad goes like this. Frontend? You must know JavaScript plus Angular/react/whatever. Fullstack? Again Javascript but also node.js, maybe some devops. Backend? Java or Rust or such plus definitely devops. So instead of listing technologies and be clear, they'd rather use fancy-schmancy made-up names.
zmxz 4y ago
It's not the full stack engineer that's problematic. How to successfully utilize human beings that have varying degree of skills and ethics is what the problem is. The one with high-level of such skills is an asset, not the problem. It's possible to be *good* in many areas if you know what you need to achieve and how certain aspects of technology work. Getting around idiosyncrasies of various frameworks is the easy part if you're aware of what you have and where you need to be with the task at hand. Memorizing these is unrealistic. Creating mnenmonics and similar techniques that serve as shortcuts is what sets experienced worker (in any area) apart from the one that tries to memorize all the buzzwords that frameworks use.
- zasdffaa 4y ago
  > It's not the full stack engineer that's problematic. It is the problem. They ask for everything. No human can be that except perhaps some incomplete human who has traded their humanity for tech, learning and never going out (I briefly worked with a couple of these, I don't envy them). It's like asking for a full-stack "vehicle" - car, ship, lorry, tractor, rocket all in one, it's not happening. Idiots.
  - christophilus 4y ago
    What? Being a full stack engineer just means you need to know how to write JavaScript and SQL and not store plaintext passwords. I’m being a bit facetious, but it’s really not some incredibly high bar. Anyway, if you enjoy programming, then it’s an even lower bar. If you don’t enjoy programming, yeah; not much is going to help. I’ve never met a happy, successful programmer who didn’t enjoy the craft. Those who don’t love it end up burnt out, leaving for a different career, moving into management, or working for Oracle (zing!).
    - zasdffaa 4y ago
      We need to define what the term means then. Because any plonker can write js and sql after a few weeks playing around and make a mess of all of it. What is the point of having a low bar when you're employing somebody? "C# (.NET 6), React (Typescript / Next.js), PostgreSQL, Kubernetes, Kafka, OpenTelemetry (and more)" - from https://news.ycombinator.com/item?id=31679768 https://news.ycombinator.com/item?id=31679768 Done properly, meaning to bring real value, you need to know SQL pretty well. Ditto C# (ditto, no doubt, web dev). Kafka is nontrivial software. It's not something a mortal can pick up in a few months.
giantg2 4y ago
I have no problem being full stack, as long as I have a stronger specialty within it. My current team expects us to be full stack supporting multiple stacks. They constantly wonder why things go so slowly (especially with me, based on my review). Um, hello, do any of my managers remember your business classes? Specialization of labor leads to gains in efficiency...
krageon 4y ago
> Full-stack engineers need to know a lot of things > Being competent at a thing takes a long time > You cannot study many things at once > Being a full-stack engineer will therefore take years > Burnout is something that results from poor planning, poor expectations and poor positive feedback > If you try to do something you can't, you may be burned out They then go from there to concluding that this means that it is somehow likely you will develop burnout from trying to become a full-stack engineer. This is incredibly infantilising and damaging - people can be taught to learn constructively over a long time. They can learn how to do a great many things and they can store a lot of information. If studying leads to burnout because it's not done within a year, that is a mental model that assumes everyone is functionally dysfunctional mentally. We call this a disorder. Patently ridiculous as a conclusion, IMO.
- jamal-kumar 4y ago
  almost like things are challenging or something the newsletter signup thing for an email subscription really made me laugh, it's like this is what you make your money on while acting like people who rise to the challenge are victims?
- apolymath 4y ago
- BlargMcLarg 4y ago
  You're working with a different scenario than the one sketched above, though the article is drawing a premature conclusion. The scenario implies that, since you're learning multiple skills at once, it takes a long time to reach satisfactory results with any of them. Humans aren't invulnerable to poor feedback, especially adults, so they have a tendency to give up early in learning an individual skill if it takes too long for satisfactory results. Since you're actively judged on your results, feedback is inevitable, and poor feedback is probable. The scenario itself is shaky on a few things: Giving poor feedback isn't a given, some places are instead overly happy to see any form of progress (mostly verbally, though). I'd even say giving poor feedback to beginners is a sign of unprofessionalism (but this doesn't help anyone who experiences this). A combination of skills may provide a different type of satisfactory result. A highly performant solution requires a far higher understanding of programming. A clean, useful webapp can be made with various skills at "meh-okay" levels. I don't agree with the scenario either drawing the conclusion that it's the "full-stack" part and not the "too many expectations in too short of a time" part, which applies to any field. You'd generate the same burnout if you'd expect translators to do multiple languages baseline, rather than just X->Y and Y->X.
morelandjs 4y ago
I never viewed full stack as knowing all the technologies. Rather, I view it as the ability to solve the problem end-to-end. Often, knowing a few generalizable recipes is sufficient to be effective in this regard.
- drakonka 4y ago
  That's how I view it as well. There are some parts of the stack where I am more proficient than others, but I know I'm able to onboard pretty quickly to start solving problems regardless of whether it's frontend, backend, infra, whatever. I guess when I think of full stack, in practice I think of someone whom the linked article describes as T-Shaped: probably especially proficient in one thing, but able to rotate and be useful wherever needed.
- bjconlan 4y ago
  I completely agree. I don't expect everyone on the team to be like this but having seniors that are is very important. This subdivision of tasks does result in an "over the fence problem" and people need to work both sides (all sides might be a bit much but having people work at least partially beyond their title is something which is overlooked)
ryanbrunner 4y ago
Making full stack engineers successful necessitates simplifying the "stack" they need to work with IMO. If you have Kubernetes, a complex SPA frameowrk on the front end, and a maze of microservices on the backend, it's unrealistic to expect any one developer to have mastery over all that. However, if you use a fairly abstracted PaaS, limit use of Javascript and primarily deliver HTML from the server, and keep things in one well-organized backend service, it's perfectly reasonable for a single engineer to contribute at all levels of that stack. I think one problem with a lot of modern tools is they haven't made programmer effectiveness and ease of use a primary motivation. People look for the best tool for the job (which is often overkill for the scale / complexity that they need to solve for), when often they're better off choosing the simplest tool for the job (which might not work forever, but works well now).
- magic_hamster 4y ago
  The "right" solution vs "right now" is a lifelong dilemma for developers. If you don't expect your project will have a long shelf life, it might be easier to accept parts in the stack that aren't going to scale. But if your project has prospects for the future, putting in the time to create a solid foundation will pay dividends when the moment comes to scale up. For some annoying reason though, we can't really predict the future and a lot of small, never-meant-for-greatness projects due pick up momentum and need to grow. Then you're in a world of pain. Hope for the best, prepare for the worst, I guess.
  - dec0dedab0de 4y ago
    If you don't expect your project will have a long shelf life, it might be easier to accept parts in the stack that aren't going to scale. But if your project has prospects for the future, putting in the time to create a solid foundation will pay dividends when the moment comes to scale up. I have services that were supposed to last 3 months that are still running 6 years later, with a firedrill every 6-18 months when requirements change without warning. I've also spent months working on things that were meant to last years, that never made it to production because the product owner changed their mind. My general rule is to assume everything will last forever, and organize my code with maintainability and changes in mind. But also to deploy the simplest way possible and scale only when needed.
benjaminwootton 4y ago
I’m not sure. I’ve seen enough people in the wild who can write their own code and know enough about deployment, ops, infrastructure etc to get their code deployed. Such a profile certainly exists even though of course you can’t be an expert in everything. I also think the full stack engineer is a better target to aim for than siloeing in any way. Telling a developer they can’t do tests or deployments feels like a step back to the bad old days. So if such a creature exists and it’s a desirable thing to aim for, I’m not sure why we would try to put the breaks on full stack development.
GiorgioG 4y ago
'Full Stack Engineer' is a problem because it assumes that you're an end-to-end expert and that you're equally happy working on backend or frontend applications. I've spent 80% of my career working on backend systems and 20% on the frontend. I consider myself to be a rare bird in that while I'm most comfortable with backend systems development, I do actually enjoy delving into frontend work. That doesn't mean I'm going to do things the same way or as well as a dedicated frontend software engineer. I'll get the job done though. Most of the folks I know are "allergic" to either frontend or backend work. Can they do it? If forced to, yes they can. But they won't be happy doing it and they may not do it well or it may take them a long time to do the work. In all of the teams where full-stack has been attempted to be forced on us, we always wound up naturally reverting to our preferred tier once the manager found another idea to be distracted by.
christophilus 4y ago
The Primagen's new video popped up in my feed this morning, and it's on this topic[0]. I generally agree with him, and agree with him here. Basically: take the time to explore / learn new things when looking at jobs you think you want. You don't need to be an expert in everything on a company's "must have" list. In my experience, you don't even need to know most of the things in a company's "must have" list. Those lists are BS. You just need to be able to solve problems, think like an engineer, and be willing to pick up new skills along the way. If a company really is a stickler about their "must have" list, guess what? That's good. It's one of the best indications that the company is run by a-holes, and you should avoid them. They're doing you a favor by providing that nice big red flag up front. [0] https://www.youtube.com/watch?v=nmhX3_m84Is https://www.youtube.com/watch?v=nmhX3_m84Is
keyraycheck 4y ago
I generally agree with the article, however it reminds me of what my algorithmic competition mentor once said: “So you know who java developer is? Someone who doesn’t know Java”. While the emphasis was not on Java, but knowing a single language. “If he could learn Java well he could very much learn C++”. Again emphasise is not on C++ specifically, but any other language really. Technology landscape changes, stack get more complex. While we should not expect everyone to know everything all the time, we should expect most developers strive for fullstackness. A ideal perhaps never to be achieved .
- Viliam1234 4y ago
  If you know Java, you can learn C++ quickly. But your knowledge of Java frameworks or Maven configuration will be quite useless for your new C++ project.
recursivedoubts 4y ago
The article seems to consider "full stack" as everything-including-devops. My definition, and the one I feel captures the meaning that I most often see is both-front-end-and-back-end, ie someone who can build a complete application feature. I would expect familiarity with DevOps and cloud componenets, but not mastery, of a full stack engineer. Given this latter definition, which, again, I think is more in line with the usage of the term in general, there is a way to reduce the cognitive load required to do full stack engineering, and that is to cut weight, particularly on the front end. I have an axe to grind here, as the author, but one way to do that is to use a technology like https://htmx.org https://htmx.org, which extends HTML, making it more expressive, and allowing 1990s/early-aughts style full stack development without a heavyweight client side model. It isn't going to allow you to do everything a heavy weight SPA framework would, but most applications don't need that, and almost no applications need that everywhere. The big advantage of full stack development is that a single engineer can conceive, implement and optimize an entire feature without bumping into inter-human dependencies. This can lead to a cleaner, simpler and ultimately more maintainable code base. We should be asking how to recapture this extremely productive mode of technical work, rather than dismissing it as "too hard". It wasn't too hard a couple of decades ago, it doesn't have to be too hard now.
Pmop 4y ago
I think being full stack is doable to some extent, I often find that it's easier to design a good solution that you can deliver in a timely manner if you know more of the stack. You'll face less "glue code" and "domain change" issues, so you ship stuff faster. I think the challenge is being full stack, understanding deeply each layer of the stack, and being comfortable with the fact that you'll be paid the same compensation regardless of if you're doing 2~4 persons jobs.
cersa8 4y ago
As a solo dev/founder I had little choice but be a full stack engineer. As long as you don't go overboard with the complexity and enjoy learning, it is very feasible to master the entire stack sufficiently. For me keeping things simple is having a single repo, everything in TypeScript and using popular libraries and frameworks. No kubernetes but a single beefy server with a hot spare. I think being responsible for the entire stack is what makes it so interesting.
denton-scratch 4y ago
I'm basically a sysadmin, who took work doing web development to make a living. The web-work involved backend and frontend, like most web-work. In addition, I set up VMs, and scripts to set up VMs, and build-pipelines, and a code repository, and repository hooks to trigger builds. I never really enjoyed web-work. In the beginning, it was mainly about browser incompatibilities; then libraries like JQuery came along, rendering Javascript essentially a new language. Then the young whippersnappers on the team started dragging in things like Moustache, RoR, microservices and so on - about one new technology each month. I have reckoned that it takes me about 6 months to get good at a new language or programming paradigm. So I have no chance to become expert at everything the whippersnappers want to be using (and I reckon they don't either). I wasn't team leader or anything; I wish the bosses had stomped on the "newsness is best" thing more firmly. As it is, although my work covered the stack from top to bottom, I wasn't "full stack" because I didn't know a lot of the stuff my colleagues were using.
immigrantheart 4y ago
If you keep monolith and don’t chase new tech all the time you can still be fullstack.
cudgy 4y ago
Full stack is a generalist. They may have expertise on one area, but are functional in most areas. Also, full stack developers are typically found in simpler web-based applications that are CRUD oriented thereby allowing one developer to provide solutions across the different application tiers. Frameworks like RoR are what likely began this trend of “full stack”, but the environment is more fragmented now. Any developers that claim to be experts in all of those tiers are likely delusional.
windows2020 4y ago
A real full stack engineer doesn't subscribe to leaky and overcomplicated fanboy abstractions, but on the elegance of simplicity, and in doing so weaves the front and back ends together with consistency and grace.
- draw_down 4y ago
nomorecodehere8 4y ago
I was full stack 20 years ago and didn't even notice it. It was called being a senior sysadmin. Now if you were to ask me to code review someones js, come up with an EOL migration strategy for kubernetes clusters, optimize a solution using openmp and write up infra in terraform I would call it a normal couple of days. Not much has changed - except I bitch more and take a longer time to do things.

51 points by DeathArrow 4y ago

wawjgreen 4y ago

the article seems to have been written by an immature MBA

spzb 4y ago

Pretty superficial article soliciting email sign ups to get the full whitepaper

Joel_Mckay 4y ago
yup, encounters with a convert-narcissist is emotionally taxing, and dangerous for anyone in proximity. At least you can spot the issue... many can't. =)

jokethrowaway 4y ago

A full stack engineer who knows all the latest BS releases of everything is rare. Especially in a company with a stack from a few years back. It's also unneeded. Frontend and backend development are not deep enough that you can't learn the important concepts and practice both. I know plenty of people who do just that and are good at adapting to whatever new framework or library we're using today. If you need to work overtime in the night, it's not because of cognitive load, it's because your job or your mental health sucks.

zmxz 4y ago
> I know plenty of people who do just that and are good at adapting to whatever new framework or library we're using today. And that's the secret sauce, the core of the full stack dev - or what I would consider - your basic programmer. Basic meaning someone who understands that the real deal is figuring out the problem and that languages and frameworks are tools, not basic as someone unintelligent or incapable. The quality to adapt to a tool means that one knows what the problem is and that's the quality of someone who's adept at solving problems. Such people are scarce, that's the sad truth. Many other devs go down the hard route - memorize everything, throw the buzz at the project, hope for the best, quit when sh*t hits the fan, lie to yourself that CV filled with many jobs in short time span means you're good and desirable.

Aeolun 4y ago

Hmm, not having full-stack engineers is also problematic. Much, much time is lost translating between disciplines. To the point that I’m kind of inclined to believe that the only way to build a decent product is with full-stack engineers.

dx034 4y ago
That's where I like the idea of T-shaped skill-sets they describe. A back-end developer should have enough knowledge about front-end to properly do their job, but they don't need to be a front-end developer.
christophilus 4y ago
Also known as “engineers”.
weatherlite 4y ago
Especially new startups. Trying to divide to backend/frontend/devops when you are a 5 people team is gonna handicap productivity. I'd even say full stack is good for up to 20 devs, maybe beyond that you can start having specialists.

Joel_Mckay 4y ago

I tend to like working with anyone competent at what they do, and have achieved a foolproof method to identify convert-narcissists prior to a hiring phase. "Six Blind Men and the Elephant" poem by John Godfrey Saxe: It was six men of Indostan To learning much inclined, Who went to see the Elephant (Though all of them were blind), That each by observation Might satisfy his mind. The First approached the Elephant, And happening to fall Against his broad and sturdy side, At once began to bawl: "God bless me! but the Elephant Is very like a wall!" The Second, feeling of the tusk Cried, "Ho! what have we here, So very round and smooth and sharp? To me 'tis mighty clear This wonder of an Elephant Is very like a spear!" The Third approached the animal, And happening to take The squirming trunk within his hands, Thus boldly up he spake: "I see," quoth he, "the Elephant Is very like a snake!" The Fourth reached out an eager hand, And felt about the knee: "What most this wondrous beast is like Is mighty plain," quoth he; "'Tis clear enough the Elephant Is very like a tree!" The Fifth, who chanced to touch the ear, Said: "E'en the blindest man Can tell what this resembles most; Deny the fact who can, This marvel of an Elephant Is very like a fan!" The Sixth no sooner had begun About the beast to grope, Than, seizing on the swinging tail That fell within his scope. "I see," quoth he, "the Elephant Is very like a rope!" And so these men of Indostan Disputed loud and long, Each in his own opinion Exceeding stiff and strong, Though each was partly in the right, And all were in the wrong! Moral: So oft in theologic wars, The disputants, I ween, Rail on in utter ignorance Of what each other mean, And prate about an Elephant Not one of them has seen.

paradite 4y ago

> When asking engineers how long it takes for a new hire to get up to speed, a common response is six to twelve months. Not sure where the stats are from. In my experience it is much shorter, like a few weeks max.

yurishimo 4y ago
I think it highly depends on the company and product you’re working on. If you come into an agency as an IC to be rented out as a consultant, sure it’s easy to onboard because you’re essentially doing greenfield. Currently I work for a large org doing 100M+ of online revenue. I work on a team that builds tools for internal staff to manage orders. Our business is also somewhat seasonal. If someone onboards in February, its not uncommon for them to be unfamiliar with the seasonal parts of our codebase because they are only used 2 months of the year. Will they be contributing code and closing tickets in a few weeks? Yes, but they won’t be confident about the flow of the entire application and all the real world gotchas until working through at least one holiday cycle, if not two.
Xylakant 4y ago
That really depends on the complexity of the app/environment in question and on the definition of “up to speed”. If you consider it sufficient that the hire can contribute code changes, then a few weeks is probably enough. If having a good model of a moderately complex environment is the goal, a few month doesn’t sound off.
Joel_Mckay 4y ago
Depends, but in general: "Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure" ( Melvin E. Conway, https://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conway%27s_law)
BlargMcLarg 4y ago
It's a bad saying either way. It's too context-sensitive and riddled with semantics to draw anything of use from. Sibling comments already showcase this. Not only that, it doesn't take into account you don't jump from 0 to 100 in a single go. It's more of a curve where you'll be decently productive early in the journey, and spend most of your time getting the remaining 20-10 figured out. And with most companies generating pretty decent profits, I'd wager being halfway your full productivity is already close to a net profit for most established companies, which negates the entire "the company runs at a loss for several months!" spiel. That's not to mention that saying makes it very easy for companies to deflect responsibilities onto ICs, as if expecting everyone to know everything is "just how it should be".

ZiiS 4y ago

The name is problematic. My mind jumps strait to trying to remember enough chemistry to produce the plastic suitable for molding into keycaps. Or is 'full' rather selectively applied to exclude the hardware, firmware, client os, networking, middle-boxes, hypervisor, guest kernel, most of the guest OS, compiler, most third-party libraries.

twirlock 4y ago

MadSudaca 4y ago

Why do we keep referring to engineers as full stack, frontend, or backend? I guess this is a relic from times when the predominant software architecture was tier-based. Does this distinction still apply? Why?

lmarcos 4y ago
Because it's easier for companies to hire and fire based on roles.
soco 4y ago
In my mind (aka experience) the job ad goes like this. Frontend? You must know JavaScript plus Angular/react/whatever. Fullstack? Again Javascript but also node.js, maybe some devops. Backend? Java or Rust or such plus definitely devops. So instead of listing technologies and be clear, they'd rather use fancy-schmancy made-up names.

zmxz 4y ago

It's not the full stack engineer that's problematic. How to successfully utilize human beings that have varying degree of skills and ethics is what the problem is. The one with high-level of such skills is an asset, not the problem. It's possible to be *good* in many areas if you know what you need to achieve and how certain aspects of technology work. Getting around idiosyncrasies of various frameworks is the easy part if you're aware of what you have and where you need to be with the task at hand. Memorizing these is unrealistic. Creating mnenmonics and similar techniques that serve as shortcuts is what sets experienced worker (in any area) apart from the one that tries to memorize all the buzzwords that frameworks use.

zasdffaa 4y ago
> It's not the full stack engineer that's problematic. It is the problem. They ask for everything. No human can be that except perhaps some incomplete human who has traded their humanity for tech, learning and never going out (I briefly worked with a couple of these, I don't envy them). It's like asking for a full-stack "vehicle" - car, ship, lorry, tractor, rocket all in one, it's not happening. Idiots.
- christophilus 4y ago
  What? Being a full stack engineer just means you need to know how to write JavaScript and SQL and not store plaintext passwords. I’m being a bit facetious, but it’s really not some incredibly high bar. Anyway, if you enjoy programming, then it’s an even lower bar. If you don’t enjoy programming, yeah; not much is going to help. I’ve never met a happy, successful programmer who didn’t enjoy the craft. Those who don’t love it end up burnt out, leaving for a different career, moving into management, or working for Oracle (zing!).
  - zasdffaa 4y ago
    We need to define what the term means then. Because any plonker can write js and sql after a few weeks playing around and make a mess of all of it. What is the point of having a low bar when you're employing somebody? "C# (.NET 6), React (Typescript / Next.js), PostgreSQL, Kubernetes, Kafka, OpenTelemetry (and more)" - from https://news.ycombinator.com/item?id=31679768 https://news.ycombinator.com/item?id=31679768 Done properly, meaning to bring real value, you need to know SQL pretty well. Ditto C# (ditto, no doubt, web dev). Kafka is nontrivial software. It's not something a mortal can pick up in a few months.

giantg2 4y ago

I have no problem being full stack, as long as I have a stronger specialty within it. My current team expects us to be full stack supporting multiple stacks. They constantly wonder why things go so slowly (especially with me, based on my review). Um, hello, do any of my managers remember your business classes? Specialization of labor leads to gains in efficiency...

krageon 4y ago

> Full-stack engineers need to know a lot of things > Being competent at a thing takes a long time > You cannot study many things at once > Being a full-stack engineer will therefore take years > Burnout is something that results from poor planning, poor expectations and poor positive feedback > If you try to do something you can't, you may be burned out They then go from there to concluding that this means that it is somehow likely you will develop burnout from trying to become a full-stack engineer. This is incredibly infantilising and damaging - people can be taught to learn constructively over a long time. They can learn how to do a great many things and they can store a lot of information. If studying leads to burnout because it's not done within a year, that is a mental model that assumes everyone is functionally dysfunctional mentally. We call this a disorder. Patently ridiculous as a conclusion, IMO.

jamal-kumar 4y ago
almost like things are challenging or something the newsletter signup thing for an email subscription really made me laugh, it's like this is what you make your money on while acting like people who rise to the challenge are victims?
apolymath 4y ago
BlargMcLarg 4y ago
You're working with a different scenario than the one sketched above, though the article is drawing a premature conclusion. The scenario implies that, since you're learning multiple skills at once, it takes a long time to reach satisfactory results with any of them. Humans aren't invulnerable to poor feedback, especially adults, so they have a tendency to give up early in learning an individual skill if it takes too long for satisfactory results. Since you're actively judged on your results, feedback is inevitable, and poor feedback is probable. The scenario itself is shaky on a few things: Giving poor feedback isn't a given, some places are instead overly happy to see any form of progress (mostly verbally, though). I'd even say giving poor feedback to beginners is a sign of unprofessionalism (but this doesn't help anyone who experiences this). A combination of skills may provide a different type of satisfactory result. A highly performant solution requires a far higher understanding of programming. A clean, useful webapp can be made with various skills at "meh-okay" levels. I don't agree with the scenario either drawing the conclusion that it's the "full-stack" part and not the "too many expectations in too short of a time" part, which applies to any field. You'd generate the same burnout if you'd expect translators to do multiple languages baseline, rather than just X->Y and Y->X.

morelandjs 4y ago

I never viewed full stack as knowing all the technologies. Rather, I view it as the ability to solve the problem end-to-end. Often, knowing a few generalizable recipes is sufficient to be effective in this regard.

drakonka 4y ago
That's how I view it as well. There are some parts of the stack where I am more proficient than others, but I know I'm able to onboard pretty quickly to start solving problems regardless of whether it's frontend, backend, infra, whatever. I guess when I think of full stack, in practice I think of someone whom the linked article describes as T-Shaped: probably especially proficient in one thing, but able to rotate and be useful wherever needed.
bjconlan 4y ago
I completely agree. I don't expect everyone on the team to be like this but having seniors that are is very important. This subdivision of tasks does result in an "over the fence problem" and people need to work both sides (all sides might be a bit much but having people work at least partially beyond their title is something which is overlooked)

ryanbrunner 4y ago

Making full stack engineers successful necessitates simplifying the "stack" they need to work with IMO. If you have Kubernetes, a complex SPA frameowrk on the front end, and a maze of microservices on the backend, it's unrealistic to expect any one developer to have mastery over all that. However, if you use a fairly abstracted PaaS, limit use of Javascript and primarily deliver HTML from the server, and keep things in one well-organized backend service, it's perfectly reasonable for a single engineer to contribute at all levels of that stack. I think one problem with a lot of modern tools is they haven't made programmer effectiveness and ease of use a primary motivation. People look for the best tool for the job (which is often overkill for the scale / complexity that they need to solve for), when often they're better off choosing the simplest tool for the job (which might not work forever, but works well now).

magic_hamster 4y ago
The "right" solution vs "right now" is a lifelong dilemma for developers. If you don't expect your project will have a long shelf life, it might be easier to accept parts in the stack that aren't going to scale. But if your project has prospects for the future, putting in the time to create a solid foundation will pay dividends when the moment comes to scale up. For some annoying reason though, we can't really predict the future and a lot of small, never-meant-for-greatness projects due pick up momentum and need to grow. Then you're in a world of pain. Hope for the best, prepare for the worst, I guess.
- dec0dedab0de 4y ago
  If you don't expect your project will have a long shelf life, it might be easier to accept parts in the stack that aren't going to scale. But if your project has prospects for the future, putting in the time to create a solid foundation will pay dividends when the moment comes to scale up. I have services that were supposed to last 3 months that are still running 6 years later, with a firedrill every 6-18 months when requirements change without warning. I've also spent months working on things that were meant to last years, that never made it to production because the product owner changed their mind. My general rule is to assume everything will last forever, and organize my code with maintainability and changes in mind. But also to deploy the simplest way possible and scale only when needed.

benjaminwootton 4y ago

I’m not sure. I’ve seen enough people in the wild who can write their own code and know enough about deployment, ops, infrastructure etc to get their code deployed. Such a profile certainly exists even though of course you can’t be an expert in everything. I also think the full stack engineer is a better target to aim for than siloeing in any way. Telling a developer they can’t do tests or deployments feels like a step back to the bad old days. So if such a creature exists and it’s a desirable thing to aim for, I’m not sure why we would try to put the breaks on full stack development.

GiorgioG 4y ago

'Full Stack Engineer' is a problem because it assumes that you're an end-to-end expert and that you're equally happy working on backend or frontend applications. I've spent 80% of my career working on backend systems and 20% on the frontend. I consider myself to be a rare bird in that while I'm most comfortable with backend systems development, I do actually enjoy delving into frontend work. That doesn't mean I'm going to do things the same way or as well as a dedicated frontend software engineer. I'll get the job done though. Most of the folks I know are "allergic" to either frontend or backend work. Can they do it? If forced to, yes they can. But they won't be happy doing it and they may not do it well or it may take them a long time to do the work. In all of the teams where full-stack has been attempted to be forced on us, we always wound up naturally reverting to our preferred tier once the manager found another idea to be distracted by.

christophilus 4y ago

The Primagen's new video popped up in my feed this morning, and it's on this topic[0]. I generally agree with him, and agree with him here. Basically: take the time to explore / learn new things when looking at jobs you think you want. You don't need to be an expert in everything on a company's "must have" list. In my experience, you don't even need to know most of the things in a company's "must have" list. Those lists are BS. You just need to be able to solve problems, think like an engineer, and be willing to pick up new skills along the way. If a company really is a stickler about their "must have" list, guess what? That's good. It's one of the best indications that the company is run by a-holes, and you should avoid them. They're doing you a favor by providing that nice big red flag up front. [0] https://www.youtube.com/watch?v=nmhX3_m84Is https://www.youtube.com/watch?v=nmhX3_m84Is

keyraycheck 4y ago

I generally agree with the article, however it reminds me of what my algorithmic competition mentor once said: “So you know who java developer is? Someone who doesn’t know Java”. While the emphasis was not on Java, but knowing a single language. “If he could learn Java well he could very much learn C++”. Again emphasise is not on C++ specifically, but any other language really. Technology landscape changes, stack get more complex. While we should not expect everyone to know everything all the time, we should expect most developers strive for fullstackness. A ideal perhaps never to be achieved .

Viliam1234 4y ago
If you know Java, you can learn C++ quickly. But your knowledge of Java frameworks or Maven configuration will be quite useless for your new C++ project.

recursivedoubts 4y ago

The article seems to consider "full stack" as everything-including-devops. My definition, and the one I feel captures the meaning that I most often see is both-front-end-and-back-end, ie someone who can build a complete application feature. I would expect familiarity with DevOps and cloud componenets, but not mastery, of a full stack engineer. Given this latter definition, which, again, I think is more in line with the usage of the term in general, there is a way to reduce the cognitive load required to do full stack engineering, and that is to cut weight, particularly on the front end. I have an axe to grind here, as the author, but one way to do that is to use a technology like https://htmx.org https://htmx.org, which extends HTML, making it more expressive, and allowing 1990s/early-aughts style full stack development without a heavyweight client side model. It isn't going to allow you to do everything a heavy weight SPA framework would, but most applications don't need that, and almost no applications need that everywhere. The big advantage of full stack development is that a single engineer can conceive, implement and optimize an entire feature without bumping into inter-human dependencies. This can lead to a cleaner, simpler and ultimately more maintainable code base. We should be asking how to recapture this extremely productive mode of technical work, rather than dismissing it as "too hard". It wasn't too hard a couple of decades ago, it doesn't have to be too hard now.

Pmop 4y ago

I think being full stack is doable to some extent, I often find that it's easier to design a good solution that you can deliver in a timely manner if you know more of the stack. You'll face less "glue code" and "domain change" issues, so you ship stuff faster. I think the challenge is being full stack, understanding deeply each layer of the stack, and being comfortable with the fact that you'll be paid the same compensation regardless of if you're doing 2~4 persons jobs.

cersa8 4y ago

As a solo dev/founder I had little choice but be a full stack engineer. As long as you don't go overboard with the complexity and enjoy learning, it is very feasible to master the entire stack sufficiently. For me keeping things simple is having a single repo, everything in TypeScript and using popular libraries and frameworks. No kubernetes but a single beefy server with a hot spare. I think being responsible for the entire stack is what makes it so interesting.

denton-scratch 4y ago

I'm basically a sysadmin, who took work doing web development to make a living. The web-work involved backend and frontend, like most web-work. In addition, I set up VMs, and scripts to set up VMs, and build-pipelines, and a code repository, and repository hooks to trigger builds. I never really enjoyed web-work. In the beginning, it was mainly about browser incompatibilities; then libraries like JQuery came along, rendering Javascript essentially a new language. Then the young whippersnappers on the team started dragging in things like Moustache, RoR, microservices and so on - about one new technology each month. I have reckoned that it takes me about 6 months to get good at a new language or programming paradigm. So I have no chance to become expert at everything the whippersnappers want to be using (and I reckon they don't either). I wasn't team leader or anything; I wish the bosses had stomped on the "newsness is best" thing more firmly. As it is, although my work covered the stack from top to bottom, I wasn't "full stack" because I didn't know a lot of the stuff my colleagues were using.

immigrantheart 4y ago

If you keep monolith and don’t chase new tech all the time you can still be fullstack.

cudgy 4y ago

Full stack is a generalist. They may have expertise on one area, but are functional in most areas. Also, full stack developers are typically found in simpler web-based applications that are CRUD oriented thereby allowing one developer to provide solutions across the different application tiers. Frameworks like RoR are what likely began this trend of “full stack”, but the environment is more fragmented now. Any developers that claim to be experts in all of those tiers are likely delusional.

windows2020 4y ago

A real full stack engineer doesn't subscribe to leaky and overcomplicated fanboy abstractions, but on the elegance of simplicity, and in doing so weaves the front and back ends together with consistency and grace.

draw_down 4y ago

nomorecodehere8 4y ago

I was full stack 20 years ago and didn't even notice it. It was called being a senior sysadmin. Now if you were to ask me to code review someones js, come up with an EOL migration strategy for kubernetes clusters, optimize a solution using openmp and write up infra in terraform I would call it a normal couple of days. Not much has changed - except I bitch more and take a longer time to do things.