Most often, it seems to me that I'm not doing anything complex. I'm not a pioneer and I'm not making any discoveries. My approach is that I just walk along already laid paths. I wait for these very pioneers to step on all the rakes, settle on something stable, and I'll just use their work. They say wise people learn from the mistakes of others, yes.
Any sufficiently large project is always restructuring across a very wide range of directions. And incremental refactoring in breadth-first, actually, is much more useful than getting stuck in one topic. We do such a large volume of work precisely because we know where and from whom to peek at good solutions, adapt them for us. The main thing is to close it with some right abstraction, here you really need to think. But if you invent your own wheel-implementation for each of these directions, then, of course, no amount of time will be enough, especially with a fairly small team.
And we do a lot. Just in the last few months... Put a design system on Compose on its feet, establishing communication with designers for this. Came up with mechanisms for how to extract modules with maximum benefit for build time, behind this as a domino go Gradle plugins, templates, navigation and DI, it hasn't reached widespread use yet, of course, but we had to shovel a bunch of materials and think it through. Without understanding metrics, it's also quite pointless to do this, so a bunch of work was done to learn how to collect them.
Not to mention that our processes evolved from building a bundle for Google Play on developers' computers and testing unclear what builds - to normal enterprise: with CI pipelines, a bunch of static analysis, automatic publishing, code review, feature testing, release trains and so on. Predictability and confidence have skyrocketed compared to what it was just six months ago. Although, obviously, there's room to grow.
And that's not to mention the usual routine, which, in fact, is almost always more than technical work directly. Meetings, discussions, somewhere help someone, answer questions, trigger someone to speed up processes, deal with bureaucracy, access, test data, a wagon and small cart of such activities.
The best high of recent times is that we managed to remove several native libraries, because of which we reduced the application size by 3 times. This is directly a line in the resume right away. But what's unusual about just taking out the trash, it would seem. But to understand that this is trash at all, we had to walk around it for several months, because it's complex, this huge bag of trash used to be covered by a wall.
I calm myself with this. Just knowing such a quantity, albeit high-level, facts - this is already a skill for which people work for years. All my previous experience always came down to the fact that it's rational to act this way, so I developed in this way. Typical 20% effort for 80% result.
The irony is that the most interesting technical content is created by people who are deeply immersed in what they're talking about. It's hard to find something to share if you just digest the experience of some HH, Avito and redmadrobot for a good enough solution in the context of your project. Well yes, you work around your limitations, but nevertheless.
On the other hand, I've always liked to read or listen to such a reflective stream of consciousness from other people, the problems are not new, it's nice to understand that you're not the only one.