Sam Altman once said: “Minimize your own cognitive load from distracting things that don’t really matter. It’s hard to overstate how important this is, and how bad most are at it. Get rid of distractions in your life. Develop very strong ways to avoid letting crap pile up.”
In programming, there is a technique called “dependency injection.” It’s a way of worrying, up front, about how to split the modules in your program from other code. You aim to give yourself the future benefit of being able to swap out a module dependency later.
In some communities, this little technique led to a temporary fad of constructing programs within a baroque superstructure via “dependency injection frameworks,” sometimes called “inversion of control frameworks.” With these, programmers fretted about a future that usually never arrived, and their worries expressed themselves as defensive code, all in the name of future-proofing. This meant in addition to spending time adopting a dependency, they also had a meta-distraction: working that dependency into their “management framework,” alongside the others. This sort of thing took some programmers very far away from the core “essential complexity” at the heart of their code.1
Dependencies seem to be all around us, both in the real world, and in programming. And they are perniciously distracting in just this way. Have you ever noticed how rare it is for you to just do something?
If so, you might have been worrying, up front, about dependencies.2
In the back of your mind, you wonder: has this been solved? The world is full of solutions in search of problems, and the internet is always nearby. You convince yourself to research if some of these happen to apply to your problem.
Even if you don’t find something off-the-shelf, you still might think to yourself: I could just do this, but is this a good use of my time? Lacking a ready-made solution, you then turn to delegation: whom shall I ask to solve this? After all, the market usually obliges with eager participants willing to sell their labor for a price.
But whether your proposed solution is an object or a person (and whether it is free or paid), there’s one thing it always is: a dependency.
John Cleese once said: “It’s easier to do trivial things that are urgent than to do important things that are not urgent. It’s also easier to do little things we know we can do… than to start on big things we’re not so sure about.”
Is programming about code re-use? After all, that is what day-to-day computing is all about. When we run a program, we re-use code someone else has written. This extends to when we use a service over the web, or when the programmers behind that service use cloud computing to run their workloads and servers. It is thus no surprise that a creative programmer, today, spends a good deal of time reasoning about which code to re-use (and how, precisely, to re-use it). Sometimes, they spend more on that than they do on writing original code.
But, consider writing. Is it about text re-use? Or concept re-mixing? Or is writing, truly good writing, somehow about new insight creation?
Some in the tech industry might claim a majority of programmers spend a majority of their time wiring together existing code. What’s the harm in helping this process along? And, indeed, this re-mixing of originality is spreading outside of the craft of programming, and very rapidly — into areas of text (prose), images (art), and video (film) with the rise of generative AI.3
But whether your proposed re-use comes from an object or a person (and whether it is free or paid), there’s one thing it always is: a dependency.
Here’s the thing: creativity isn’t just about piecing together dependencies.
That’s not to say that people haven’t been creative in doing so — of course, they have. But, there is a way in which the world today feels very derivative. We sometimes marvel at the originality of these new works, and especially at the sheer speed of output. But many of us have this nagging feeling of something being lost in this flourishing of a derivative kind of productivity.
We can sense, deep down, that the ingenuity of a tool is no substitute for our human ingenuity.
We also know, with certainty, that the value of a tool is never a guarantee of the value of its output.
Thanks to our gift of birth, our human intellect, and aided by a sturdy educational and technological foundation, in some domains we are as gods who can will-to-creation these things-of-value from pure-thought-stuff. But I wonder whether some of us have been conditioned into being too frightened to even try.
Let us cast aside the question, perhaps the empty question, of who (or what) deserves credit for some artifact. My main point is that there are ways in which we distract ourselves (and diffract our efforts) when we set our sights so low as to be just above the horizon of today’s tools.
We can sense it, too — this is often the moment at which a given dependency feels “heavyweight” and runs the risk of snaring us in a self-defeating maze, falsely giving us a sense of progress while maddeningly taking us farther from our goal.
Reflecting on how to create a space for creativity, John Cleese went on to say: “You can’t become playful (and therefore creative) if you’re under your usual pressures. […] You have to create some space for yourself away from those demands. And that means sealing yourself off. You must make a quiet space for yourself where you will be undisturbed. […] When I say: ‘create an oasis of quiet’ … know that when you have, your mind will pretty soon start racing again.”
I find this idea quite calming. Reading it, I feel the urge to create — not merely to go through the motions, not merely to surround myself with the impressive output of carefully-chosen dependencies.
Let us consider one particular open source project and its creator, Redis and Salvatore Sanfilippo (aka antirez). Redis is one of the world’s most popular “in-memory databases,” a piece of server infrastructure used by programmers for any number of important tasks, such as the caching, ranking, and indexing of data. Redis is written in C, a language that doesn’t even have a dependency manager. This was also the language used to develop DOOM, in a world before 3D game engines.4
Redis has very few formal dependencies. Thus all the data structures, internals, and commands are implemented from scratch. Which is to say: designed from first principles.
By having a simple wire protocol for how clients talk to the Redis server, the open source community is free to innovate around that wire protocol, and innovate it has, with an implementation in pretty much every programming language. This creates clarity around what, exactly, Redis is: it’s a program that acts as a network server that implements this wire protocol, so that clients can stick data into Redis and get data back out of it.
When antirez used to sit down to write a feature, he knew exactly what tools he would use. That is: the C programming language, his background in programming and computer science, his knowledge of operating systems, his design instincts. He didn’t need to pull in much else, and he never had to worry much about making sure his code “fit in” with the millions (billions? trillions?) of lines of open source code already written in undoubtedly “relevant” areas.
He once implemented a complex algorithm called “HyperLogLog” in precisely this fashion, and it resulted not only in a novel implementation, but also in an insightful technical blog post. Most programmers would have attempted to embed or extend an existing implementation, since there are hundreds of such implementations floating around on the internet, including under liberal open source licenses. But antirez just studied the algorithm itself, ran some of his own tests and experiments, and wrote a unique contribution that made sense for Redis, while sharing his results with the world.
This minimalist setup gave him a very focused way to ship new stuff. And he used that for more than a decade to great effect. In the last few years, he’s taking a break from programming to write sci-fi novels. But throughout his creative life, he has rarely carried the baggage of anyone else’s past contributions.
Through this example of antirez and Redis, we can reflect a bit and widen our view. There is something pathological about trying to constantly fit together all your upcoming contributions into someone else’s (or, the world’s) past contributions. Whether in your code, in your writing, or in any other pursuit. The goal, after all, is to make a novel contribution. To do this, you don’t need better dependencies. No — to create something new, you need to reject your dependencies! Even if only temporarily. You need to operate from a “sealed-off” place of constraint and focus.
I think of the billboard advertisement that once provocatively stated, in large and bold type:
“YESTERDAY YOU SAID TOMORROW”
Then, in small print at the bottom of the billboard was the company’s slogan and admonition:
“Just do it.”
Because even the future can be a dependency, clinging you ceaselessly to the past.
The next time you strive to create something truly new, try dependency rejection for a change. It’s amazing how fast you can move when you trust your instincts and pack light.
- I once wrote about “Inversion of Control” (and other developer practices du jour) as a sort of cargo cult. This particular practice is part of the same universe of jargon and techniques that surrounds “dependency injection.” ↩
- This essay isn’t just about programming, though it is the craft of programming that got me thinking about the role of dependencies in everything I do. ↩
- If some texts, images, and videos are not merely “content” but are instead prose, art, or film, respectively, I ponder whether this is also true of code. That is, do we lack the right word to describe some of our code not merely as “machine instructions,” but instead as output from an artistic-creative process? ↩
- I am not making a specific argument for the C programming language in this essay. But there is something quite interesting about just how much of my favorite software is written in C. A short list: Redis, Python, SQLite, PostgreSQL, Linux, git, and nginx. And then, within the Python community, many of the most widely-used modules have significant portions implemented via the Python C API. It’s not just about performance. I think there is something about the C language’s rejection of dependencies that allows its wielders to create some of our most timeless and most widely-used software. This is one of the reasons I enjoy the Zig community as of late. It inherits this philosophy from the C community. ↩
Acknowledgements —
The idea for this essay came from reflections on how one of my friends approaches his own creativity. He also provided some very useful suggestions and edits to an early draft of this essay — thanks, Rom.
The photos embedded in this post come from a brochure for a specific pen I bought while in Japan, the Sakura Craft Lab 004. I really enjoyed how they described the design of their pen, and it is in line with some of the thinking in this post:
“By avoiding excessive decoration and pursuing a simple design, we have created a form that will become your partner. The central knob is pleasant to the touch and reminiscent of antique items. If you turn it, it’s a ballpoint pen, and if you press it, it’s a mechanical pencil. A simplicity that eliminates waste. What is important? What do you need? This is where a new relationship between the author and the pen is born, especially in today’s age of information overload.”
I edited a printed copy of this post with the red ink from this pen. I wrote the original post on macOS using iA Writer, with the text stored in Markdown format. To quickly apply the red ink edits and improve formatting, I used vim — with the help of the Livedown and Goyo plugins — on Linux. I shared a draft with friends using a “public preview” plug-in and then I published the final draft to the wider internet via WordPress.
But do any of those details really matter? I wrote an essay, and I tried to say something new. Now, you’ve read it, and you can go off and make something new!
Reminds me of this great Gertrude Stein quote: “It takes a lot of time to be a genius. You have to sit around so much, doing nothing, really doing nothing.”
This is a thoughtful essay. I’ve found it helpful to reject dependencies in my personal coding projects, but this essay is about more than rejecting code dependencies.
The main theme seems to be creativity/originality by rejecting a large chunk of past attempts (although not all of it, as you pointed out with antirez’s usage of C and his knowledge of computer science).
I do wonder about your statement that “there is a way in which the world today feels very derivative” though. That sounds odd to me because many classical celebrated works are derivative of something that came before. (I would say it is the rule rather than the exception.)
Of course you point this out when saying that people have often been creative in piecing together dependencies, but I’m left wondering if you also would have thought the past would have felt just as derivative too because you mention “the world today feels very derivative” (wasn’t the past just as derivative or even more so?).
One relevant excerpt from a book that influences my own view on creativity (R.G. Collingwood’s “The Principles of Art”) is linked here, and you might enjoy reading it too.
I would have preferred to link another section (under the heading “Collaboration between Artists”, available here), but it’s a bit longer, and I don’t know if you’ll find it interesting to read an opposing view.
@Humza, well-stated comment, and I enjoyed the citations. I read them with interest! The tension in my essay, versus your comment, is between the concept of creativity and of originality. I was aiming my essay more at creativity and particularly how to spark the creative mood (by rejecting dependencies). As for originality, I think I largely agree with your assessment on that!