The 97 Things Every Programmer Should Know – The Rapyd DevTalk Highlights

We were fortunate enough to be joined by Kevlin Henney at our Rapyd Developer Talk (DevTalk), where he shared his hard-earned insights with an audience of international programmers.  

Kevlin Henney is a consultant, international speaker, and editor of 97 Things That Every Programmer Should Know and numerous other programming books. He also has the unique ability to balance the technical with the profound, simplicity with nuance.  For a deeper dive into Mr. Henney’s expertise, we recommend checking out his Twitter, Medium page, or his programming books.

Please note that all the text below originally appeared in Mr. Henney’s medium articles or books.

Key Idea #1: Simplicity Before Generality, Use Before Reuse

A common problem in component frameworks, class libraries, foundation services, and other infrastructure code is that many are designed to be general-purpose without reference to concrete applications. This leads to a dizzying array of options and possibilities that are often unused or misused — or just not useful.

Generally, developers work on specific systems; specifically, the quest for unbounded generality rarely serves them well (if at all). The best route to generality is through understanding known, specific examples, focusing on their essence to find an essential common solution. Simplicity through experience rather than generality through guesswork.

Read more of Kevlin’s thoughts on “Simplicity Before Generality, Use Before Reuse.” 

Key Idea #2: Test Precisely and Concretely

It is important to test for the desired, essential behaviour of a unit of code, rather than for the incidental behaviour of its particular implementation. But this should not be taken or mistaken as an excuse for vague tests. Tests need to be both accurate and precise.

…

Precision matters. A test is not simply an act of confirmation; it is an act of communication. There are many assertions made in tests that, although not wrong, reflect only a vague description of what we can say about the code under test. In being precise, however, it is easy to get lost in a level of formality that makes tests hard to work with, no matter how precise and correct they are. 

Concrete examples help to illustrate general cases in an accessible and unambiguous way. We can draw representative examples from the domain, bringing the test code closer to the reader, rather than forcing the reader into the test code.

Read more of Kevlin’s thoughts on Testing Precisely and Concretely.

Key Idea #3: Comment Only What the Code Cannot Say

As with any other form of writing, there is a skill to writing good comments in code. And, as with any other form of writing, much of the skill is in knowing what not to write.

What of comments that are not technically wrong, but add no value to the code? Such comments are noise. Comments that parrot the code offer nothing extra to the reader — stating something once in code and again in natural language does not make it any truer or more real. Although often interpreted simply as a principle of avoiding code duplication, DRY (Don’t Repeat Yourself) cautions more broadly against the repeated expression of knowledge within a system… Instead of writing apologies and apologia, follow Kernighan and Plauger’s advice from the 1970s: Don’t comment on bad code — rewrite it.

Read more of Kevlin’s thoughts on Commenting on Only What the Code Cannot Say.