I had this issue before -- I spent a long time trying to figure out what my brain told me was 'clever' code. For me it was 2 things:
1. Code that takes advantage of a constraint in an unexpected way (if you know the input will always be 'a' or 'b', you can write 'if not a:' and do things that assume 'b')
2. Code that allows for reuse in an unexpected way (you know these because the explanation in code review is 'in case we switch to system-X, we won't need to re-do this part')
Both of these are really cool in an academic setting because they're bonuses. They're like plot twists, only with code. However, in the real world, these are both pretty bad.
1 is bad because you generally don't know what constraints are 'fixed' and what aren't in your business. 'not a' might mean 'b' today but might not in two months. Your best bet is to make very clear easy-to-understand, easy-to-predict code so when you do learn new constraints you can quickly fix or extend the code.
2 is bad because it's usually premature optimization. Honestly think back to how many times you or someone you know has added code in this way, adding an abstraction layer somewhere or adding complexity because it will allow for extendability later, and think back to how often the code had to be extended in the way predicted. Usually this seemingly clever piece of code ends up being a weird extra step you always have to remember later ("oh, then we convert it into an array of strings and back into ints")
So I would say you should look at the applications you're building and think about what 'smart' code really looks like in your day-to-day and if the people you're talking to are creating such code. I'd argue they aren't, and one of the problems is that part of you believes they are, so you're having trouble articulating why they should stop and why it's harmful.
1. Code that takes advantage of a constraint in an unexpected way (if you know the input will always be 'a' or 'b', you can write 'if not a:' and do things that assume 'b')
2. Code that allows for reuse in an unexpected way (you know these because the explanation in code review is 'in case we switch to system-X, we won't need to re-do this part')
Both of these are really cool in an academic setting because they're bonuses. They're like plot twists, only with code. However, in the real world, these are both pretty bad.
1 is bad because you generally don't know what constraints are 'fixed' and what aren't in your business. 'not a' might mean 'b' today but might not in two months. Your best bet is to make very clear easy-to-understand, easy-to-predict code so when you do learn new constraints you can quickly fix or extend the code.
2 is bad because it's usually premature optimization. Honestly think back to how many times you or someone you know has added code in this way, adding an abstraction layer somewhere or adding complexity because it will allow for extendability later, and think back to how often the code had to be extended in the way predicted. Usually this seemingly clever piece of code ends up being a weird extra step you always have to remember later ("oh, then we convert it into an array of strings and back into ints")
So I would say you should look at the applications you're building and think about what 'smart' code really looks like in your day-to-day and if the people you're talking to are creating such code. I'd argue they aren't, and one of the problems is that part of you believes they are, so you're having trouble articulating why they should stop and why it's harmful.