But reality is harsh. Scrum ceremonies eat up more time than I feel like they should, and they don't even work well enough IMO. Our team unsurprisingly works on one specific service, which is 90% black box to me because nobody has the time to introduce me to the domain. The rest of a system is even more opaque. Dedicated devops team handles all infra/CI/CD, and I have no idea how and where the app is deployed, I only know we use k8s and docker for that.
It feels like an eternity before my team would consider me knowledgeable enough to discuss anything significant with them, e.g. data modeling, service interaction etc. And even when that would happen, I'll find myself in the same position where I left previous job - a big ball of mud you only can throw away and start from scratch.
Overall I don't care because the pay is way over than a junior dev would normally get. I'm more worried "n years of experience" line on my resume would mean nothing. How do I prevent that?
Frankly it’s making me want to quit. I wonder how this company will succeed with this culture. (Already got an offer with 30% increase in base).
> Our team unsurprisingly works on one specific service, which is 90% black box to me because nobody has the time to introduce me to the domain.
I am sure atleast one person would be more than willing to do that if you asked, they might even appreciate getting an hour break from their usual grind.
> Dedicated devops team handles all infra/CI/CD, and I have no idea how and where the app is deployed, I only know we use k8s and docker for that.
Again, you need to ask. As someone committing code to your app, there is no reason for you to not know how and where the app gets deployed even if you are not handling the actual deployments. This is not even optional, someone on your team has to walk you through the process otherwise there is a latent background risk of there being an issue due to not understanding the context of the deploys or not knowing what to do when a change you make breaks something (and it will eventually).
You’re going to do things hundreds if not thousands of times each year at the job. Each time you do them again, it is a wonderful time to ask “Why?”. Why do we scrum like this? Why do we not make time to share domain expertise? Etc. After asking “why”, then ask yourself “how might I/we” with regards to a better path forward.
You’ll be able to see your own individual path of things you can change to make your life at work more enjoyable, but the most enjoyment I get is challenging the status quo especially if everyone else feels the same way and nobody largely knows why things are the way they are. Talking to people helps you realize that nothing is really set in stone and can bring more meaning into what you want to get out of the job.
Unless you are very curious about the details of different ways 'microservices' can be done wrong, there's little reason to stay and try to understand what's there. I could be wrong, like if the reason it doesn't make sense is lack of domain knowledge, in which case it may be worth staying and getting a view, but the environment doesn't sound very conducive for learning.
Side-topic: I thought DevOps was supposed to be the opposite to this - but this is my experience too.
On-topic:
If you really can't get someone to sit down with you, you could ask to attend some meetings and try pick up on what senior engineers are talking about.
That's a good question. One that I failed to address in my career. I would say just focus on the tech (AWS, a language, microservice stuff like toggles/versioning). But that's just my guess.