More Notes On “97 Things Every Programmer Should Know”

Some time ago I wrote a post about three articles from the book that specially grabbed my attention. Now I'm finally finished reading the book and I think a second and final post makes sense.

There are many good and great essays in the book, and a lot of advice for any programmer. Many may seem Common Sense™. But I think there's a lot in value in reading something you can agree, clearly explained. That's one of the biggest strengths of the book, in my opinion.

Floating Point Numbers Aren't Real

You can find the article by Chuck Allison here.

I enjoyed thoroughly this one. The examples are clear. My formal education is on Computer Engineering (rather than Computer Science), and one semeter we invested some hours looking at floating point representations, how hardware handled those, and the limitations found there.

Also, working at SeQura means I code with numbers that represent money. And as the article says:

It should go without saying that you shouldn't use floating-point numbers for financial applications — that's what decimal classes in languages like Python and C# are for. Floating-point numbers are intended for efficient scientific computation. But efficiency is worthless without accuracy, so remember the source of rounding errors and code accordingly!

Test for Required Behavior, not Incidental Behavior

You can find the article by Kevlin Henney here.

This one is great! It basically warns about testing implementation details. While the tests must be accurate and sufficient, we shouldn't overspecify them.

If you spec more things that are needed, testing for incidental behavior of an implementation, you lock yourself into that implementation. It says we need to treat the code under test as blackboxes, forcing us to clearly define the interface to test.

It's no incident–pun inteded–that the article that follows is called Test Precisely and Concretely, by the same author.

WET Dilutes Performance Bottlenecks

You can find the article by Kirk Pepperdine here.

I would have included it only for introducing to me the term WET (Write Every Time) as the opposite of DRY (Don't Repeat Yourself).

The author says that not adhering to DRY (where possible) hides possible performance improvements. Having different implementations doing the same thing scattered around the application, hides the possible benefits of refactoring them.

I like how this relates to Amdahl's Law (potential speed-ups). If I've learned one thing from studying Computer Engineering, it's Amdahl's Law. Seriously, that concept has appeared in almost every course I've enrolled for the past years.

Closing thoughts

Maybe I've just covered 6 things in these posts, but that doesn't mean, in any way, that these are the most important or useful. The book is not a heavy read but I think it's better digested when you give yourself time to ponder each essay.

Share this:

Leave a Reply

Your email address will not be published. Required fields are marked *