<script>
$(document).ready(function(){
    jQuery.extend(jQuery.expr[':'], {
      containsIgnoreCase:
        "(a.textContent||a.innerText||jQuery(a).text()||'').toLowerCase().indexOf((m[3]||'').toLowerCase())>=0"
    });
    $('input.filterer').keyup(function(){
        $('#'+$(this).attr('target_id')+' option').show().not(':containsIgnoreCase('+$(this).val()+')').hide()
    });
});
</script>
<input class="filterer" target_id="target_select_id" type="text"/>

But then IE made me do:

<script>
$(document).ready(function(){
    jQuery.extend(jQuery.expr[':'], {
      containsIgnoreCase:
        "(a.textContent||a.innerText||jQuery(a).text()||'').toLowerCase().indexOf((m[3]||'').toLowerCase())>=0"
    });
    $('input.filterer').each(function(){
        $('<select id="'+$(this).attr('target_id')+'_stash" style="display:none;" />')
            .insertBefore($('#'+$(this).attr('target_id')));
    });
    $('input.filterer').keyup(function(){
	var visible_select = '#'+$(this).attr('target_id');
	var hidden_select = visible_select+'_stash';
	var needle = $(this).val();
	$(visible_select+' option').not(':containsIgnoreCase('+needle+')').remove()
            .appendTo($(hidden_select)).removeAttr('selected');
	$(hidden_select+' option:containsIgnoreCase('+needle+')').remove()
            .appendTo($(visible_select)).removeAttr('selected');
    });
});
</script>
<input class="filterer" target_id="target_select_id" type="text"/>

But that was my last step in my trail of Chandler faith. As soon as Chandler Desktop booted up, I was greeted with a soft, warm and fuzzy python exception: “Hey! This function receives one argument, you gave it two!”. Never good.

Tried to report the bug. Need a login for some bugzilla somewhere. Hmm, guess I’ll pass.

And don’t think that I am saying that there is no place for optimization, that is not true, there is just less room for optimization in the source itself, but there is lots of room for optimizations in terms of overall system performance and in terms of developer productivity. It is more important to focus on the big picture and solve performance problems that are system wide, or refactor code so that changes can be made much faster, than it is to solve a performance problem in a single line of code…unless of course that line of code is being called 8 million times by 50 parts of the system.

So next time you go to write a super clever line of code, think to yourself “Will the benefits of this super cleverness be outweighed by the future issues in maintaining and understanding the code?” And if there is any hesitation at all, then you better not be clever, because 3 months from now you will come across that code and say “What the hell was I thinking?” Then you’ll end up rewriting it anyway.

It’s quite correct, except for one little detail: “Then you’ll end up rewriting it anyway”.

I wish! Doing it right the first time is the good solution, but rewriting it when you latter come across it and realise it’s stupid is a “not good, not bad” solution. The problem is when you just can’t rewrite that piece of crap! Maybe you can’t test it, maybe you have something more important to do, maybe you don’t really understand it, maybe maybe maybe…

I could segway this into the perfect TDD and “Tests as a living, runnable spec” pitch, but I’ll let it rest.