As a software developer I've worked with Unity and Unreal in a professional capacity for many years, and shipped quite a few games on both engines. Unreal is powerful, but really shows its game development studio and FPS game roots. Unity has limitations, I won't deny that. And both engines have their own issues and different frustrations in using and deploying them. I have also shipped games on internal, custom built engines too. From a business perspective, hiring Unity developers, i.e. people who can code in C#, is a lot easier. Unreal developers are plentiful, but their knowledge of the guts of Unreal usually stops at the surface level, barely dipping below Blueprints, at least from my experience.
Personally, I prefer Unity over Unreal, but am not averse to using either, in the right context.
The power of unity is that you don't have to delve deeper, just start it up, make a script and start writing code. The weakness then is that all the components you code against are horribly bad/slow, so for a bigger game this approach wont scale, but if you are a programmer and just want to code a simple game unity can get you there in a weekend. First project I made in unity was a top down shooter with simple random map and powerups, took a weekend, I've tried using unreal but it is way harder to interface between code and assets and ui there.
Edit: My point here is that in unity you can easily write your own replacements since it is so easy to write new components in C#. This means you don't have to learn how unity did things, just write your own if you don't like what they did. The only exceptions here are physics and the renderer, you can't easily replace those.
> The only exceptions here are physics and the renderer, you can't easily replace those.
While physics is in the engine itself you can definitely replace or modify the render pipeline. Unity comes with a built-in legacy pipeline but nowadays you mainly use either the High Definition Render Pipeline (HDRP) or Unified Render Pipeline (URP) both of which are open source packages. Meaning they are modifiable. They are also both based on a common base class: Scriptable Render Pipeline, which you can extend to make your own render pipeline from scratch.
Source code access in Unity is available but very expensive, even for large studios.
Coming from a background of working with engines where the source is available it has been frustrating to me being unable to dig into or modify the engine. Especially when I'm at the mercy of some obscure engine bug. But most of the time I've managed to make do.
This advice is a bit generic - but look at either the official examples or tons of github projects that have C++ in them and try to understand how they work - that's the thing that worked for me.
First of all, you have to manage your expectations and be mentally prepared for the fact that you will just not get most of the engine. UE is a massive project (and that is an understatement) and you will be a VERY good student if you just grasp the gameplay framework (core functionality in c++) and a few specific things (if you understand rendering, you may fiddle with the renderer, if you're an audio engineer, mess with meta sounds etc.). If you just look at the amount of code being pushed into the UE repo, you will soon realize that no single person will ever be able to grasp and contextualize even 10% of the engine. It's just not happening. With that out of the way, what I found incredibly helpful was the Ue4/5 cpp game courses on Udemy from Stephen Ulibarri.
Personally, I prefer Unity over Unreal, but am not averse to using either, in the right context.