Your proudest code is your worst

The other day I sat down and worked really hard to solve a particular parsing problem. I used regex because I like a challenge, and when it works—it works beautifully.

var countableVerseRegex = /(^\n*|\n\n+)(({[Cc]omments?|#).*\n)*([^{# \n])/g,
    hasChordsRegex = /.*\[.*\].*/,
    chordlessTailRegex = /\][^\[\]]+$/,
    getChordRegex = /\[(.*?)\]/g,
    commentRegex = /^(\{ ?[Cc]omments?:|\#) *([^{}]*)}?/;

I finally got it working and was so happy and proud of myself.

Well done, you.

However, worming their way through cracks in my ecstasy, two quotes came to mind:

"You have a problem and you try to solve it with regular expressions. Now you have two problems."

"At the end of the day, take your 100 lines of code you are the most proud of, and throw them away."

Both of these are jokes—kind of. The point is that creating complex code is not only hard and time consuming for you, but also hard and time consuming for anyone who later comes to add/fix/give up and delete your code.

Sandy Metz values code on one thing: the cost of change. If your code is so simply laid out that even a grad student could jump in and make some adjustments, then your code has high value. If changing one section of your code only affects one section of your tests, your code has high value. The thing is, the code you are the most proud of is probably the most complex, the most fiddly, the most unintelligible. It took the longest time to write. By the time you finished, you're tempted to comment "https://hope I never have to touch this again". The rest of the world hopes that, too.

So write your code, do the fancy things, be proud of it, and at the end of the day have some serious thought on how to remove that fancy code, how to simplify things, and how to increase the value of your code.