Why the full stack engineer is problematic (2020)
itrevolution.com
itrevolution.com
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).
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.
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.
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?
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.
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.
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.
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.
> 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.
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.
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.
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?
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 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.
At 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.
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.
“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.
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!).
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".
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.
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.
with tbl as
(
select x
from ( values (10), (20), (30) )as tt(x)
)
select \*
from tbl
where x not in (10, 30)
x
---
20
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)
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.
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.
> 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.
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.
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.
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...
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.
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".
"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)
Any developers that claim to be experts in all of those tiers are likely delusional.
"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.