I have 7 years of experience in the field as SWE, but I am having a really hard time reading/editing code produced by this team. It's not because I'm new, it's really because I don't think I am hardwired the same way as them. I am trying to decide if the issue is me (I am stupid and they are very smart) or them (I am normal and they are exaggerating). I tend to produce code that is as simple as possible, that really anyone else with minimal experience should be able to read and understand. I never introduce gratuitous abstractions unless they allow me to deduplicate code or write tests more effectively, so I don't just "decouple" components for the sake of it. Besides that, all the typical junior tips apply to my code as well (descriptive names, short functions, idiomatic patterns, ...). The people in this team instead produce incredibly complex code that is very hard for me to read: BY DEFAULT, everything they write is incredibly abstract, with multiple levels of interfaces/abstract classes even for stuff that doesn't need it at all. Then, the logic inside the classes is always super generic with a myriad of custom template parameters or functors. It gets really hard to follow, it's as if the real business logic I care about is buried in an immense web of abstractions, and I have to navigate through 50 different classes to understand a simple behavior that could be coded within a single class and a handful of normal methods! What do you think?
Code shouldn’t be hard to read, if it is you’re usually falling victim to technical debt or people who enjoy adding complexity for the sake of reducing line numbers. Ask yourself, what makes it complex? Have a open conversation with your team. Collect their reasoning and then evaluate.
“I tend to produce code that is as simple as possible, that really anyone else with minimal experience should be able to read and understand.” I pretty much try to achieve this on daily basis. My team also strives for this. This should be a fundamental thing for a software engineer.
Sounds like you write good code and your team don’t
Of course he'll make it sound that way. We need concrete examples
Imagine making HEAVY use of multiple and deep inheritance hierarchies on top of generic programming (and use generics not just to leverage custom collection types as it's typical, but custom behavior too, so coding all code paths as behavioral classes then passed as template parameters, which the main class combines with a lot of functional patterns) in C++, for every single part of the code. That's something I am not used to at all.