I'm Too Clever
Musings on some (correct) PR feedback I received.

The title really says it all here, and I honestly, truly take no pleasure in admitting it, but…

I’m too clever.

I initially received this feedback after submitting a PR at work, but I had already admitted it to myself before asking for a code review. I had scoped out a performance optimization that I wanted to tackle and identified it as being low-hanging fruit, but in reality it turned out the problem was much larger and more far-reaching than I had anticipated (when is it not?).

I wrote a very clever piece of code to cover the original issue, the edge cases, and everything in between… But the problem was that without extensive code comments and documentation that would eventually get out of date, I knew that the average developer reading my code would fail to understand what was going on in a reasonable amount of time. This code was concise, elegant, and all the other developer buzzwords – all right up until the next developer inherited my work.

So I submitted the PR, self-identified myself as “too clever”, and requested a code review. Of course, the team decided to reject my changes as “too complex”.

I don’t blame them. They were right.

I wish this had been a one-off issue. Looking back, I can see myself making this same mistake over and over. I’m not really sure how to break out of this loop, actually. This post isn’t really meant to be advice on how to not be clever, more just a reflection on how I am today.

If, for some reason, you’d like to be clever like me:

• Specialize deeply – that way no one else really knows what you’re doing.
• Use esoteric language features extensively, and assume everyone knows as much or more than you do about them.
  • For me, this is Ruby metaprogramming features.
• Code golf wherever possible.
  • Lowest character count > code readability.
• Abstract away everything, especially when it makes it harder to reason about what the code does under the hood.
  • Inverse (and occasionally equally evil): Apply the minimal changeset required for desired functionality.
  • Bonus points: Apply these rules indiscriminately and at random.
• Write confusing tests – just apply all the rules above to tests, as well!
• Secret Sauce: After following all the above rules, prioritize the first working solution above all else. Refactor sparingly and with great restraint.

Obviously, this post is meant to be slightly humorous. What really hurts, though, is that I can look back to posts I’ve made on this very blog that demonstrate directly the issues I’m talking about.

On the other hand, posts like these are incredibly beneficial for my self-growth. I’ve been working as a developer for almost 5 years now, so I can only hope I’ll sustain the level of growth in the next 5 years as the first.

That’s all for now. Thanks for reading!