There is a strange fascination in developers to keep things as small as possible. There are several reasons for it. In the past, computers had limited resources, so every byte had to count. On the web, we never know what people use to consume our code. Erring on the side of caution is also a good plan there. One virtue of every good developer is also laziness. This translates to fewer words and keystrokes.
Another reason for short code is that we drum up excitement in blog posts and presentations. Screen space isn't plentiful when you want people at the end of the room to read. And people online are busy and don't want to go through long-winded code examples.
Over the years in my career, I started not believing in short code as a goal any longer. There are a few reasons why we shouldn't celebrate it as much as we do:
- Terse code expects more knowledge. Often shorter code uses special syntax that allows to omit longer constructs. Furthermore, this syntax differs from language to language. If you write in several languages - as any developer sooner or later has to - this is another cognitive overhead.
- Terse code is less flexible. We never write code that considers outliers and problem cases at first attempt. Extending code that could be shorter tends to be easier than already optimised code. It isn't uncommon that a simple, short example only follows the happy path with a "TODO" for error cases. We keep it short by omitting error handling or assuming incoming data to be flawless. This isn't how the world works.
- Terse code often has a lot of dependencies. The biggest issue I see with solutions advertised as "in only $x lines of code..." is that they tend to have a lot of dependencies. New functionality only available to preview builds of browsers. Sometimes even non-standard code that is experimental or only applies to one environment. The worst case scenarios depend on a lot of library code to have functionality not (yet) available in the platform.
- Terse code is harder to read. Oh boy, this is holy war material. I'd rather have maintainers get clean code that follows a style than clever, dense hacks. And it shouldn't be a rite of passage to know all the syntactic magic a language allows. U wl b abl 2 rd ths, as our brain craves harmony and tends to fill in gaps. But it will tire you out much faster than a proper sentence.
The biggest flaw in the shorter is better thinking to me is that it assumes an outdated idea of development. We've come a long way in delivering code to our end users. Instead of writing live code there are a lot of sensible steps we can take. Linting the code for issues even before we add it to version control. Writing tests and validating the code against erroneous input. And converting and packing the code to be smaller in production than it is in development. Tools are great at shortening code to be more effective and even parsers and engines do their bit. JavaScript engines do a lot of optmising and caching of code. Thus a seemingly long piece of code can run faster than something that has been optimised prematurely.
So am I telling people to write more and overly wordy code? No, you can do whatever you want. But I wished we considered where the code runs and who maintains it before declaring smaller the winner. And I see a lot of effort and praise being wasted on code that looks impressive but wouldn't work out well in production.
What counts in the end is what our end users have to download and how it executes on their devices. Twenty lines of "clever" dependent on a high-computation library of 2 MB or more is not good service to our users. A hundred lines that deliver a good experience loading more when and if the environment and connection allows is good service.
By all means, let's keep impressing each other with short, clever code. But let's also consider the long term effect of making this a goal. We now still have a lot of web products dependent on jQuery, probably the starter of "write less, achieve more". Many of those products aren't maintained any longer. The libraries they depend on have security holes that won't get patched. Blindly following a "less is more" approach we created a lot of technical debt.
The other problem I keep running into is lots and lots of "short and quick" solutions being piled on resulting in a huge final product. Just because the smaller parts something big has been built with are optimised doesn't mean it results in an optimised final product.
My approach to development is the same I take when it comes to writing. I write as much as needed to keep it understandable and easy to follow. I deliberately use simpler words when more complex, but terser ones could confuse a reader. I go through my written products a few times and remove cruft as I go. I don't pretend that I could write the perfect post right off the bat. Instead making things smaller as you re-read it is a positive experience I enjoy.
Let's applaud excellent solutions for our users, not things that are impressive but only applicable in the environment they are shown.
Top comments (1)
I fully agree with your point here, but I think this article would've been even better with some examples of code, for example in snippets demoing a framework/library, that suffer from being too terse.