> All teams are different, and a good rule of thumb is to write code the least skilled or experienced person can understand on its own without guidance. This.

> All teams are different, and a good rule of thumb is to write code the least skilled or experienced person can understand on its own without guidance. This. Also, if your team develops on framework X and people are hired based on that, stick to the damn patterns used by your framework! I had once worked with a developer that one day unilateraly decided that the abstractions provided by the framework we used were not good enough. Instead, we should use the abstractions from a "design pattern" described in a shitty blog post they dug up, and "everyone should read". There wasn't enough pushback, so we had ended up with some seriously unmaintainable code.