I started learning Unity through their online learning pathways and I can't help it but Unity feelsmkind of gimicky. Like it's a lot of clicking your stuff together and using predefined components (at least at the early learning step I am right now) and very little coding.
I expected more of a Framework.

There is plenty Framework stuff.
You'll learn it once you become more advanced with using Unity.
It's kinda made to be easily accessible, hence why a good amount is a bit abstracted away.

The thing is, it IS like a framework. Most people just don't know that and then don't know how to make a proper game

You still need a code base with a proper architecture in C# orthogonal to the engine. Making a bunch of prefabs with random scripts that live in entirely different universes is the worst way to use Unity

ummmm...
... try to do literally anything non-generic, anything that is specific for your game?

like... setting up lights, collision boxes, rigidbodies, animation graphs, models and their materials...

why would you expect these generic things to require code (in a game engine)? and would you really want them to require code?

if you're bored of clickity click, forget those tutorials you're watching and juat do tetris (more difficult, you either need some hack to detect filled lines, or do all the logic separately and use unity only as a display frontend) or breakout (much easier, one short script for paddle, one to handle brick destruction, the ball can be physics driven).

my point is... be glad for the clickity parts because they are the fast and easy ones, but don't think they'll get you far.

Don't get me wrong, it is nice, just weird for someonewho's used to write thousand-file-enterprise java applications.
I was just surprised by the tutorials approach, eg. ojce I had to wirte a short Script which referwnced another gameobject and to get it I declared a public variable and dragged the respective object into the field in the inspector window of the other scripted object. Or when implementing a simple object spawning we used a empty game object with a script called spawnmanager.
If this was the work Flow I'd fear large objects, just draggin around hundreds of gameobjects and having hundreds of invisible manager objects floating around in the scenes.

@Katakompe
well... there isn't really a strictly defined workflow in unity. it kinda allows you do design your architecture almost any way you want. what the tutorials are showing you are more like some of the most basic ways used by the code to *interface* with the engine.

the most *basic* - but you know how it is with basic approaches - quick and easy to use, easy to learn for beginners, but they scale badly.

my recommendation is don't judge an engine before having made at least a one complete game in it, especially when you're coming from a non-game-dev background.

what you mentioned with the gameobject referencing and spawning, is pretty much industry standard in gamedev, every engine i know does/supports it like that.

the key is to realize all your code is running within a scene/level. nothing you're writing is the topmost code, engine's code is the topmost code.

then, the need for "empty objects" as carriers of scripts (as well as other things) will start making more sense

@Katakompe
"hundreds of invisible manager objects"

you won't need that many managers, probably ever. and if yes, so what? make them children of a "Managers" object to keep it tidier.

but yeah, it requires a slightly different organizational paradigm, and to be honest, i've been working with unity for 10 years and i still haven't figured out one that i would truly like and think is truly good =D

another helpful way to think about it is that the unity editor is basically a level editor with some extra features.

imagine having a button prefab and a door, programmer writes a script that opens door after button press, puts it on the button prefab, then you as level designer put the button in the scene and to define which door is supposed to be controlled by that specific button, you drag that door into the button's "controlledDoor" field, right?

it's... i recommend just give it more time, and don't judge things based on your Java enterprise expectations, rather try to figure out why they might be useful in a setting where very technical people code components which are then used by less but still pretty technical people to be composed into larger multimedia components (graphcs+sound+animation+behavior), which are then used by not really technical people (level artists and designers) to build levels/worlds out of.

also the design process itself is the other way around compared to enterprise where u usually first sort out the business logic and u define what user sees last.

in games what player sees is the business logic, so first you design that, and often you also implement from that side - what's seen first, and you move inside, down, towards the "backend" code that actually ensures that it works and behaves and looks the way you want.

games are mostly just a pile of hacks and smoke and mirrors to make it appear as if something is happening, even though it's really not, not even in the backend.

the whole field is very different from corporate enterprisey stuff.