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.
> 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.
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.
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.
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.
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.
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.
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.
"Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure"
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".
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.
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?
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.
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.
> 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.
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!).
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.
I've never once used Kubernetes or Kafka or OpenTelemetry, but I've been "full stack" since before those technologies existed.
There are plenty of full-stack Node shops. You only need JS as a language (or preferably TS, these days). And many, many companies can get away with just Postgres as their data store, with maybe a caching layer like Redis or Memcache or even an in-process cache. Heroku, Render, Fly, etc can solve the Kubernetes problem for a whole lot of projects for a very long time, so I don't think Kuberentes belongs on a "must know in order to be full-stack" list.
When I first started in the industry (when C# was pre-1.0), you simply hired "engineers". Your expectation for them was that over time, they'd learn the peculiarities of your entire tech stack. But immediately, they'd be able to understand most technical problems at a fundamental level, reason about it, and give a reasonable solution with a decent list of pros / cons / tradeoffs.
I've made hiring decisions for around a decade now, and that's still my expectation of an engineer. I don't expect every engineer I hire to know my stack (it's varied wildly from project to project: C#, jQuery, SQLServer, Memcache; Rails, Redis, MySQL, React; Preact, Polka, Postgres, a bunch of AWS junk; React, Hapi, ElasticSearch, etc.
You don't need to know the intricacies of the full stack when you join a team. You need to be able to understand why you might need a bit of tech, and when tackling an issue, you may need to learn a new bit of tech to better solve the problem.
It’s an unfortunate example of the strange priorities that seem to plague our industry.
I’ve also been doing this development thing for a while now, and at this point I’m fairly sure the actual order of what matters looks something like this (most important first):
1. Solid fundamentals in development and/or infrastructure as appropriate
2. Soft skills, particularly different styles of communication and organisation
3. Domain knowledge relevant to the role/product
4. Knowledge of any specific language, tool, process or technique
We could debate the order of the top two. Domain knowledge is new to almost everyone when they first start a new role, unless they happen to have worked for someone else in the same field before. The specific technologies are rarely going to be an exact match, but that doesn’t matter as long as someone has good general knowledge and the motivation to quickly learn new tech when they need to.
I can’t help feeling that a lot of problems in a lot of development groups would vanish if hiring was based on looking for good fundamentals and a professional approach rather than strict buzzword compliance, and if the day-to-day working environment then supported good people doing deep work. It’s not really surprising that some people think every new technology will take weeks to learn and capable full-stack developers are mythical creatures when you look at the environments and hiring processes they are stuck with, but it doesn’t have to be that way and of course the better developers are drawn to the places that aren’t, which continues the cycle.
> I've made hiring decisions for around a decade now, and that's still my expectation of an engineer
That sounds like the kind of reasonableness that just does not come across to me when I read so many job adverts.
When I read 'full stack' it says to me 'know this stuff', otherwise you should put "we need this and you also need to learn x, y, z, ..." as the need arises. I can do that.
Counterpoint: it is absolutely something you could know all of. In your example, I’d describe myself has highly proficient in c#, Typescript, React, Postgres, and Kafka, proficient at Kubernetes, and unfamiliar with OpenTelemetry. That’s just a list of common tools, and if the list were different, I’d be pretty confident I could learn whatever I was missing on the job. Tools are usually the easy part.
I agree you need to know all those things pretty well, but I don’t think that’s a huge ask. You can definitely pick up Kafka in a few months.
Look, maybe all that’s not your thing, which is fine, but knowing a wide range of tools and being comfortable in any part of the architecture isn’t some crazy rare skillset known only to certain cyborgs. It’s certainly not idiocy to seek those people out.
I've been doing sql for decades. You can learn sql in weeks, a few months to get good at it, longer to get good at relational data modelling (I've seen some non-normalised messes) and years to learn the database underneath to get solid scalable performance out of it - and if you don't your business may sink.
I think it fair to say if it had not been for me, 2 successful business would have died due to sql perf. problems. Edit: what this means is if you go for a shallow skill level it works at first but may cost later, and very heavily.
Good back-end langauge skills, well, I can pick up C# in a few weeks and indeed did - because I had a ton of other language experience behind me. That isn't something you get in a few months - and I mean not just the language but the whole gamut of techniques for solid programming, and you can add functional programming on top. Then you need to understand about garbage generation and big-oh costs of algorithms so you don't do twatty things with linked lists.
How about web dev? I know more about html/http/user interfaces than most web devs do and you don't have to look far to see the mess they made (I choose not to be a web dev).
Maybe I set the bar high but when I see a list of skills, I assume it means "be actually good in these" not "pickem up as you go along"
Perhaps people should be more clear about what they want.
> It’s certainly not idiocy to seek those people out.
Maybe you aren't looking for the level of skill that I assume you are. But be clear what full-stack means because others (me) may misunderstand it.
Full stack developers who have been working for decades have also been doing sql for decades, because most substantial software uses a database. Perhaps the DB server has changed (I’ve gone deep on Postgres, MsSQL, and MySQL) but the principles are largely the same and while there is plenty vendor-specific knowhow, that is just stuff to learn.
> because I had a ton of other language experience behind me
Yes, a full stack dev needs this. Why wouldn’t they have it? You seem to be conflating seniority/experience with breadth of skill.
Edit: I'll also point out that languages aren't the only thing that "rhyme" in tech. If I were already experienced with Pulsar and Rabbit, I'm not going to have much trouble with Kafka. If I know Terraform well, CloudFormation isn't going to be a complicated new tool. Etc. Having breadth of experience makes taking on seemingly complicated new things far less daunting, as you point out with your c# example. That applies across the board.
> How about web dev?
I’m not quite sure what you’re trying to say here, but web dev is pretty straightforward, and of course full stack devs have typically done a lot of it.
You are either overestimating how hard it is to learn all this stuff, or you are underestimating how close you are to being able to do it yourself.
Edit. Here is a framework for thinking about it. You have been doing SQL for decades. But how much genuinely new skills related to SQL have you learned in the last, say, 5 years? Probably not many, because learning is logarithmic like that: you learn quickly at the beginning, and then more and more slowly. So what if you had instead learned a new skill 5 years ago? You'd be quite good at it by now. And if you kept using SQL, you'd stay pretty good at that too. Rinse and repeat a couple times and you're a full stack dev. You'd notice another advantage too: the undercurrent of convergence, where you notice the same patterns emerging in disparate parts of the stack and architecture, and finding yourself reapplying the same principles in very different contexts.
with tbl as
(
select x
from ( values (10), (20), (30) )as tt(x)
)
select \*
from tbl
where x not in (10, 30)
this gets you
x
---
20
as the result
without running this (same query as above but for addition of a null):
with tbl as
(
select x
from ( values (10), (20), (30) )as tt(x)
)
select \*
from tbl
where x not in (10, 30, null)
what's the result?
This can be an expensive mistake. It threw my old company into a flurry. Rare, but it happens - do you know why?
> while there is plenty vendor-specific knowhow, that is just stuff to learn
that stuff is precisely the difference between sleeping at night and "WTF now???, it's 3am and the clients are phoning me from singapore". And then losing your company or spending 20X unnecessarily on a scaling up box. You underestimate it.
> You are either overestimating how hard it is to learn all this stuff, or you are underestimating how close you are to being able to do it yourself.
Yeah, this discussion has been a major eye opener for me. I wish it had come much earlier. Thanks.
I know how `NOT IN (null)` works just fine. Now what? Remember that full stack devs have also been writing SQL for their whole careers. It's weird that you have somehow confused "I have specifically avoided these parts of the stack" with "LOL you guys must not know SQL". Just a bizarre thing to say.
My point was if you don't know something well, you fall into expensive traps. This was one that hit our company - some sql devs don't even know sql has ternary logic and why that matters.
Another that hit our company, was not understanding isolation levels in SQL, meaning that two people who could write SQL very well didn't realise their approach to avoiding a race condition just didn't work. When I pointed that out, they had a hotfix on client sites by the end of that afternoon.
I worked on the Cassandra database, we were having problems (albeit in development, it didn't reach production). Turns out truncating in the database did not release the space. That was causing people a lot of problems in till I ran into that by chance. These were full-stack, and smart, I respected them.
You can't have what I consider thorough knowledge on all fronts, and if you don't you can pay very heavily (I can give other examples). No more than that, no LOL'ing at people.
Draw your own conclusions I guess.
Anyway, thank you for taking the time to reply and for several people here pointing out that I've got the wrong end of the stick.
Edit: the sql example was me trying to make a point, not trying to catch you out. Please don't take it that way. It came across badly.
Have you seen job ads for full-stack these days? It's far beyond "JS and SQL". If that's your idea of facetious, I'd like to see your idea of what you think is realistic.
DevOps, DBMS, HTML+CSS, JS, a back-end language, a front-end framework, both language and framework considered "non-transferable" by many for some insane reason, "cloud". That's just the beginning.
>I’ve never met a happy, successful programmer who didn’t enjoy the craft.
You're conflating "juggling the company's entire stack" with "programmer". Many of us learn programming for reasons other than fullstack webdev, but we work there because the vast majority of low-risk, well-paying jobs in software development are webdev, while doing the things we consider "fun" in our own time.
At the very least, piping generic information and writing glue code isn't my idea of "fun programming".
That is about a quarter of the stack. Anyone calling themselves “full stack” in their cover letter on such a basis is getting red-flagged for lack of self-awareness.
You read the sentence in such a way that it can fit the narrative you wrote.
> They ask for everything
I don't know who "they" refers to and what those they ask for, or what everything is.
You're not concise and are answering from subjective point of view rather than from logical.
This forum has plenty of engineers that can be considered full stack. You having worked with a few humans who, in an era of their life, decided to pursue something you didn't - means nothing.
> It's like asking for a full-stack "vehicle" - car, ship, lorry, tractor, rocket all in one, it's not happening. Idiots.
See, it's the opposite. What we refer to as "full stack" is, in my opinion, your basic version of a programmer. A person who solves the problem using tools and are capable of using the right tool for the problem, or find the tool that fits solving the problem.
Full-stack would be the vehicle in your story. Not a specialized one. A vehicle. A complete system that can take you, the "client", from point A to B. Even your analogy is lacking.
I've no idea why you went on and typed "Idiots", it could very well be the ineptitude of handling the fact there are individuals who are capable of achieving what you deem impossible.
> You're not concise and are answering from subjective point of view rather than from logical.
It is coming clear that the definition of of 'full stack' is perhaps my tripping-over point. I think of it as meaning extensive knowledge and experience over the whole stack (and that in my terms means cache-line layout to algorithms to frameworks to sql to databases to http to web dev to web standards to to expertise in aesthetics & UI usability).
So where do you get your definition of 'full stack'? Pls show me.
> See, it's the opposite. What we refer to as "full stack" is, in my opinion, your basic version of a programmer. A person who solves the problem using tools and are capable of using the right tool for the problem, or find the tool that fits solving the problem.
That's called generalists. That's me (web stuff excepted). I'm good at that. Why not call them that?
So what does it mean to talk about 'full stack' then list a load of tech, as happens in job ads? Cos it implies to me existing knowledge of these things, not just ability to learn them (which I can).
What you're referring to as the stepping stone is the terminology.
You know very well that people in our field like big words and big terms - full stack developer, machine intelligence, leaky bucket algorithm, graph query language, functional programming, aspect oriented programming - just to name a few.
If we gave easy-to-understand names to everything, what would marketing do? :)
What you call as generalist can be interpreted as someone who can't use tools proficiently or produce high-code quality.
> So where do you get your definition of 'full stack'? Pls show me.
It's something we used in the earlier days of internet do describe someone who's capable of producing usable user interface sprinkled with some javascript that basically works and create db that accepts the data you insert via some kind of form that php/python/ruby processed.
It was basic "bragging" rights in the beginning, it meant "look, my thingy looks good and I made all of it myself, I Installed server software, hacked up CSS, HTML, wrote serverside code and inserted all of it in a DB".
Context: plot happens at news groups, circa 1999.
The name, along with people, evolved. There's no concrete definition. You can tell, since you assumed "full stack" means A and to me it means B.
One who can take a web-based project and create it from 0 too 100% = full stack, as it takes the full stack of tools relating to backend and frontend to complete.
> That's called generalists. That's me (web stuff excepted). I'm good at that. Why not call them that?
I don't know. I never liked the term full-stack and I met plenty of people who claimed the title but what they had to show for didn't fit the title they claimed.
> So what does it mean to talk about 'full stack' then list a load of tech, as happens in job ads?
No idea honestly, I never take those seriously. People are unstable and not trustworthy, all you can trust are facts and facts are hard to come by when it comes to hiring. The tests are the only way to assert anything, and it's difficult to create such a test, let alone run it. It's not nice for sure.
I understand where you're coming from now. I don't pay too much mind to terminology, I learned years ago that a simple algorithm that any newcomer will discover has 50 different names. That alone tells me we like to reinvent the wheel and brag needlessly.
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...
> 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.
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?
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.
Beeing a full-stack engineer isn’t problematic. But searching those amongst really young people may be misguided. Because yes, learning takes time.
If you want someone with profound knowledge and experience in nearly every programming language, concept and project management methodology, you should look for people in their 50s.
Those, who had time to invest 35k-40k hours into their passion and are going strong still. The real „unicorns“!
As a self-proclaimed full-stack person with some mastery in a lot of areas, the biggest hurdle I've had is actually the interview process which is very frustrating. I constantly get smug interviewers who ask questions a specialist in X, Y, or Z would know. In some cases I know the right answer, but because I have dealt with so many FE, BE, DevOps, and data technologies I have evolved to learning the art of learning, generalized good practices, the context around tech, and the architecture decisions needed to apply them, instead of the minute details of each technology. To make matters worse for my working memory, I have started learning knowledge about other industries outside of pure software. To the average interviewer, this makes me look inexperienced or untalented. If instead I am evaluated based on applied knowledge in the form of a take-home tech assessment I always pass with flying colors. It's very frustrating and is pushing the industry towards only being able to see the trees and not the forest which can't be good.
I feel you!
I worked with Hashes in Perl since the 90s, Did almost 10 years of Java used Dictionaries in the early versions of C#, switched to JS, Ruby and Clojure for a while and didn‘t remember how to correctly declare a typed Hash in Java in a programming kata - ouch!
So if you are a unicorn, you need to find a special environment i guess?
I hired in at one place, was informed afterwards that it was only because they were so desperate that they hired me despite my demographics.
Was reminded repeatedly on my sins of being a white male.
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.
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.
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)
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).
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.
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.
For sure it's definitely not a simple question where the answer is "right now" all of the time, but my overall point is that at least with modern trends in development, we way overcorrect for "right".
A couple of things that help me when considering this question:
- Is it really a question of "right" vs. "right now"? Is there a genuine compromise with choosing the simpler option? In my experience there often isn't. Using server rendered HTML vs. a SPA for some types of applications isn't going to result in a poorer UX. Using a slower language might be fine forever if raw language execution speed isn't your bottleneck (it rarely is IMO).
- Is it more expensive to do what's best for later later? I think this is especially relevant for dev ops questions. Moving to a Kubernetes setup is going to be just as expensive in the future as it is right now, so it's better to delay that cost for when you actually need it.
- How likely is it that you're going to know what is going to require a more robust solution now? Do you know what the service boundaries of your microservices are going to be? Do you know which portions of your app are going to be scaling concerns?
> 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.
Why is it unrealistic to expect a single doctor to have mastery in every medical specialty?
Why is it unrealistic to expect a school teacher to be able to teach every single subject?
Because in these fields, along with software development, there's too much breadth of material to sufficiently explore the depths of all of it. Having the breadth and depth of experience required to have mastery in every bit of minutia is a even slightly complex webapp is enormously difficult to obtain and maintain for a single person.
Someone can master a subject in 5+ years if they do it everyday. A fullstack dev with 20 years experience can master all those stated and more and I know fullstack devs (granted not many) than can maintain entire apps like this.
A lot of how to interpret this article is from the context you're viewing it in. You, personally, can be a full-stack developer with complex stacks if you're working at it. If you're someone who's building a team, requiring deep knowledge of all tiers is going to make it incredibly hard to hire in terms of both people who have all those skills, and more importantly people who want to use all those skills.
> Someone can master a subject in 5+ years if they do it everyday.
The problem is that all of these are moving targets. You don't master DevOps in 5 years and then you're done forever (same with backend and front-end development), these are constantly changing fields that require continually honing your skills.
Just chiming in this looks basically like my day-job.
I'm a fullstack dev who is often our devops/kubernetes lead. I'd say over 50% of my day is around DevOps tasks, but I'm likely to write an API or hone a frontend animation as well. I contribute on all parts of our microservice based kubernetes government application, but do skew to the devops side where the rest of my teams' experience is lighter. I can write iptables or webpack configs, I can implement OAuth or modify bezier curves for animations, and frequently do it all at my job. I have just over 10 years of professional experience but have been programming longer.
> Why is it unrealistic to expect a single doctor to have mastery in every medical specialty?
Full stack doesn't mean everything.
And actually all the doctors are doctors first, so they know everything about medicine, except they are not specialized in all the medical specialties.
Which is rarely a requirement in medicine.
Brain surgery or conjoined twins separation isn't that common, but an highly specialized surgeon is perfectly capable of curing common diseases just like a cardiologist can perform common surgery, such as appendicitis.
Full Stack means that you can get things up and running, not that you know everything of everything.
I spent a couple years at a place where everyone was expected to be a master of everything including Kubernetes, and handle customer support.
Absolutely nothing of value was accomplished. By the time a person started to get decent at Kubernetes and frontend and backend and support they would find a better job with more realistic expectations.
So we basically we were paying people to learn for a year, then they would leave.
I've been thinking in a similar direction lately. A lot of the more effective practices historically assumed that a single unit of value end-to-end was deliverable by a single engineer (with supporting QA and review, etc.)
The reason those single stack skills diverged into specialisms is because the results were better, especially beyond a certain scale. An SPA done right provides a much more responsive and rich user experience than forms and a full page reload. A DevOps engineer can create a system to deploy quickly, in a reproducible manner and safely when compared to copying a bunch of files over to some servers (and provisioning those servers manually too).
I don't think it's sustainable though, for a large set of use-cases common to everyday web and app development. Having separate front end and back end roles requires maintaining a minimum of two projects instead of one, defining and maintaining an API, managing co-ordination between different developers and understanding how to split scope boundaries between technology and people. It's lot of extra communication both for people and machines. It's more difficult on a management level as well - separate recruitment streams, different evaluation mechanisms, parallel promotion ladders, resourcing headaches, etc.
Now we have the benefit of knowing what's required to compete in the modern landscape, I think we'll start to see the return of a new set of frameworks and runtimes which give 90% of the benefits of separate FE/BE/DevOps roles whilst allowing a single engineer to focus on application development. I'm thinking of things like Elixir's Phoenix LiveView, and eventually frameworks that compile a single codebase to WASM for the browser whilst providing seamless integration with the backend.
It seems like an economic inevitability; anything that lets people ship value more quickly and efficiently has to win out in the end.
I might agree if the expectation is that someone also has a deep understanding of infrastructure, but I'm not convinced by the rest.
I know a few exceptional software folks who have a deep understanding of React and Java backends. The problem for the most part is that it has been difficult to be a full stack engineer because of the churn of FE software frameworks. Now that React has be around for a while, it is well understood by many people and having a decade of software experience means that you can be very competent and knowledgable about both the FE and BE. My expectation is that if React stays popular and is generally similar to how it works today, we will see a lot more people be able to do both FE and BE systems.
Typically a person will still be stronger at one than the other, but they can still be great at both.
Totally this. I can do javascript. I have written a LOT of javascript in my life. I worked with jQuery, I've worked with React, I have worked with knockout and this and that and this and.
Meanwhile my backend stuff hasn't changed all that much in 10 years. Yes I learn new things, but what I know about javascript and web development has largely gone out the window.
I think in my experience what has traditionally been a challenge straddling the front-end and backend sides of a full stack developer in a SPA + backend API world is not the complexities of the technologies (it's not uncommon for backend developers to have a workable understanding of React and vice versa), but the sheer amount of 1st party code to deal with when working in both areas.
I'm working on turning around a site that's been up and steady for about 5 years. there's no less than 6 different various 'helper' 'foundation' libraries, helper libraries, utility libraries, libraries that don't get used anymore. All interpolated into a mess.
This whole thing is developed by some rotating cast of developers on contracts, who have no interest in maintaining anything long term, and so its just piled up and piled up. Technical debt doesn't exist when you will leave the project for the next guy.
Anyway... we're making progress against it slowly but it's really frustrating because our website is loading so much crap and untangling it takes forever. Half of me wants to throw the whole thing out.
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.
'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.
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.
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 .
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, 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.
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.
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.
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.
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.
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.
88 comments
[ 2.5 ms ] story [ 101 ms ] threadAt least you can spot the issue... many can't. =)
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.
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.
"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.
Not sure where the stats are from. In my experience it is much shorter, like a few weeks max.
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.
"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)
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".
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.
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.
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!).
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
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.
There are plenty of full-stack Node shops. You only need JS as a language (or preferably TS, these days). And many, many companies can get away with just Postgres as their data store, with maybe a caching layer like Redis or Memcache or even an in-process cache. Heroku, Render, Fly, etc can solve the Kubernetes problem for a whole lot of projects for a very long time, so I don't think Kuberentes belongs on a "must know in order to be full-stack" list.
When I first started in the industry (when C# was pre-1.0), you simply hired "engineers". Your expectation for them was that over time, they'd learn the peculiarities of your entire tech stack. But immediately, they'd be able to understand most technical problems at a fundamental level, reason about it, and give a reasonable solution with a decent list of pros / cons / tradeoffs.
I've made hiring decisions for around a decade now, and that's still my expectation of an engineer. I don't expect every engineer I hire to know my stack (it's varied wildly from project to project: C#, jQuery, SQLServer, Memcache; Rails, Redis, MySQL, React; Preact, Polka, Postgres, a bunch of AWS junk; React, Hapi, ElasticSearch, etc.
You don't need to know the intricacies of the full stack when you join a team. You need to be able to understand why you might need a bit of tech, and when tackling an issue, you may need to learn a new bit of tech to better solve the problem.
I’ve also been doing this development thing for a while now, and at this point I’m fairly sure the actual order of what matters looks something like this (most important first):
1. Solid fundamentals in development and/or infrastructure as appropriate
2. Soft skills, particularly different styles of communication and organisation
3. Domain knowledge relevant to the role/product
4. Knowledge of any specific language, tool, process or technique
We could debate the order of the top two. Domain knowledge is new to almost everyone when they first start a new role, unless they happen to have worked for someone else in the same field before. The specific technologies are rarely going to be an exact match, but that doesn’t matter as long as someone has good general knowledge and the motivation to quickly learn new tech when they need to.
I can’t help feeling that a lot of problems in a lot of development groups would vanish if hiring was based on looking for good fundamentals and a professional approach rather than strict buzzword compliance, and if the day-to-day working environment then supported good people doing deep work. It’s not really surprising that some people think every new technology will take weeks to learn and capable full-stack developers are mythical creatures when you look at the environments and hiring processes they are stuck with, but it doesn’t have to be that way and of course the better developers are drawn to the places that aren’t, which continues the cycle.
Thank you
That sounds like the kind of reasonableness that just does not come across to me when I read so many job adverts.
When I read 'full stack' it says to me 'know this stuff', otherwise you should put "we need this and you also need to learn x, y, z, ..." as the need arises. I can do that.
I agree you need to know all those things pretty well, but I don’t think that’s a huge ask. You can definitely pick up Kafka in a few months.
Look, maybe all that’s not your thing, which is fine, but knowing a wide range of tools and being comfortable in any part of the architecture isn’t some crazy rare skillset known only to certain cyborgs. It’s certainly not idiocy to seek those people out.
I think it fair to say if it had not been for me, 2 successful business would have died due to sql perf. problems. Edit: what this means is if you go for a shallow skill level it works at first but may cost later, and very heavily.
Good back-end langauge skills, well, I can pick up C# in a few weeks and indeed did - because I had a ton of other language experience behind me. That isn't something you get in a few months - and I mean not just the language but the whole gamut of techniques for solid programming, and you can add functional programming on top. Then you need to understand about garbage generation and big-oh costs of algorithms so you don't do twatty things with linked lists.
How about web dev? I know more about html/http/user interfaces than most web devs do and you don't have to look far to see the mess they made (I choose not to be a web dev).
Maybe I set the bar high but when I see a list of skills, I assume it means "be actually good in these" not "pickem up as you go along"
Perhaps people should be more clear about what they want.
> It’s certainly not idiocy to seek those people out.
Maybe you aren't looking for the level of skill that I assume you are. But be clear what full-stack means because others (me) may misunderstand it.
> because I had a ton of other language experience behind me
Yes, a full stack dev needs this. Why wouldn’t they have it? You seem to be conflating seniority/experience with breadth of skill.
Edit: I'll also point out that languages aren't the only thing that "rhyme" in tech. If I were already experienced with Pulsar and Rabbit, I'm not going to have much trouble with Kafka. If I know Terraform well, CloudFormation isn't going to be a complicated new tool. Etc. Having breadth of experience makes taking on seemingly complicated new things far less daunting, as you point out with your c# example. That applies across the board.
> How about web dev?
I’m not quite sure what you’re trying to say here, but web dev is pretty straightforward, and of course full stack devs have typically done a lot of it.
You are either overestimating how hard it is to learn all this stuff, or you are underestimating how close you are to being able to do it yourself.
Edit. Here is a framework for thinking about it. You have been doing SQL for decades. But how much genuinely new skills related to SQL have you learned in the last, say, 5 years? Probably not many, because learning is logarithmic like that: you learn quickly at the beginning, and then more and more slowly. So what if you had instead learned a new skill 5 years ago? You'd be quite good at it by now. And if you kept using SQL, you'd stay pretty good at that too. Rinse and repeat a couple times and you're a full stack dev. You'd notice another advantage too: the undercurrent of convergence, where you notice the same patterns emerging in disparate parts of the stack and architecture, and finding yourself reapplying the same principles in very different contexts.
Quick question. This.
this gets you as the resultwithout running this (same query as above but for addition of a null):
what's the result?This can be an expensive mistake. It threw my old company into a flurry. Rare, but it happens - do you know why?
> while there is plenty vendor-specific knowhow, that is just stuff to learn
that stuff is precisely the difference between sleeping at night and "WTF now???, it's 3am and the clients are phoning me from singapore". And then losing your company or spending 20X unnecessarily on a scaling up box. You underestimate it.
> You are either overestimating how hard it is to learn all this stuff, or you are underestimating how close you are to being able to do it yourself.
Yeah, this discussion has been a major eye opener for me. I wish it had come much earlier. Thanks.
Another that hit our company, was not understanding isolation levels in SQL, meaning that two people who could write SQL very well didn't realise their approach to avoiding a race condition just didn't work. When I pointed that out, they had a hotfix on client sites by the end of that afternoon.
I worked on the Cassandra database, we were having problems (albeit in development, it didn't reach production). Turns out truncating in the database did not release the space. That was causing people a lot of problems in till I ran into that by chance. These were full-stack, and smart, I respected them.
You can't have what I consider thorough knowledge on all fronts, and if you don't you can pay very heavily (I can give other examples). No more than that, no LOL'ing at people.
Draw your own conclusions I guess.
Anyway, thank you for taking the time to reply and for several people here pointing out that I've got the wrong end of the stick.
Edit: the sql example was me trying to make a point, not trying to catch you out. Please don't take it that way. It came across badly.
I meant the whole list of things I mentioned, not just one.
DevOps, DBMS, HTML+CSS, JS, a back-end language, a front-end framework, both language and framework considered "non-transferable" by many for some insane reason, "cloud". That's just the beginning.
>I’ve never met a happy, successful programmer who didn’t enjoy the craft.
You're conflating "juggling the company's entire stack" with "programmer". Many of us learn programming for reasons other than fullstack webdev, but we work there because the vast majority of low-risk, well-paying jobs in software development are webdev, while doing the things we consider "fun" in our own time.
At the very least, piping generic information and writing glue code isn't my idea of "fun programming".
> They ask for everything
I don't know who "they" refers to and what those they ask for, or what everything is.
You're not concise and are answering from subjective point of view rather than from logical.
This forum has plenty of engineers that can be considered full stack. You having worked with a few humans who, in an era of their life, decided to pursue something you didn't - means nothing.
> It's like asking for a full-stack "vehicle" - car, ship, lorry, tractor, rocket all in one, it's not happening. Idiots.
See, it's the opposite. What we refer to as "full stack" is, in my opinion, your basic version of a programmer. A person who solves the problem using tools and are capable of using the right tool for the problem, or find the tool that fits solving the problem.
Full-stack would be the vehicle in your story. Not a specialized one. A vehicle. A complete system that can take you, the "client", from point A to B. Even your analogy is lacking.
I've no idea why you went on and typed "Idiots", it could very well be the ineptitude of handling the fact there are individuals who are capable of achieving what you deem impossible.
employers
> You're not concise and are answering from subjective point of view rather than from logical.
It is coming clear that the definition of of 'full stack' is perhaps my tripping-over point. I think of it as meaning extensive knowledge and experience over the whole stack (and that in my terms means cache-line layout to algorithms to frameworks to sql to databases to http to web dev to web standards to to expertise in aesthetics & UI usability).
So where do you get your definition of 'full stack'? Pls show me.
> See, it's the opposite. What we refer to as "full stack" is, in my opinion, your basic version of a programmer. A person who solves the problem using tools and are capable of using the right tool for the problem, or find the tool that fits solving the problem.
That's called generalists. That's me (web stuff excepted). I'm good at that. Why not call them that?
So what does it mean to talk about 'full stack' then list a load of tech, as happens in job ads? Cos it implies to me existing knowledge of these things, not just ability to learn them (which I can).
'Idiots' was a mistake.
You know very well that people in our field like big words and big terms - full stack developer, machine intelligence, leaky bucket algorithm, graph query language, functional programming, aspect oriented programming - just to name a few.
If we gave easy-to-understand names to everything, what would marketing do? :)
What you call as generalist can be interpreted as someone who can't use tools proficiently or produce high-code quality.
> So where do you get your definition of 'full stack'? Pls show me.
It's something we used in the earlier days of internet do describe someone who's capable of producing usable user interface sprinkled with some javascript that basically works and create db that accepts the data you insert via some kind of form that php/python/ruby processed.
It was basic "bragging" rights in the beginning, it meant "look, my thingy looks good and I made all of it myself, I Installed server software, hacked up CSS, HTML, wrote serverside code and inserted all of it in a DB".
Context: plot happens at news groups, circa 1999.
The name, along with people, evolved. There's no concrete definition. You can tell, since you assumed "full stack" means A and to me it means B.
One who can take a web-based project and create it from 0 too 100% = full stack, as it takes the full stack of tools relating to backend and frontend to complete.
> That's called generalists. That's me (web stuff excepted). I'm good at that. Why not call them that?
I don't know. I never liked the term full-stack and I met plenty of people who claimed the title but what they had to show for didn't fit the title they claimed.
> So what does it mean to talk about 'full stack' then list a load of tech, as happens in job ads?
No idea honestly, I never take those seriously. People are unstable and not trustworthy, all you can trust are facts and facts are hard to come by when it comes to hiring. The tests are the only way to assert anything, and it's difficult to create such a test, let alone run it. It's not nice for sure.
I understand where you're coming from now. I don't pay too much mind to terminology, I learned years ago that a simple algorithm that any newcomer will discover has 50 different names. That alone tells me we like to reinvent the wheel and brag needlessly.
Answer is very much appreciated! Thanks.
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...
> 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.
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?
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.
Lots of people don't like to hire those anymore.
I hired in at one place, was informed afterwards that it was only because they were so desperate that they hired me despite my demographics. Was reminded repeatedly on my sins of being a white male.
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).
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.
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.
A couple of things that help me when considering this question:
- Is it really a question of "right" vs. "right now"? Is there a genuine compromise with choosing the simpler option? In my experience there often isn't. Using server rendered HTML vs. a SPA for some types of applications isn't going to result in a poorer UX. Using a slower language might be fine forever if raw language execution speed isn't your bottleneck (it rarely is IMO).
- Is it more expensive to do what's best for later later? I think this is especially relevant for dev ops questions. Moving to a Kubernetes setup is going to be just as expensive in the future as it is right now, so it's better to delay that cost for when you actually need it.
- How likely is it that you're going to know what is going to require a more robust solution now? Do you know what the service boundaries of your microservices are going to be? Do you know which portions of your app are going to be scaling concerns?
Why?
Why is it unrealistic to expect a school teacher to be able to teach every single subject?
Because in these fields, along with software development, there's too much breadth of material to sufficiently explore the depths of all of it. Having the breadth and depth of experience required to have mastery in every bit of minutia is a even slightly complex webapp is enormously difficult to obtain and maintain for a single person.
Someone can master a subject in 5+ years if they do it everyday. A fullstack dev with 20 years experience can master all those stated and more and I know fullstack devs (granted not many) than can maintain entire apps like this.
The problem is that all of these are moving targets. You don't master DevOps in 5 years and then you're done forever (same with backend and front-end development), these are constantly changing fields that require continually honing your skills.
I'm a fullstack dev who is often our devops/kubernetes lead. I'd say over 50% of my day is around DevOps tasks, but I'm likely to write an API or hone a frontend animation as well. I contribute on all parts of our microservice based kubernetes government application, but do skew to the devops side where the rest of my teams' experience is lighter. I can write iptables or webpack configs, I can implement OAuth or modify bezier curves for animations, and frequently do it all at my job. I have just over 10 years of professional experience but have been programming longer.
Full stack doesn't mean everything.
And actually all the doctors are doctors first, so they know everything about medicine, except they are not specialized in all the medical specialties.
Which is rarely a requirement in medicine.
Brain surgery or conjoined twins separation isn't that common, but an highly specialized surgeon is perfectly capable of curing common diseases just like a cardiologist can perform common surgery, such as appendicitis.
Full Stack means that you can get things up and running, not that you know everything of everything.
Absolutely nothing of value was accomplished. By the time a person started to get decent at Kubernetes and frontend and backend and support they would find a better job with more realistic expectations.
So we basically we were paying people to learn for a year, then they would leave.
The reason those single stack skills diverged into specialisms is because the results were better, especially beyond a certain scale. An SPA done right provides a much more responsive and rich user experience than forms and a full page reload. A DevOps engineer can create a system to deploy quickly, in a reproducible manner and safely when compared to copying a bunch of files over to some servers (and provisioning those servers manually too).
I don't think it's sustainable though, for a large set of use-cases common to everyday web and app development. Having separate front end and back end roles requires maintaining a minimum of two projects instead of one, defining and maintaining an API, managing co-ordination between different developers and understanding how to split scope boundaries between technology and people. It's lot of extra communication both for people and machines. It's more difficult on a management level as well - separate recruitment streams, different evaluation mechanisms, parallel promotion ladders, resourcing headaches, etc.
Now we have the benefit of knowing what's required to compete in the modern landscape, I think we'll start to see the return of a new set of frameworks and runtimes which give 90% of the benefits of separate FE/BE/DevOps roles whilst allowing a single engineer to focus on application development. I'm thinking of things like Elixir's Phoenix LiveView, and eventually frameworks that compile a single codebase to WASM for the browser whilst providing seamless integration with the backend.
It seems like an economic inevitability; anything that lets people ship value more quickly and efficiently has to win out in the end.
I know a few exceptional software folks who have a deep understanding of React and Java backends. The problem for the most part is that it has been difficult to be a full stack engineer because of the churn of FE software frameworks. Now that React has be around for a while, it is well understood by many people and having a decade of software experience means that you can be very competent and knowledgable about both the FE and BE. My expectation is that if React stays popular and is generally similar to how it works today, we will see a lot more people be able to do both FE and BE systems.
Typically a person will still be stronger at one than the other, but they can still be great at both.
Totally this. I can do javascript. I have written a LOT of javascript in my life. I worked with jQuery, I've worked with React, I have worked with knockout and this and that and this and.
Meanwhile my backend stuff hasn't changed all that much in 10 years. Yes I learn new things, but what I know about javascript and web development has largely gone out the window.
This whole thing is developed by some rotating cast of developers on contracts, who have no interest in maintaining anything long term, and so its just piled up and piled up. Technical debt doesn't exist when you will leave the project for the next guy.
Anyway... we're making progress against it slowly but it's really frustrating because our website is loading so much crap and untangling it takes forever. Half of me wants to throw the whole thing out.
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.
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.
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
“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 .
But your knowledge of Java frameworks or Maven configuration will be quite useless for your new C++ project.
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, 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.
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.
Any developers that claim to be experts in all of those tiers are likely delusional.