Many people believe that computer programming is about 0s and 1s. Fun idea, but not very useful. When you’re actually building software—especially on a phone, where every feature has to earn its place—the numbers that matter are 0, 1, and many. This simple rule can save you time, reduce bugs, and keep your project from turning into a maze of special cases.
Sure, the most efficient code is the code you never write (the trivial case). But when doing nothing doesn’t solve the problem, you have do a thing. You know, just one thing. So you keep it simple. You hack it into place and it’s just good enough to meet the need. One, the smallest possible solution. No frameworks, no abstractions, no grand architecture. Just the smallest solution that works. That’s not laziness. It’s efficiency and discipline.
But after you’ve experienced the joy of doing something once, you may encounter a horror: you need to do the thing again. For example, Code on the Go supports a Java language server via the Language Server Protocol (LSP). It works well to support Java programmers. But what about Kotlin programmers? And developers using the NDK, who may code C, C++, assembly language, or possibly even Fortran? They all might want their own LSPs.
That’s a lot of new work to support. And if there’s one thing management dislikes, it’s extra work. Work costs time, money, bugs, customer goodwill…work is awful! And we don’t just want LSP support for Kotlin; we may want it (goes back and counts) for at least five more.
So the important numbers are zero, one, and many. When you need to do the second version of anything, that’s the time to figure out how to make it generic and applicable for many versions of the thing. Because inevitably, two leads to three, four, five, or even bigger numbers.
The general lesson is simple: Try very hard to do nothing. If that’s not enough, then do the smallest possible thing once. Don’t try to build generic systems upfront—they’re expensive and frequently wrong. Instead, wait until you’re asked for a second version. That’s what signals that your work is valuable enough to justify the cost of making it flexible and repeatable.
It’s been a few months since we released our first preview version of Code on the Go, and we’re currently in the transition from one to many. We’re intentionally building a generalized architecture to support your many different application needs. It’s a “many” amount of work for us now, but it’s part of our investment in a platform that gives you the best versatility later. Happy coding!
