go-spew is a very handy library used for dumping arbitrarily complex data structures in a (roughly) human-readable format. This is immensely helpful when debugging or writing automated tests in programs. Coupled with a package like go-difflib, it can make comparing the expected and actual results of a test not only easy, but into something approaching fun. Much of my time lately is spent hacking on projects to be compiled by GopherJS, the Go-to-JavaScript compiler.

A couple of weeks ago I made a comment to my team at work which I think a couple took harshly, but I believe it is true, and an indication of a deeper problem. I said “All of the really smart people at this company move to the ‘infrastructure’ teams within a few years, which means we have only new, untrained people writing the real software.” Today, on a flight back home from vacation in Oslo, I was reading Domain-Driven Design by Eric Evans, and once again I found myself taken aback by how precisely this book has described my work place–and not in a good way!

I wrote this post in October of 2015 as I was adjusting to life without unit tests at a new job. I recently stumbled upon it in my Drafts, and edited it down to a single point for publication. In October of last year I took a new job at a company with a large group of programmers, and an old (15+ years) code base. The new company doesn’t generally do unit tests, for various historical reasons, none of which make much sense upon close examination.

I have a new software project in mind. I want to do it right. So I’ll use a RESTful web API. Which, of course, like any good software developer, I already understood pretty well, but I wanted to just brush up on my REST game, and make sure I got all the best practices down. Thus began my search on Amazon for a good book about REST. I found one. I read it.