Disclaimer: I am affiliated with neither O'Reilly nor Pragmatic Press and have received no special discounts or compensation beyond the regular sales they make available to the general public.
That is all
Recently I've read two really excellent books. The Developer's Code by Ka Wai Cheung, and Code Simplicity by Max Kanat-Alexander. I should start off by saying that they were both great (and short!) reads and I'd recommend either of them to anyone. Particularly young developers still getting their first five years' experience(1). Though I've been reading a fair few books in between these two, something about them struck me as similar. Given that it's been months since I read The Developer's Code and no review materialized, I figured I'd give some brief words about each book now.
The Developer's Code
This book is aimed at younger developers, or even folks who haven't yet decided to become software developers. It gives a pretty good overview of the industry in which we work and how it's perceived. The author seems utterly enamored with code generation and found a way to bring it up in nearly every chapter. I'm not really a fan of it at all unless it's the runtime kind of code generation. However, it's largely incidental to the work as a whole. Lastly, chapter 6 discusses teaching and every single one of you must read it now. It's not even eight pages and yet he collects a handful of techniques it has taken me more seven years of instructing(2) to be able to put to words. The book was worth the full price to see these words written in front of me. If you need to borrow it, let me know. @sgharms has my copy right now.
I will admit to buying this book as an impulse buy because the ebook was half-off on O'Reilly.com. I'm ever so glad I did though as it's been a very easy and enjoyable read. At first I felt the method of describing the author's observations as Laws was considerably presumptive behavior. However, like the laws of gravity and motion in the physics world, the precise wordings have genericity(3) and a timeless quality. One of the stand-out aspects of this book to my mind was the complete absence of software testing until the very last law of the book. I was impressed by this because as I've written before, testing is not itself an end, it is a means to the end of successful, quality software that performs its duty of helping people. Throughout the book there is discussion of evidence and verification, from which testing should arise naturally. While I respect the author's desire to add a specific law of software testing, I think it could be omitted as a duplicate in a George Carlin-esque fashion.
Thanks for your eyes,
(1) I'm talking real experience. Not LOL I was writing C64 machine language in the womb by tugging on the umbilical cord in binary Morse code.
(2) When I was sixteen, I was reassigned from lifeguarding to teaching photography at the boy scout camp where I was working. I had no idea at the time, but the shake-up resulted in the discovery of two of the great passions in my life, photography and teaching. I went on in subsequent years to teach lifeguarding, teach teaching lifeguarding, and now teach programming and software development to whomever I can.
(3) Using the mathematical definition of "nearly always holds true."