Do you know that feeling when you just need to show off that new trick with Expressions or generalize three different procedures? This does not have to be on Architecture Astronaut scale and in fact may be helpful but I can't help but notice someone else would implement the same class or package in a more clear, straightforward (and sometimes boring) manner.

I noticed I often design programs by oversolving the problem, sometimes deliberately and sometimes out of boredom. In either case, I usually honestly believe my solution is crystal clear and elegant, until I see evidence to the contrary but it's usually too late. There is also a part of me that prefers undocumented assumptions to code duplication, and cleverness to simplicity.


  What can I do to resist the urge to write “cleverish” code and when should the bell ring that I am Doing It Wrong?


The problem is getting even more pushing as I'm now working with a team of experienced developers, and sometimes my attempts at writing smart code seem foolish even to myself after time dispels the illusion of elegance.


  The problem is getting even more pushing as I'm now working with a team of experienced developers, and sometimes my attempts at writing smart code seem foolish even to myself after time dispels the illusion of elegance.


Your solution lies here.  I'm presuming that "experienced" in this context means "more experienced than you."  At the very least, you clearly respect them.  This is a valuable learning opportunity -- assuming your ego can take the hit.  (Irksome things, egos.  A pity we need them so.)

Do you have code reviews with these folks?  If so, if they're not doing it already, explicitly ask them to call you on your bullshit.  Mention that you've noticed a tendency in yourself to overdesign, to use a meticulously designed top-of-the-line pneumatic jackhammer (preferably wielded by some sort of automated road-worker android) when a simple claw hammer would be more than sufficient.

You may often find yourself squirming in your seat while your face turns red during the code reviews.  Endure it.  You're learning.

Then, once you've got a few of these under your belt, pay attention to the moments where you suspect you're maybe possibly overdesigning.  When those moments come, ask yourself:  "If somebody calls me out on this during code review, can I defend my solution as the best one available?  Or is there a simpler solution I'm forsaking?"

Sometimes, peer review is the best way to get a good look at your own work.
