6 ms·

The Hungry Programmer

67 points by bradly 15y ago

dasil003 15y ago
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).
- city41 15y ago
  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.
  - Retric 15y ago
    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.
  - dasil003 15y ago
    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.
TheSOB88 15y ago
Hacking is like painting. Hacking is like eating. Is painting like eating too?
- deleted 15y ago
  [deleted]
- _Y_ 15y ago
  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.
- tikhonj 15y ago
  Approximation can't really be transitive. Otherwise, $1 is "like" $1.01 which is "like" $1.02 ... which is "like" $100,000,000 ;)
  - shoo 15y ago
    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.
laconian 15y ago
Cook very large quantities of food so you can have leftovers later == shaky analogy for code reuse?
richardk 15y ago
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.
ericwright90 15y ago
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.
usaar333 15y ago
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".
shalmanese 15y ago
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.

67 points by bradly 15y ago

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).

city41 15y ago
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.
- Retric 15y ago
  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.
- dasil003 15y ago
  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.

TheSOB88 15y ago

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

deleted 15y ago
[deleted]
_Y_ 15y ago
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.
tikhonj 15y ago
Approximation can't really be transitive. Otherwise, $1 is "like" $1.01 which is "like" $1.02 ... which is "like" $100,000,000 ;)
- shoo 15y ago
  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.

laconian 15y ago

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

richardk 15y ago

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.

ericwright90 15y ago

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.

usaar333 15y ago

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".

shalmanese 15y ago

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.