Is Code an Asset or a Liability?

The hosts of the Crafting Code podcast raise an interesting question on an episode about deleting code: is code an asset or a liability?

It’s a good question to consider, since most of us think we make something better — from a recipe to a piece of art — by adding to it, rather than subtracting from it.

Additions have a cost, as the trio of hosts on this episode point out. “[Software] gets more and more complex as you add things to it,” they explain.

They’ve got a point.

Say you added a bunch of conditionals to address all the edge cases in a problem. The program works, but at what cost? Can anyone else follow logic? Can you? This is a case where deleting code can likely save the day, and simplify a solution that’s unnecessarily lengthy and complex.

It’s a point that’s made clear by Michelangelo’s attitude towards sculpting. “The sculpture is already complete within the marble block, before I start my work,” the legendary artist explains. “It is already there, I just have to chisel away the superfluous material.” Likewise, there are times that we need to “chisel away” at our code to unearth its true intent and functionality.

But before you start hitting the backspace button, let’s consider the flip side: deleting too much code. Although this podcast episode emphasizes deleting code, it does recognize that it’s possible to have too little code. “And that’s not good either,” says one of the hosts. While verbose code can be unwieldy and complex, deleting too much may result in terse code, which is often hard to read and understand.

Although you have bragging rights for squishing everything onto a single line. Will your teammates know what your un-named or one-letter variable names represent? Will you remember a week or month later when you’re digging through the code trying to debug it?

Sometimes adding code, like a clear and meaningful variable name, will make the program easier for the reader to understand and potentially debug.

So instead of asking yourself: “what can I delete?”, I prefer the question: “is this code valuable?” Because if a line of code isn’t valuable, it’s gone. And, to me, valuable code is an asset.

Is this Code Valuable?

Let’s unpack what valuable code is. For me, valuable code means two things: it’s working code that’s being used within the program and it’s clear and meaningful.

First and foremost, valuable code is working code that’s being used within the program. For example, the function sum_two_nums sums two numbers and the output of this function is being used elsewhere in the program. This function meets the first part of my valuable-code definition.

That means dead code should be deleted. So should code that’s been commented out: waiting for some future use or code that you feel a personal attachment to. The hosts of the podcast also suggest deleting such types of code.

Now let’s reconsider the example from the start of this blog post: a program that contains tons of conditionals. Does this code pass the “valuable” test? After all, the program does work and its results are used elsewhere in the program.

In my opinion: this code does not pass the second part of my valuable code definition. That’s because valuable code is also clear and meaningful. Clear and meaningful code is readable and understandable. It’s the easiest for the reader to understand, and oftentimes that reader is our future self.

A function can work and be used in the program. But if it’s a nightmare to read and understand, then it’s not valuable. Rather, it’s very taxing on the reader. Likewise, using an unhealthy number of conditionals can make a program unnecessarily complex and hard to read. This isn’t valuable, so the code should be re-written.

So if you’re muscling through a program, then that’s usually a sign that the code could be written better, more clearly. Sometimes writing more clearly means deleting code. But sometimes it means adding to it.

The way to write valuable code requires a shift in mindset.

A Shift in Mindset

Any writer of prose will tell you that the writing is in the editing. I spend far more time editing my articles than I do writing them.

The same is true in the code that I write. I spend a lot of time editing my code, from trying multiple solutions to renaming functions and variables. It’s through the editing process that I really understand what I’m trying to do, why I’m doing it, and the best way to go about it.

That’s why as writers of code, we’re also editors. We need to see ourselves that way. This is the path towards writing valuable code. If the code isn’t valuable, then our job isn’t complete; there’s still work to do.

A way to stress-test clear and meaningful code is to be empathetic. Put yourself in the shoes of another developer who’s tasked with reading your code right now and has no context.

Would the program work? Could the programmer read and understand it? Would they be able to readily modify or extend what you’ve written? Or would they struggle unnecessarily trying to figure it out?

As editors of code, we need to constantly work and re-work our solution and the process that brought us to it. Rarely is the first solution the best one. Just like the first draft of an article usually ends up in the trash. We need to question our code and think about it from different perspectives in order to come up with different — and often better — solutions.

When we look at our work with an editor’s eye, then we’ll be more thoughtful about our code selection, which will bring us closer to writing valuable code. And valuable code is definitely an asset.

Programmer and writer: amymhaddad.com | programmerspyramid.com | I tweet about programming, learning, and productivity @amymhaddad

Originally published on amymhaddad.com.