This is one of my favorite sayings. It encapsulates the human condition – pleasure, desire, pain, survival – so efficiently. It’s a simple, great proverb for chefs and competitive athletes.
But is also a great proverb for anyone who is passionate about their work.
Let’s talk about what this means for coders.
When coders mention “bloated” code, we know immediately what they’re referring to. Code that attempts to do too many things, code that is verbose, code that has too many comments, code that is inefficient and not fun to work with.
When we talk about “clean” code, we’re talking about code we enjoy working with. We like code that is self-evident, descriptive and logical. Clean code is humane code, and since (almost) none of us make a living as 1-person coding phenoms, it’s extremely important.
In my mind, hungry code is the opposite of bloated code, with clean code falling in-between.
Hungry code wants to do more than just what it was originally written for. Hungry code anticipates being modified, re-used, referenced, branched, merged. To me, C++ templates are a good example of hungry code. Templates require you to think not just about the problem you’re trying to solve today, but the problems you’re going to solve tomorrow. You can write perfectly good, clean, non-extensible solutions to many problems, but the “hungry” version of the code will always win in the end. Code that is useful twice is code you don’t have to write again!
For our capstone project on web security, we must be hungry in order to succeed. Since my last post, node.js (which will be an integral component of our project) released patches for multiple medium-severity CVEs. The only way we will be able to be trustworthy researchers is if we are constantly reading, updating, searching, and asking the question – “what’s next?”
Hungry code requires a curious author. If “perfect is the enemy of good”, complacency is the enemy of hunger. Are you aware of both cutting-edge solutions and historical best practices for the problem you are trying to solve? Do you understand both the micro- and macro- processes at work in your system? We must constantly re-examine what we know, un-entrench our old practices and continually educate ourselves and those around us.
We won’t have the opportunity to be authorities on every topic, but we can ask “Why?” One example of this mindset I appreciate is the Python documentation for random.py. This documentation not only explains how it implements its functions, but why it chose specific solutions, and makes recommendations to the end user about when to use this library. I believe we owe it to our evolution to make this mindset the status quo.
So here’s a reminder to listen to your passion, to let yourself hungrily pursue truth, and embrace the journey it will lead you on.
“random — Generate pseudo-random numbers”, docs.python.org, accessed Jan 2022,
https://docs.python.org/3/library/random.html
English, Bryan, “January 10th 2022 Security Releases”, node.js.org, Jan 11, 2022,
https://nodejs.org/en/blog/vulnerability/jan-2022-security-releases/
