Three Types Of Programmers

I am deeply convinced that there are only three types of good programmers:

programmers-engineers: the whole program is a mechanism for them or even a drawing of this mechanism;

programmers-mathematicians: the whole program is a formula (or a system of formulas), a proof of some theorem;

programmers-writers: the whole program for them is text.

What does it mean for a programmer to be one of these types? The way he writes the code. Which code he thinks is good and which code is bad. How the development of general architecture works in his head. What problems does it solve best?

To simplify a lot, we can say that “engineers” can create good high-level structures, they are good at distinguishing patterns in problems, but sometimes they neglect the details. “Mathematicians” are indispensable in algorithmically complex problems and can sacrifice almost anything for the sake of a clean solution, while “writers” pay a lot of attention to “beautiful code”, they can distinguish between bad code, but sometimes they forget about the whole picture.

It is useful to realize what type you yourself belong to, at least from the point of view that it allows you to more effectively develop your strengths and notice and compensate for weaknesses in time.

Here I should say that every good team should have all types of programmers, and tasks should be reasonably distributed among them, etc., etc. But, unfortunately, this is extremely rare. Why?

Statement: The “ideal” programming language for a developer depends on what type the developer is.

This statement may not seem obvious at first, but if you think about it, it becomes perfectly understandable. All this controversy and “holy wars”, where seemingly reasonable people ask rhetorical questions like “how can anyone write large amounts of code in dynamic languages”? Or “how can anyone like Java?” such correct OOP (and no one understands it), or that FP is the only Answer to All Questions …

No less than Statement 1, I am convinced that a programming language (more precisely, language + tools + infrastructure + community) imposes a way of thinking, and a developer’s pleasure and productivity are strongly related to how well the developer’s way of thinking matches the way of thinking of the language. programming and ecosystems with which he has to work.

You can argue for a long time about which programming language corresponds to which way of thinking, but of one thing I am sure:

Assertion: Ruby is for type ©, for programmer-writers.

Fortunately, I am not obliged to prove this statement: much stronger and cleaner than I could, the creator of the language proves it. In the famous book Beautiful Code, a chapter written by Yukihiro Matsumoto is titled “The Beauty of Code” and outlines this approach to Ruby as a programming language: write than design or compute. This approach is either for you or not.

For both essays and code, it is important how they are written. Even if the expressed idea is good, it will be difficult to convey it to the reader if what is written is hard to understand. The style in which they are written is as important as the purpose. Both the essay and the lines of code are intended — primarily — to be read and understood by humans.

Unlike The Matz, I do not believe that “the code is primarily intended to be read” (and therefore must first of all be Good Text) — this is an immutable rule. Some languages ​​ — good languages ​​ — are obviously meant to be written more like “blueprints”: large and complex unified structures that the reader has to research and disassemble for a long time before they understand. And in other languages, you can write a brain-absorbing, but compact formulation of a new and incredibly complex algorithm.

But Ruby is definitely for writing lyrics. Either you understand this, or you have chosen the wrong language.

Naturally, all of our “texts” have a pragmatic purpose. We write something that works, is extensible, and maintainable, that solves important problems, not just express ourselves. In a sense, all of us Ruby programmers write parts of one big text. Therefore style guides and coding convetions are helpful. After all, there’s no point in trying to mix the five parts of Finnegans Wake with one part of Stranger in a Strange Land and hope to get some meaningful result.

Important Takeaway: There is only one sure sign of good Ruby code, good Ruby library, good Ruby architecture:

At any level of the code, it is clean, readable, concise, witty text.

You could, of course, argue that 100-line methods are useful because they “let you see the big picture right away.” But in Ruby, in good Ruby, in our Ruby, every line or expression is a complex phrase for thoughtful reading, every method is a paragraph of general text.

And this applies to all levels: ideally, even at the most general level, your software looks like several paragraphs stating “this and that happens”, with deeper “explanations” in different components and libraries.