Unexpectedly Clean Code

There is this quite well known book, titled Clean Code. It is a very insightful work which I wholeheartedly recommend reading for any serious (or semi-serious) programmer.
The premise revolves around the concept of “cleanness” of code, which the author defines in various ways. Mostly it boils down to high signal-to-noise ratio and clear structure, where everything is neatly subdivided into smaller parts.

The idea is very appealing. For some it may even sound like a grand revelation; I know it was almost like that for me. But there is a bigger kind of meta-lesson to be learned here: the one of scope where such great ideas apply – and where they don’t.

You see, the Clean Code ideal works very well for certain kind of languages. The original examples in the book are laid down in Java and this is no coincidence. Java – as well as C, Go and probably few others – is not a very expressive language: lots of detailed busy work is often needed, even for conceptually simple tasks. And if several such tasks are lined up one after another, the reader is likely to drown in small details instead of seeing the bigger picture.

Those details are therefore one of the prime reasons why you may call some code “unclean”. To tidy up, they need to be properly encapsulated, away from a higher level overview. Hence it’s pretty common in Java to see functions like this one:

and think of them as good code, even if such a function is only used once. The goodness comes from the fact that they are relieving their callers from irrelevant loop minutiae, so that it’s easier to see why we need foos to be valid in the first place.

Yet, at the same time, if you saw a completely equivalent Python construct:

you would firstly curse at incompetence and lack of knowledge of whoever wrote it:

and then you would get rid of the function altogether:

Why? Because the language is expressive enough for implementation itself to be almost as readable as the function call. Sure, throw the result of all(...) into a variable for even more self-documenting sweetness, but don’t put it in some far away place behind a standalone function. Such code may or may not be cleaner; it will definitely raise eyebrows, though.

And lack of astonishment is probably the most important metric.

Don’t Throw Old Books Away

When moving in to a new flat just few days ago, I had to find a place for all the various IT books I’ve accumulated over the years. It’s not exactly a copious amount, but it was just enough to fill the shelves of quite big bookcase. Shuffling through them, I was surprised to find some really old ones, straight from the long forgotten era of Windows 9x.

Like these.

Many of the technologies they describe are long outdated (the different techniques for rendering 3D effects age particularly fast, for example). None of them seem to be completely phased out – you need to wait few decades for that, not just one – but I doubt they get used very much outside of maintenance of legacy systems. And definitely no one gets excited about, say, Delphi or Visual Basic now. That boat simply doesn’t float anymore, partially because its ocean – desktop platforms in general and Windows in particular – is slowly leaking away for quite some time now.

Does it mean all the books treating about those nigh-ancient subjects are little more than paper waste now? I wouldn’t be so sure. The whole purpose of IT books is far from being an up-to-date reference of anything. Bits over wire travel much faster than letters on paper, after all. It doesn’t happen very often that a developer needs to consult a book regularly, especially during a coding session. Although some timeless classics can be an exception, online documentation or sites like StackOverflow have replaced books for most intents and purposes.

Most – but not all. Some topics are better tackled practically if you first have a bit of theoretical foundation which you then iteratively refine after gaining more experience. You will finally put the book away, of course, but then you can still use it later to quickly revise your knowledge if need be. It doesn’t matter that it was standing dormant for many months or years, as long as it proves useful when there is urgent need to flip through its pages again.

What if you cannot even conceive how and when that prehistorical literature can be of any use whatsoever?… Well, I still wouldn’t be so quick with getting rid of it all. See, IT as a whole has this surprising tendency of going in circles, and periodically regurgitating old ideas into new forms and shapes. Hence the ability to generalize is important for long-term success in this field – at least the kind of success that’s more palpable than 15 minutes of Hacker News fame.

But to see patterns and connections between seemingly unrelated pieces of technology, you need have at least vague mental trace of all of them. And to verify you are not just seeing things, it’s often necessary to go back and read up again.

More often than not, that new thing will turn out to be just an old new thing.