mushinnoshin

A nugget of common wisdom in the world of computer programming speaks to the division of programmers into two basic categories (we do like things in binary…) — those who code because they love it, live it, and would be doing it even without the paycheck, and those who do it because someone told them it was good way to make a living. The former are generally considered the good ones, though I suspect management may recognize how the latter may have their uses.

I find myself somewhere in between, being a person who lived it and loved it until he was about 13 or 14 or so, a bit of a programmer prodigy — right up until I discovered the things that would really drive my life: music, literature, philosophy, film, politics, and parties — not necessarily in that order. I only came *back* to programming when I finally resigned myself to the need to make a living.

So, yeah, I’ve got more natural skills and code with more artistry than the latter, but have to bow before the former (which would include all my colleagues). This of course is why you almost never read tech posts from me. And yet why you will get this occasional one as I pat myself on the back.

OK, see, I’m in a position that’s actually probably perfectly suited for my particular point in the aforementioned spectrum. I started out here working as a maintenance programmer on some old code from the 90s. And while we have been working to replace that system with a modern architecture, we find we run up against its limitations more quickly than we can realistically port it to the new environment. And so at some point my job changed from *maintaining* the old code, to *transforming* it — rebuilding in place, creating a brand new system on top of the old data & schema, to solve the problems of today that can’t wait for the potential of tomorrow. As I paraphrased the other day to Cory, I liken my job often to that of a modern artist making sculptures out of garbage found in a landfill.

Anyway I’m just posting to rejoice in having finally solved a particular problem that’s plagued us from the beginning. See, the people who wrote the old code for some reason got it in their heads that a user would surely *never* change their email address, and pretty much built the entire system around the idea that an email address was the primary identifier — they made email address the primary key of the users table, and made it the link to just about every other table there is.

Raise your hand if you’ve only ever had one email address. What, no one? Well then, you see our problem.

It’s a problem that I’ve been thinking about for going on three years and which finally bubbled up to the top of my priority list this week. And after building and trashing a few different hacked-on schemes to add an email address table attached to the user, all of which had numerous ugly complications when it came to account logins, maintaining continuity, preventing hijacking, and a whole host of other issues — on Friday it came to me and I hacked out most of it in an exciting flash that hearkened back to those early days as a pre-teen teaching himself assembler.

It was so simple it was stupid. All I had to do was take a step back and redefine my terms. Create a new “superuser” table and store the superuser id as a foreign key in users. My “superuser” becomes what would be a user in a smarter system, and my current “users” table become the equivalent of an “email addresses” table. Everything works exactly as it has for probably 10 years or so, and when someidiot@yahoo.com wants to become someidiot@gmail.com, they do so exactly as we’ve always done, creating a brand new “user”. *I* know that both “users” are the same superuser, even if legacy code and the user-order-item cascade doesn’t — and my soon to be redesigned account manager program will only care about superusers.

Elegant and minimally invasive, yet turns the entire platform’s assumptions on it’s head and solves one of the biggest thorns in our side in about two days worth of coding. Maybe I’m still a real geek after all.