Book notes: Coderspeak by Guilherme Orlandini Heurich

Highlights / summaries that I made while reading Coderspeak by Guilherme Orlandini Heurich

On Community

When they contribute to open-source projects, they often say they want to ‘give back to the community’, (…which…) comes from the connection between the programmers who wrote it and the program they created.

Heurich cites Marcel Mauss’ The Gift:

What imposes obligation in the present received and exchanged is the fact that the thing received is not inactive. (…) It is something attached to me, the giver, and it will be permanently attached to me, even if you pass my gift along.

That is why, Heurich concludes, it is not the companies who contribute graciously, instead, but the individual developers who reciprocate. And not for the prestige (as Eric S. Raymond tends to think of it), but for a feeling of belonging to a community.

In the early days ‘think global, act local’ ideology was felt much in line with the free and open-source movement, focussing on fairer information technologies. But these days a lot of investments center around a few companies.

Ruby

Heurich took a job at a company called Upstream (no longer existing as an independent company) to study the interactions between programmers. Ruby was the main language used to develop the software.

One of the interviewed developers, Rafael, came to ruby from Java because of the community. And being mentored by José Valim he developed a “sense of obligation … or maybe an objective, really,” to contribute to Rails (one of the major frameworks to develop webapplications in).

What is special about Ruby according to DHH, initial creator of Rails, is that “The core language allows someone else to come up with their own dialect that makes the language better for them. That is what I’ve done for 18 years.”

Aside: Rubyist often congratulated themselves with the mantra ‘Matz is Nice and So We Are Nice’, and while I tend to believe that some of that niceness is still there, it should be noted assholes becoming more louder these days, among whom DHH.

But happiness, ruby was designed for developer happiness, is also a recurring theme.

Metaphors

Heurich often encountered sculpting related metaphors while listening to developers speaking about code. A monolith, as an application style, really is like a stone, you carve pieces out. You break it down.

Rails’ unique proposal: somebody took the modelling clay, created a language in a shape that was natural to them and gave it to you as a ready-made (baked) frame, with small holes you now can fill. - @zverok

Amir, a senior developer at Upstream described maintaining as ‘to prevent code from ossifying.’ (hardening)

Reflection

For me as a senior Ruby developer this book contains many relatable stories. Sometimes even feeling empathy for the developers who were talking about (in hind sight) wrongly chosen implementations that followed from choosing an off the shelf solution, which then was adapted badly and now has become a bottle-neck to development.

I finished the book, but in the second half I made considerably less notes. I much enjoyed the first part where a lot of day to day programming observations were made, but the relation between more visible developers within the global ruby community and the Japanese ruby community is not something I could easily relate to. After reading I concluded the Japanese ruby community is not that far removed from the global community, even though perhaps the ruby core team may have its peculiarities in terms of decision making. But then, deciding the design of a language, being both future proof and ideally backwards compatible, is not an easy task. And keeping a design consistent, deliver sparks of joy, requires one to be more careful accepting changes.

When looking for some reflection on your day to day practice as a ruby developer, a nice book to read. Especially the first part is really relatable, and can help others to understand what makes and drives a rubyist.