Do most full stack developers find themselves using framework upon framework to do most things, and not getting enough time to actually understand how the framework actually does the things under the hood? I think in companies there is a lot of pressure to do all things as soon as possible and move on to the next high-priority thing. I want to know if a lot of developers face this, and how they cope up with it.
No pressure. The big promise of a framework is usually gaining some advantage of speed on some metric. We are usually optimizing for speed on some facet of the software project!
We can evaluate our dependencies very clinically. Frameworks usually promise on speed to deliver and this usually comes with an opaque tradeoff cost of one of the other aforementioned facets of speed.
Often speed in refactoring/maintenance can slow down with a framework. Either yours or theirs. Newer frameworks change more in the early days creating thrash. But they usually stabilize with time. Likewise userland apps bolt on new functionality accruing dept with time further locking the codebase into an older and older framework. Neither of these things is inherently bad as that many frameworks nowadays value API stability. But regardless you should independently verify that by looking at the changelog, releases, issue tracker and stackoverflow. Maybe your team can take some of the framework maintenance on and contribute back?
Of course a stable API might not matter much if the tradeoff is speed in terms of raw network performance and compute execution. Obviously we can look that very clinically. How big are the payloads? Etc. I like using DaisyDisk to check out the disk cost and either Firefox or Chrome devtools to ascertain the network cost of webby stuff.
Frame explorations in terms of testable experiments attempting to falsify a hypothesis. You can evaluate a smaller dependency in a day. For something larger like a full blown web framework or language I'd budget least a week. More ideally.
It is valuable for everyone involved to do the best diligence research for your long term organization and project needs. And given that no two projects ever have the same dep tree it is clear there is no singular right answer for all scenarios.
Also know that at some point somebody has to make a call and sometimes that call will be wrong but a good team will catch that and correct it with a blameless retrospective.
“If we have data, let’s look at data. If all we have are opinions, let’s go with mine.” Jim Barksdale
I think that goes for beginners; experienced programmers have a lot of ideas about how they might work.
I, for myself, have written a lot of “vanilla” code. I know how to communicate with SQL and NoSQL servers, cache systems, and a lot more. I know how to handle Web requests, command line options, environment variables, I can manipulate memory and files pretty effectively. I know how the operating system works behind the scene. Heck, I even know how bits are flipped in memory modules and disks.
Bragging aside, if you have seen a lot, you probably know how things work under the hood. If not, even a framework wonʼt help you.
There is always pressure to finish things as fast as possible. The higher up the food chain you go the more pressure you face. Interestingly, most of the effective leaders I've interacted with in the upper echelons are incredible at handling pressure and managing people below them, so they don't feel the brunt of the pressure.
That's one of the biggest thing that separates an effective leader from a bully. They lift you up and shield you from that pressure so you can perform your best. It's the only way I've been able to effectively manage people.
With that said, what you're talking about seems to be a two-fold problem. There's the pressure and then there's the execution of getting the job done. If you're talking about using many frameworks, you should really only be using one framework and maybe a couple libraries.
You should be highly skilled in a framework before moving on to the next one, and proficient enough to scan a library and test if it works for your needs.
But that's ideally. What tends to happen (unless you're lucky) is you just get it done by any means necessary. Once you advance further in knowledge and your career, you'll be able to make better choices about where to work and find a place where it isn't so dysfunctional.
TLDR; Yea, it's very common in my experience. With time and experience you'll have more leverage and can leave those kinds of situations behind.