Comfy programming: an idea
I want to give a name to an idea that isn’t earth shattering but that has been building within me for a long time. I call it “comfy programming.”
Us programmers are a strange lot. We’re either obsessing over new tools and architectures like a brand new pair of Jimmy Choo’s that are so shiny but that we know will be insanely uncomfortable, or we’re the grouchy old man saying “MYAHHH youngsters these days and their newfangled Kafkaesque distributed systems! Don’t want ’em, don’t need ’em! I’ve got Postgres/vim/ed/linseed oil.” We’re either in love with the shiny or we’re loudly talking down to everyone else yelling about how “you don’t need that.”
Let me start with the grouchy old man. Why are you so grouchy?
Well, the reason is simple. The more experienced you get, the more you can see through the BS and the closer you are to the only real truth in software development, which is that all software is bad. Whatever new silver bullet you’re touting today has probably been tried before in some other form and was discarded for the same reason that your silver bullet will be forgotten, it’s just that you’re too young/too inexperienced to know.
Underneath this assessment is a fear of pain. The pain of having to learn yet another technology that won’t amount to anything but another refactor. The pain of having to maintain a new system, more complicated than the one that preceded it, without any real payoff. And the pain of having to groan “I told you so” to another generation of programmers.
What if instead of fearing that pain, we decided to address it and adopt it as the focus of our programming efforts? What if instead of optimizing for speed, elegance, or organizational sustainability, we optimized first and foremost for comfort?
What if we learned comfy programming?
The idea isn’t entirely new. Since Fortran, programmers have been trying to attain that elusive goal we call “elegance,” which brings a certain satisfaction. It’s the same satisfaction that you feel when you depress a really good button or when you see a perfectly alphabetized shelf, or any of these things. Elegance can clearly lead to comfort.
Yet elegance isn’t always the same as comfort. The problem is that comfort in programming depends on many factors, not always technical. How easy is it in your organization to commit code to your master branch? When you start working on a new feature, are you also bombarded with a thousand requests from management? Can you edit text at the speed of thought?
Here’s my rough, provisional definition of comfy programming:
A holistic approach to programming that optimizes for minimizing the amount of friction involved in moving from having a thought to implementing that thought in production code.
We can think about this approach in terms of a comfort toolchain. From the keyboard to the continuous deployment platform, we need to consider what makes a programmer’s life as easy as possible.
Well-funded startups have been doing this for years in terms of external factors. For example, at my wife’s startup, new (engineering?) employees are given a $10,000 budget to configure their desk however they want. There’s a full-time culinary staff that prepares out of this world meals, and generally life is good. No need to worry about paying the bills, either.
But what about the policies within an organization? What about the organization of your codebase? Your selection of architecture, language, and tooling? Can we move beyond griping about PM’s and “ugly code” and toward a science of what it means to program comfortably? And how do smaller startups with less cash to throw on fancy dinners accomplish these goals?
Answering all these questions is precisely what I’m trying to do at Trove. I want to make our process as comfortable for developers as possible. Fortunately, I have the best guinea pig possible for these experiments: myself!
