It’s hard if you have unprotected, shared mutable state. If you use a language that uses immutable data structures (Haskell, Clojure, Erlang) it’s easy! If you use a language that won’t let you share mutable data without the required protection (Rust) it’s also easy! Everything else and you can be sure that even if it looks like it works, it most likely doesn’t.
When I was still at university, I started working on a place where Spring was used… they gave me a book called “Spring in Action” to read. I loved reading it and everything made much more sense after that… I highly recommend trying to get a deep understanding of something so central to an application like Spring before you start doing anything more advanced with it. You wouldn’t want to drive a F1 car without first learning how to do it properly, it may be fun at first but you’re likely to crash and burn.
In Java it’s really rare to see hundreds of files in a single package (dir)… do you have examples showing anything different??
I think you may be failing to internalize the real lesson from your anecdote: how hard a task is has almost zero correlation with how valuable such task is for the business. If management didn’t care about the very difficult work you did, and assuming management actually has a good understanding of the business, then that very difficult work just wasn’t very valuable and maybe shouldnt’ve been done at all (because if you do a cost-benefit analysis, and something is really hard and the benefit small, it’s an easy call to not do it).
Of course, there are things that have almost no immediate benefit to the business but must be done, like when you need to refactor a large code base to be able to implement future features in a way that doesn’t destroy the software from within… but if you analyse such cases properly, their benefit is very big for the company in the long run and that’s where communication plays an important role: management needs to understand why that refactor is so important, which I admit may be difficult in case of non-technical management (but then you have bigger problems than just properly judging the cost-benefit of some task).