skip to Main Content
  • Blog
  • The 97 Things Every Programmer Should Know – The Rapyd DevTalk Highlights

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

developer looking at computer screen

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.” 

Download Report

The State of the Fintech Developer

See trends and insights into what developers like yourselves are doing to help shape global fintech.

Download Report
Rapyd Fintech Developer Study Cover Image

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.

Check Out Our Developer Community

From research on how developers like you are shaping global fintech to a forum for getting your fintech questions answered, the community has it all. Check it out and join the discussion about our API, low-code solutions, fintech and everything else.

Learn More

Related Articles

Developer looking at computer screen in dark room

Study Finds Nearly Half of Developers Involved in Data/AI Initiatives, Even More Want To Be

Read Blog Post
Developer uses Rapyd APIs

Here’s How to Keep Developers Happy, New Survey Reveals Best Practices for Fintech Devs 

Read Blog Post
Fintech developer builds payments tools on his laptop

New Study Reveals What’s Eating the Most Time for Fintech Developers

Read Blog Post

Join the Rapyd Developer Community

Gain insights from a worldwide community of fintech developers.

Subscribe Via Email

Thank You!

You’ve Been Subscribed.

Back To Top xandr