Previous Entry Share Next Entry
Programming as the art of sacrificing your children
device
jducoeur
Today's project is one of those really painful ones, but illustrative of a key point about software engineering: you have to always be prepared to throw your brainchildren on the pyre of better code.

Suffice it to say, I spent all of last week developing a new feature for Querki called "User Values" -- the ability for a Thing to have a different value for each User. (Which we're going to use for things like Reviews.) The code was hairy and ornate, and by Friday I was tearing my hair out over the complex interactions between it and some other features, especially Model Types.

And then, Sunday morning, I woke up with the horrible epiphany that I'd done it all wrong -- that I'd made a decision early on, that seemed to make sense at the time, but had made the problem ten times harder than it needed to be.

So this morning consisted of disentangling all of that ornate new code, putting lots of things back to where they were, and (the inspiration for this post) simply deleting the complex new class that was at the heart of it all. I've replaced it with an alternate design that is slightly less "magical" at the UI level (you need a few more manual steps, instead of the system DWIMming quite so much), but is semantically cleaner and *vastly* more robust. All the things that were so hard to do previously turn out to simply work correctly with no code changes in the new design.

The point is an important one, and it's one of the common differences between junior and senior programmers: you have to learn to get your ego out of your code. Yes, you spent a ton of time on that; yes, the design might be a thing of beauty. Doesn't matter: it's sunk time, and no longer relevant. If it isn't what you actually need in the code base, just kill it and move on. It'll be better for the program in the long run...

  • 1
"Kill your darlings" is an incredibly difficult lesson for any creative endeavor, but an absolutely essential one for maximizing quality. I have agonized over such decisions myself!

Yaas. I suppose it underscores the often-misunderstood point that coding *is* a creative endeavor. Most people assume that the "engineering" part of "software engineering" means that it's all just mathematical, but I find the art of coding very much like that of writing, in many ways...

I have that problem in writing too. This sentence/paragraph/chapter is wonderful. But it doesn't fit the narrative now. *sigh*

Sunk Cost Fallacy. Integral to human nature regardless of discipline.

And yes, the temptation to go 'But I can make *this* work!' is big, isn't it?

I think the real difference here between the senior and the junior programmer is that the senior programmer is so steeped in the craft that the subconscious can continue to churn until the senior programmer -has- the epiphany. The junior programmer never has that moment, so never sees any way but the hill they've already chosen to die on.

  • 1
?

Log in

No account? Create an account