The three types of programmers

Introduction: this article is part of a series of articles under the code name «Keep it simple»: theoretical discussions and personal opinions about programming in general and Ruby programming in particular. The main idea is simple: complexity is our enemy. All that we do, all that we are trying to achieve when developing software is to handle with complexity, brought to us by requirements, subject field and user demands. But still, some of our approaches, techniques and libraries bring undesirable complexity by itself – and this is not good. That's it.

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

• a) programmers-engineers: all the program is a mechanism for them, or even a draft of this mechanism;
• b) programmers-mathematicians: all the program is a formula for them (or a system of formulas), a theorem proving;
• c) programmers-writers: all the program is a text for them.

(There are also many types of bad programmers: programmers-managers, programmers-businessmen, programmers-laborers etc. But we won't talk about them. At all.)

What does it mean for a programmer to belong to one of those types? The way he or she writes the code. Which code the programmer considers good, and which – bad. How the development of the overall architecture works in his head. Which problems he solves the best.

Keeping it very simple, you can say that «engineers» can create good high-level structures, can recognize patterns in problems, but sometimes ignore the details. «Mathematicians» are unreplacable in algorithmically complex problems and can sacrifice almost anything for the sake of cleanness of solution, and «writers» find a lot of time for the «beautiful code», can easily recognize a niffy code, but, it happens, they forget about the whole picture.

Recognizing, which type you yourself belong to, is useful at least from such a point of view that this allows to develop your strong sides more effectively, and to notice and compensate the weak ones in time.

Here I should probably say that every good team must have all the types of programmers, and their tasks must be divided between them reasonably, etc. But, unfortunately, this happens very rarely. Why?

Statement 2: A programming language, «Ideal» for a developer, depends on the type the developer belongs to.

This statement may seem unobvious at first, but if you think about it, it gets absolutely clear. All these discussions and «holy wars», where people who seem reasonable ask rhetorical questions like «how on earth can anybody write big blocks of code in dynamic languages»?, or «how can anybody at all like Java?», or what is a proper OOP (and that nobody understands it), or that Functional Programming is the Only Answer to Any Question...

As much as I am convinced of the 1st Statement, I am sure that the programming language (to be more precise, language + tools + infrastructure + community) imposes a way of thinking, and the pleasure which a developer gets from work and his productivity depend very much on the extent to which the developer's way of thinking corresponds with the programming language way of thinking and the ecosystem he has to work with.

You can have long discussions about with which way of thinking every programming language corresponds, but this I am sure:

Statement 3: Ruby is for the (c) type, for programmers-writers.

Luckily, I don't have to prove this statement: the creator of this language proves it much more clearly and strongly than I could. In a famous book «Beautiful Code», a chapter written by Yukihiro Matsumoto, called ("Treating Code As an Essay") states exactly the same approach to Ruby as a programming language: it is created rather for writing, than engineering or calculating in it. This approach is either for you or not.

It is important, how they are written, both for an essay and the code. Even if the expressed idea is good – it will be difficult to deliver it to a reader if what's written is hard to understand. The style in which they are written is as much important as the goal. Both an essay and the code are meant – first of all – for people to read and understand.

Unlike Matz, I don't think that «the code should be meant for reading at first» (and that's why it should be first of all a Good Text) — this is an unalterable rule. Some languages – good languages – are evidently meant for writing something like «drafts»: big and complex complete structures, which a reader should explore and analyze for a long time, before he understands something. Other languages allow to write mindblowing, but compact representations of new and very complex algorithms.

But Ruby is definitely for texts. You either understand it, or you have chosen the wrong language.

Remark: Of course, all our «texts» have a practical goal. We write something that will work, something maintainable and extensible, something that solves big problems, we are not just expressing ourselves. To some extent, we all – Ruby programmers – write parts of one big text. That's why style guides and coding conventions are helpful. All in all, there's no sense trying to mix five parts of «Finnegans Wake» with one part of «Stranger in a strange land» and hope to get some sensible result.

Important Conclusion: There is only one reliable hallmark of a good Ruby-code, good Ruby-library, good Ruby-architecture:

On any code level, it is good, readable, neat and smart text.

Sure, you can say that one-hundred-line methods are useful, because «they allow to see the whole picture». But in Ruby, in a good Ruby, in our Ruby, every line or expression is a difficult phrase for a reflective reading, every method is a paragraph of the whole text. And it concerns every level: ideally, even on the most general level your soft looks like a couple of paragraphs, saying that «here happens this and that», with more detailed «explanations» in different components and libraries.

P.S. Important remark: Strangely ironical, Rails is the very thing that has made Ruby popular, and it doesn't share the «writer's» approach. They aim to hide expression and freedom of tools choice under the hood, and instead offer a developer lots of patterns, agreements, the best (and the only) practices and other marks of «engineering» tools. That's why, today there are two oppositely directed trends: on the one hand, a lot of Rails-developers move to another languages and approaches while they continue to think that Rails is a cool thing (these are, exactly, engineers), and others, while still continuing to be fond of Ruby, search for other approaches to ORM, routing and views, which would be more «like ruby», than Rails has offered.