I remember this one job, I got assigned to this team because their rockstar left the company and I had similar overlapping talents. His code generally wasn't te

I remember this one job, I got assigned to this team because their rockstar left the company and I had similar overlapping talents. His code generally wasn't terrible, but he had this habit of being /way/ too clever for his own good. For instance, we had this 3d mesh file loader (for a game). We wanted to add another file format, since the legacy one we were using was some ancient outdated thing from 3ds max that only one artists could export from their machine, so it was a bottleneck in the pipeline. Anyway, this fricking mesh loading code should have been, if well designed, super easy to update right? Hell no! This guy attempted to use every template meta-programming feature available in C++, so even adding a method to a class would suddenly result in this nightmare cascade of indecipherable template issues. There's this phase any every developers career, my own included, of "being just smart enough to be dangerous". It's like, you're smart enough to use those kind of features, but not smart enough to realize that just because you can doesn't mean you should. The worst part though is, when you take it over, the expectation from non-technical people is "well this guy wrote the feature in a weekend, why can't you update the feature in a weekend"? So you end up looking worse in comparison because your predecessor set you up to fail. I would implore anyone writing code that has some empathy: try to setup the people working on your code for success.