I have had a similar situation where a very senior engineer worked in the same team  and in the same role for some time(like 20 years). Consequently, he was SPOF for 10-15 critical projects/microservices. Everyone else who may have worked on these had already left.\
\
He would be hesitant to share their knowledge and, when asked, would draw circles around the concepts.\
They often derail themselves when explaining things, making it extremely hard for the other person to understand.\
\
This is what I have seen to have worked.\
\* try solving more minor relevant bugs related to it.

- Record videos of the Knowledge transfer.
- Ask your manager for some time to review the code. Write some unit tests if you can. (In my case, it was hard because the code was written in legacy C++/C/fortran, so one couldn't write unit tests, and there wasn't a debugger too since the services ran over ibm/solaris machines) Hopefully, you have it easier than this.
- Document what that person tells you in confluence or wiki. The more that person's knowledge because commonplace, the more you can extract from them next time.

Senior Software Engineer at Intuit

anonymous18

I am not an expert like Rahul and Alex, but for me, working remotely is super important. In my past company, we had a mandate for everyone to return to the office.

I changed companies in the past to move to remote work. I was even willing to take a pay cut for the same but I didn't have to. I think I still continue to enjoy remote work and have no plans to move to a company where a return to office is mandated (even if it doesn't mean I don't work for FAANG or get a super high-paying job)

To each his own, I guess. It depends on what is essential for you. And will change employers should the need arise. But I do work hard for whomever my employer is though.

Intuit

Senior Software Engineer

I think what would work here is to have smaller prs which means less peer review comments but for places where that might not be feasible the first thing is to do is to have detailed pr review descriptions and second for people who are prone to changing their minds establish a quick sync before starting implementing their feedback.

That way you can learn from them but not have to worry about them changing minds later on.

Thats a great question. To add to the complexity of your questions there are now serverless containerized options like knative and such..

This is really hard to predict but i would like to be cloud agnostic in general and use the containerized workloads since it has a lot less vendor tie in. Further ease of development and having more control with configuration are more cherries on top for containerized workloads

It depends on what your goals are and it seems from the post that your goals are here to learn.
I think there is somethings to learn from leading and maintaining a legacy product but it is far and far less limited in focussing on something and developing something from scratch. I would changes teams or change project or change company if I have to in your shoes.


Papers

It doesn't matter how talented you are as an engineer: When a talented developer is pitted against a crappy team, the crappy team wins 99.9% of the team. In order to grow in your career, you must find a supportive team first.