Loving / Hating The Code

"The less lines of code I have, the easier I'll be able to modify them without breaking anything. Wouldn't it be even better if I had no line of code at all?"

A fellow coder asked the question above during a discussion about the virtues of simplicity. He was upset by others justifying the use of programming language X over programming language Y by how much it helps to write concise and simple code. (Lesson learned: don't put values on pedestals, don't argue in public on which language is best -- if you don't upset your interlocutor, chances are great that you and them will upset third parties.)

Despite the tongue-in-cheek aspect of the question above, I suspect it reveals some truth about the attitude we coders hold toward our code. We see the success of a software project both as a motivation (justification?) for our current work, and we project in that future success our own to come -- rewards, recognition, promotion, etc. In this relation of desire between us (the subject) and success (the object), the software code stands like a mediator, the thing that allows -- or prevent -- the subject to access the desired object. We personify the code we write and we make it endorse what should be our own responsibilities : "it's not my fault if it's not working... it's the bugs in the code / it's because it's C++ / it works fine on my computer / it was working fine yesterday / etc." Our feelings towards the code/mediator varies according to circumstances from veneration to blame, from fascination to fear.

Our code doesn't rule our lifes, our reactions to the frustrations we experience do. When we realize we don't master the code's behavior, these reactions we should tame first, not the code itself.

I'm hoping for a change in the attitude we hold toward our work. A new mindset in which we don't personify the code anymore, but objectify it instead as a vector of change -- an opportunity to create value, with all the risks of impredictibility and chaos attached to it. What's at stake then isn't so much the number of lines of code one "should" write, but the compromise to find between the value one hopes to generate and the risks of losing control one induces at the same time.