It's interesting as analogies go, but the real problem is that eating is inevitable. You will eat eventually and consistently. But with code there is no guarantee you will ever ship. There are many programmers whose quest for perfection almost completely prevents shipping. On the other hand an obsession with eating the best food is not nearly so crippling; it is more unilaterally beneficial despite whatever flaws or inconveniences it may cause (road trips, wrong definition, etc).

I have found finding the balance between quality and actually shipping to be one of the most challenging aspects of being a good developer. Sometimes "good enough" really is, and other times it really isn't. Distinguishing between the two (and all the gray in between) takes experience.

I think they are orthogonal issues. For any code base there are a list of things most in need of improvement and a quality threshold to be able to ship. It's all to easy to spend a lot of time making unimportant things better, but the problem is not trying to make great code it's working on the wrong area. If the messaging system sucks and there is no GUI then build a GUI.

Indeed. There are few things as satisfying in the craft of programming as discovering some code that you wrote years ago which foresaw conditions that didn't exist then but do now. Deleting ugly code which did the job but is now unnecessary is a close second.

Another way code quality is like food: There's no point in trying to optimize your diet if something else is going to kill you first.

This is an interesting analogy, for me, it doesn't map though. I "believe", if you'll let me use that word, in code quality, so my attitude towards code quality is constant. I moved past the urge to knock out quick and crappy solutions as soon as I shifted my enjoyment from "getting a solution" to "getting the best solution I am capable of". That is, simply solving a problem doesn't feel good, I have to solve it as well as I can to get anything out of it.

This has to be one of the most self indulgent article I've read in months. I enjoy the philosophical bits of programming as much the next guy but when did everything become an analogy for writing code? Bad programming is like McDonald's? This article is like White Castle: unhealthy and unsatisfying.

I'm normally not the type of person to dis articles, but I just read nearly 900 words and learned nothing. The tl;dr is obvious to any professional programmer: there are short-term costs but long-term rewards to code maintainability. Unfortunately, he doesn't argue this point at all (I want to see data or an least an anecdote), or even tell what is healthy code. Instead, he opts for an extended analogy to a factually questionable "healthy eating continuum".

Cook very large quantities of food so you can have leftovers later == shaky analogy for code reuse?

Hacking is like painting. Hacking is like eating. Is painting like eating too?

Approximation can't really be transitive. Otherwise, $1 is "like" $1.01 which is "like" $1.02 ... which is "like" $100,000,000 ;)

Maybe we could allow the quality of the approximation to degrade: if 'hacking is like painting' and 'hacking is like eating' are ||hacking - painting|| < \eps and ||hacking - eating|| < \eps respectively, then ||painting - eating|| < 2 \eps. So painting is at least half as like eating as painting is like hacking.

It may or may not be. It's not false but neither is it true. Strictly logically speaking.

And in a sense both can be considered as different pleasures - eating derives joy from taste and painting derives joy from fine craftsmanship.