Code Is Not The Goal
If there’s one thing I’ve learned in recent months and that I’m actively trying to internalize, it is this: code is not the goal. It never is.
As programmers, we tend to get so caught up in the act of churning out code that we sometimes lose sight of the purpose of it all.
The purpose of software is to help people. And code, the building blocks of software, should be geared toward that purpose. (Unless we are explicitly coding for the sake of coding.)
The focus should be on solving problems. And if it can be done without (new) code, all the more better.
Jeff Atwood touches upon this idea in his post Please don’t learn to code criticizing the “everyone should learn to code” movement:
“It (the movement) assumes that coding is the goal. Software developers tend to be software addicts who think their job is to write code. But it’s not. Their job is to solve problems. Don’t celebrate the creation of code, celebrate the creation of solutions. We have way too many coders addicted to doing just one more line of code already.”
So, in that sense: Code is the last resort.
We should only create more when we have run out of all options because the best code is no code at all:
“Every new line of code you willingly bring into the world is code that has to be debugged, code that has to be read and understood, code that has to be supported. Every time you write new code, you should do so reluctantly, under duress, because you completely exhausted all your other options. Code is only our enemy because there are so many of us programmers writing so damn much of it.”
The professional programmer
It is even more important to see the bigger picture — beyond code — when you’re doing it professionally. Remember this: you are not paid to write code.
“You have never been paid to write code. In fact, code is a nasty byproduct of being a software engineer.”
Don’t call yourself a programmer and other career advice hammers home the point even more emphatically:
“Producing beautiful software is not a goal. Solving complex technical problems is not a goal. Writing bug-free code is not a goal. Using sexy programming languages is not a goal. Add revenue. Reduce costs. Those are your only goals.”
This mindset is even more paramount at Startups because you’re expected to move fast and break things.
In the hardest lessons for a startup to learn, Paul Graham lists out some lessons Startups need to learn. Among the first three are:
i) Release Early
ii) Keep pumping out features
iii) Make users happy
And well, getting too caught up in the beauty and intricacies of code can distract one from all three. And that is a recipe for disaster. Again, code is not the goal!
Summing it up
All this is not meant to be a license to write sloppy, unmaintainable, or even “clever” code. It simply means that when we are typing away at our keyboards, it is essential we intermittently remind ourselves that what’s on the screen is not the end itself, it is just a means to an end.
—
End-notes and references:
I’m pretty new to all this and am constantly learning and updating how I see things. So, this article (adapted from a Quora answer of mine) is an attempt to sort out my own thoughts on the topic. Anyway, I highly recommend going through all these interesting write-ups. At worst, they can be interesting food for thought, at best they can be fascinating eye-openers.
[2] Please don’t learn to code
[4] The best code is no code at all
[5] You are not paid to write code
[6] Don’t call yourself a programmer and other career advice
Zerone is an undergrad publication at I.O.E, Pulchowk focusing on People (their creative side, their thoughts, their lives) and Technology (the new, the old, everything).
Follow us for more articles, stories, poems and other cool writings.
