Writing Source Code For Humans

By Stephan Eberle

Elevator Pitch

Source code is written once and read multiple times - for a long time to come. Strive to write code in a way that is good for PEOPLE to read and possible for a compiler/interpreter to run, not the other way around, or you’ll find yourself and your team in a world of hurt and I’ll tell you why.

Description

Computer languages differ from human languages in the way that they are deterministic and that source can be checked for correctness (language-wise and syntactically, sometimes even semantically).

The common agreement with a lot of developers is that source code is for the machine to execute whereas my argument is that source code is a way to convey concepts and intentions to other developers (and your future-self) with the benefit, that a compiler or interpreter is also able to either execute the instructions or generate instructions from the source.

In order to achieve this developer-developer communication and make it as “low-barrier” as possible we need to write code in a way that it can be easily picked up by other developers, that the structure of the code and the layout of the project are easy to understand and that ideas and concepts can be used and maintained well after the original developer left a project.

Notes

  • I’ll show why choosing a programming language is not just a matter of problem-domain
  • I’ll show some samples for conveying a concept using Rails and Go where
    • Rails benefits from its convention over configuration approach (the Rails-Way)
    • Go benefits from its explicit nature and limited instruction set (leading to the “same” way of problem-solving for Golang devs)

I’m qualified as I lead and work in a team working with Rails, Scala and Go and am also responsible for hiring new talent and maintaining development speed of features and quality. I also hack programs for 35 years and counting. :)