User Profile

I didn't particularly like this book, but I want to start by saying that it's really my own fault. I should have taken a closer look at the synopsis and the table of contents, I basically read it based on the title alone and it wound up being a very different book than what I was expecting.

I was expecting a technical book for architects, or even any engineer doing architectural work and making decisions of an architectural nature. Ultimately the book is entirely nontechnical, and what it tends to view as "architects" I tend to think of more as "managers". The book is mostly about soft skills for management types and yeah, it's not really focused on management skills in terms of managing people or anything, so it's fair in that it's still focused on the skills of individual contributors.

A more accurate title for the book would be something like "Ivory Tower Architect Soft Skills: How to Interact With The Rest of the Business When You're The Most Senior Person on the Team and You No Longer Write Code".

If that's up your alley, the book is actually pretty good. Very thorough, well written, covers a lot of ground and is organized and broken up into right-sized chunks. If that's not appealing to you, I'd say give it a pass. Most of it is common sense anyway.

Debugging to me feels like an extremely imperfect process - while most aspects of software engineering I do on a regular basis are informed by a mix of learning/reading with a heavy dose of experience/wisdom, debugging is one part that is purely experience, without ever having read a single book on the subject. Given how much I read and how much I learn from reading, I have assumed that while I'm good at debugging I'm really in a "tip of the iceberg" situation, and with the right kind of reading material I'd really max out my skills.

I first read "Debug It!" hoping it would provide the academic and formal learning that would turn me from an okay debugger into a master debugger. But in the end, that book wound up saying nothing new and I largely felt it was a waste of time.

I had hoped Effective Debugging, with it's subtitle of "66 Specific Ways" to debug and the "Effective *" moniker that I've come to associate with excellent books traditionally, would really teach me a lot. But alas, nope, it was stuff I already do. Sometime around Chapter 2 when Item 13 suggested I enlarge my window so that the entire line of a log file would fit, I started to realize that there probably is no book that will take me from an okay debugger to a master debugger. I think everyone's just an okay debugger and that's it.

I guess this book is worth skimming, especially if you're new to software engineering. But if you've been at it for any length of time, you could likely write this entire book if only you could be hyper aware enough of your debugging process to simply write down the stuff you're doing as though it was noteworthy, rather than second nature. Overall, I just didn't get much out of it, and I was really hoping I would. Two disappointing books in and I've given up, debugging can't be taught.

Not bad. Decent advice in here and good material, it gave me some insight into some "behind closed doors" aspects of Google, Microsoft, Apple, and Amazon's hiring process. It was worth reading for someone interested in a job at one of these big companies.

I think overall the book skews more toward college students and recent graduates than folks like me who have been working in tech for a while. There were plenty of parts that I just skimmed because I felt like they didn't apply to me.

I felt like the advice in general skewed young as well, and I kind of felt like the author did too. There was one section of a Q&A where the question was something like "my parents tell me I should take down all the facebook pictures of me underage drinking, are they right?" and Author Gayle McDowell's response was not to bother, if anything underage drinking makes the submitter look more sociable which Google might want to balance out all their nerds. Uh, no dude. Delete the pictures. Holy smokes what terrible advice.

Overall, book was full of good insider info but for someone at my point in my career there was a lot that didn't apply. I'd definitely recommend it to younger folks or college students who want to get into one of these big companies, and it's worth a quick skim for graybeards like myself.

I kind of always had this hunch that Domain-Driven Design was something of a buzzword fad, that it likely described something I was already doing regularly and that the book and the approach likely just lent formality and terminology to common sense activities. After all, the biggest thing I see referenced seems to be this Ubiquitous Language stuff, which I think just means using the same nouns for stuff as the domain experts, which I try to do anyway so I'm sure I'm already doing everything in the book, right? Nope. I was flat wrong, which is why I consider this book a must-read for engineers who do a lot of greenfield work, domain modeling, and architecture.

Early on, the author provides a sort of toy example that will stay with us for the duration of the book, designing the domain for a Scrum management product. I've actually worked a job where I did this very thing, so this resonated fairly strongly. The book suggests that, if engineers are left to their own devices, they'll design around code generality to reduce duplication, so there might be like a ScrumElement that could be a Product or a BacklogItem, and there's like a generic ScrumElementContainer which could be either a Sprint or Release. I'm just reading this section like, yeah, that's exactly what I would do... in fact I did that. Is that bad? But the rest of the book explains exactly why that's bad, and exactly how to do it better. Chapter after chapter, the book showed me the ways in which my approach to domain modeling was disastrously bad and how much better it could be. It also explained how, with this alternative approach, my domain would lend itself more easily to modular system design along service-oriented boundaries.

In short, this book is excellent and completely changed how I think about and model domain objects at work. The book can sometimes be light on detail, I often found myself wanting more information, or stronger examples of exactly how something should work, but at the end of the day that's the purpose of this book - a short introduction that encourages the reader to dive in deeper with Domain Driven Design or Implementing Domain Driven Design. As such, I can't really complain about the general lightness of this book, as it's the primary reason it was such an easily digestible 197 pages.

Overall, this book is a must-read, I wish it existed years ago. I think back to all the times that a group of coworkers and I would gather in front of a whiteboard and model domain objects together without a single domain expert in the room. It makes me slap my head at how idiotic my approach has been for over a decade, the ways that I let database and technical concerns dictate the design of domain objects rather than the business's needs. I can never look at this regularly-performed process the same way, which is why it joins my list of Career-Changing Books.

I've become somewhat wary of "how to be a better programmer" type books in recent years. I really want to become a better programmer, but I've been doing this for over a decade and it's gotten to a point where every book I pick up feels like rehashing the same stuff from Pragmatic Programmer, or adding codified common sense. I know it sounds like I'm tooting my own horn, like I think I'm some great programmer, but that's not what I'm trying to say - it's just that a lot of these kinds of books have little new to offer someone who has been in the industry as long as me.

I probably wouldn't have bothered picking up Beyond Legacy Code if not for the fact that the author actually mentions my master's thesis in the last chapter of the book (though he gets my name wrong, grumble), because I think it mostly fits the bill of "general book about being a better programmer."

I'm really glad I wound up reading it though, because for the first time in ages one of these books actually gave me a lot of new stuff to ponder and think about. Naturally there was a lot of head-nodding, as the book reiterates lots of things I already know, but David Scott Bernstein definitely did put these ideas to words in extremely novel and useful ways. In particular, I loved the CLEAN code acronym, which I'd never seen before and have now mentioned multiple times at work. It's not that CLEAN (Cohesive, Loosely coupled, Encapsulated, Assertive, Nonredundant) is a new way to look at code, but it IS a very handy pneumonic that's easy to reference and remind yourself of, like SOLID, DRY, YAGNI, etc.

Bernstein's chapter on Practice 2: Build In Small Batches, is particularly excellent. Not merely content with reiterating common sense ideas about building code, the chapter cites tons of studies and figures to back up the claims, really showing the value of building and releasing in small batches and avoiding huge team utilizations. I've directed people to read this chapter on multiple occasions since reading it, it's fantastic.

I think the title of the book is a bit misleading - I was kind of expecting something like Michael Feathers's excellent Working with Legacy Code, but I think the "Legacy Code" aspect of this book is pretty minor, in fact only Practice 9 deals with it directly. The rest of the chapters are more, how to write good code in general, and I suppose you could argue that all code is Legacy code once it's written, but the book title still had me expecting something a bit different. I also felt like the final chapter, Learning from Our Legacy, went on a bit too much, the final section in particular seemed to restate the exact same thing over and over, it kind of had a "can't figure out how to end" vibe to it. Part 1 of the book, which establishes how much of a "crisis" we're having in software development, was similar, you kind of read it going "okay, I get it" and wanting to get to the meat of the book.

Those minor gripes aside though, I think the book is definitely well worth reading, and I think it's earned a place on the shelf right near The Pragmatic Programmer as mandatory reading for junior and senior developers alike. Definitely highly recommended.

A lot of authors seem think they can gather together what is essentially a ton of short blog posts and compile them into a book that will become as noteworthy and reference-able as The Pragmatic Programmer. Maybe The Pragmatic Programmer is also really just a collection of simple blog posts, and the only reason I liked it so much and disliked this book was because I read them at different points in my career. When I read Pragmatic, I needed to read it, and it was very influential for me, and when I read Becoming a Better Programmer, I'd already learned and started doing most of the things in the book because I've been at this gig too long. Maybe if the books were swapped, I'd love this book and roll my eyes at the basic-ness of Pragmatic.

But as it happens, that's not the timing of when I read these books, and so for me Pragmatic Programmer was life-changing, and this book was an incredibly long and tedious collection of what I'd argue is common knowledge.

The book is probably fine, and I might even recommend it to a newcomer, but it just didn't do much for me. I'm not trying to say I'm above it, this isn't me tooting my own horn, I just genuinely think that there's nothing particularly insightful or noteworthy at play here. Just a standard collection of common programmer wisdom that anyone who has been working for a few years knows. I frankly found the book a slog to get through, and I kept hoping I'd eventually happen upon something worth bookmarking, quoting, or highlighting, but I just never did.

I think this is a definite "your mileage may vary" book. There are a lot of positive reviews from career newbies who clearly found it to be, for them, what I found Pragmatic Programmer to be for myself. So I don't know, it's probably worth reading if you're fairly new to programming, or perhaps unsure of yourself or suffering from imposter syndrome.

UPDATE: Given what has happened with Patton's wife since I wrote this review, it all seems a bit petty now. I'm only leaving it here because there are a few comments, and if I delete it they won't make sense. TL;DR of the review: I wound up reading this book for a weird reason, and it was alright.

----

Why did I read Patton Oswalt's "Silver Screen Fiend"? To answer that, I have to first tell a bit of a story.

A few years back I wrote a blog post introducing a new order for watching the Star Wars films. I named it "Machete Order" after my blog ("Absolutely No Machete Juggling", don't ask) and published it randomly without much of a thought. A year or so after publishing it, Wired.com linked to it in an article, and for the remainder of the year after that it sort of "went viral". I was interviewed on a local news station as well as NPR, the post was mentioned in various magazines, it got a shout-out in an episode of The Big Bang Theory and King of the Nerds, and was even mentioned on CNN. Clearly this was to be my fifteen minutes.

But by far, the absolute coolest mention of my dumb Star Wars post was on an episode of Late Night with Seth Meyers, in which Patton Oswalt mentioned the order as an "amazing" way of watching Star Wars. I went through the roof, I've listened to every single comedy album Oswalt has ever released, and seen every special he's ever taped. He has been one of my favorite comedians for years and the very notion that his eyeballs were looking at my dumb blog utterly floored me. To date, this is still the highlight of my fifteen minutes of fame, which have since subsided after the release of Episode VII.

Shortly after the Seth Meyers plug, I saw that Patton was touring and would actually be in Denver a few months later. I bought tickets simply because I'd never seen him live, and then I was struck by a silly idea. What if I messaged him on Facebook, told him I was the Machete Order guy, and asked if I could meet him when he comes to town? "No," I thought, "it's too presumptuous, it's awkward and weird. I'm just some guy on the internet, why the fuck would he want to meet me?"

But my own curiosity got the better of me and I convinced myself, hey, I'm nothing to sneeze at, after all HE'S the one who referenced ME. Hell, maybe he'd be a little excited to meet me like I would be to meet him. So I worked up the nerve to message him on Facebook and asked if he'd like to meet me after his Denver show. I assured him "I'm not some rabid, crazed fan - just a hello and a cell phone pic or something would be awesome." I told him I'd understand if he didn't feel comfortable with it, that I understood the internet is full of weirdos and I'm just a name on the internet to him. I thanked him for the shout-out on Seth Meyers either way, and pressed send.

To my immense surprise, Patton responded within minutes. "Sure! This should be no problem." Holy shit. I'm going to meet Patton Fucking Oswalt! He followed up with "You + 1 will be on the backstage visit list!" I was beside myself with excitement.

But then panic set in. What the hell would I say to him? I'm just some guy with a blog, what can he and I possibly talk about? Okay, one, Star Wars for sure. I didn't want to talk about Machete Order itself, that seemed to self-absorbed. But the date of his show was actually AFTER the release of Episode VII, so I figured I could ask him what he thought of the new movie, we could chat about that a bit. Two, cell phone picture. My wife can take it, and that'll take a little time too. Or wait, what if he wouldn't want that since I'm so much taller than him? Oh, I know, I could get him to sign something! Oh but shit, what would he sign? A comedy album? Who even owns physical CDs anymore, plus he's not a rock star so that's weird. "Wait," I thought, "I've got it! He just recently published a book called Silver Screen Fiend, I'll buy a copy and he can sign that!"

So I ordered a hardcover copy of the book. I honestly had no intention of reading it. I've read a few autobiographies by comedians and frankly haven't enjoyed them much, they're always too young to have enough life experiences to impart wisdom, and the funniest life experiences they've had are already part of their comedy routines, so the books always just seem like extremely long and watered-down sets. Patton's book in particular didn't interest me as it looked, from the cover and description, like it was mostly about movies he liked, and I hadn't seen a lot of the older films he seemed to discuss. But I figured, hell, I don't have to tell the dude I'm not gonna read his book, I really just want to meet him and it'd be nice if I had something he can sign. The book signature would just be a neat memento of what would definitely be the biggest celebrity encounter of my life.

The date of the show, the wife and I drove downtown and sat down in our seats - pretty far in the back, unfortunately. By this point, my wife was actually pregnant with our first baby, a girl. I knew Patton also had a young daughter from listening to his comedy, so I figured if I ran out of things to say my obviously-very-pregnant wife could be a topic to end any awkward silences. I was feeling pretty good, I just had to keep telling myself not to act like an insane gushing fanboy and treat the man like an ordinary person.

Patton came out on the stage in Denver's Paramount Theatre and bellowed "Hello Dallas!" Oof. Not a great start. The crowd was nearly silent, some people nervously laughing trying to figure out if he was messing with them. Patton then made some jokes about the local Dallas area, which were met with almost total silence from the audience. He seemed taken aback by the reaction, like he knew that normally name-dropping attractions gets the locals riled up. There was an awkward pause and I heard someone in the front row say something to him. Then Patton jumped, "oh fuck, am I in Denver?" - big laughs. Patton had a pretty good show that night, he rescued the set and won the audience over eventually, but I could tell the Dallas flub rattled him, he even made another crack about it and called himself an idiot later on. He talked about Star Wars Episode VII and shared his thoughts on the film as well. I tried hard to focus on the show and enjoy myself, but the thoughts of meeting him kept creeping in. When he made the Dallas flub, I wondered if it would put him in a bad mood after the show. When he mentioned Episode VIII, I realized it would no longer be a viable conversation starter.

When the show ended, I looked around and tried to figure out where to go or what to do. I'm not a famous person, I have no idea what the procedure is to go backstage because you're "on the list" - I've never been on a list before. The best I could tell was, up front near the stage were some curtains with guards standing in front of them. Me and my pregnant wife tried to make our way to the curtains, but struggled against the force of the crowd moving in the other direction to exit the theater. I could hear people muttering about me, snickering. One guy laughed when his girlfriend asked what I was doing, to which he responded "he thinks he's going to be able to go backstage." Yeah, I get it. I looked like some douchey nerd fan, holding my stupid Patton Oswalt book like an idiot. But little did that guy know, I'm on the list, motherfucker!

I finally pushed my way past everyone and got to the front. I walked up to the security guard and said "hey, I'm Rod Hilton, I should be on the list." He looked me up and down, then replied, "we weren't given a list." My face fell. I thought there might be some kind of mistake. "Can you just go ask--" I started, but he interrupted "nope, sorry, can't do that. You can feel free to call him yourself though" he said, smirking. Well, shit. I didn't have his number, we only talked on Facebook. I pulled out my phone and tried to show the guard my conversation with him, but when I held my phone out he pushed my arm back down and said "sorry, can't use that, he has to actually come out here and get you."

So I messaged Patton on Facebook. "Hey Patton I don't know if you're still here but they say they don't have a list..." I knew every minute that ticked by made it more likely Patton had already taken off for the evening. And now I was asking for so much more than being a name on a list, he'd actually have to walk all the way back out of the dressing room and come get me to let me come backstage, it seemed like a lot to ask. I quickly followed up with "I won't keep you or anything just wanted a quick signature" desperate to salvage the whole endeavor. And then I stood there, against the wall. All of the people I had to push past were still glancing back, seeing if Patton was going to show up to sign books or something. But they saw no Patton, just me and my wife, standing against the wall, waiting, having been completely rejected by a few large security guards. I felt my face flush with embarrassment as I tried to think of things I could say to the security guard to convince him to let me go back stage, but I realized everything I could think of saying only made me seem even more like a crazed fan, which to a security guard likely meant security risk.

Minutes went by, feeling like hours while I waited. I kept refreshing my Facebook messages over and over, hoping Patton would respond. After some time, the entire auditorium was empty aside from the guards, a few ushers picking up trash, my wife, and me. Eventually they told me they needed us to leave the room so they could close up, so we did. I stood in the lobby for a bit instead - there were a handful of other fans there, also holding books for him to sign. I guessed they were all fans who thought Patton might show up after to greet folks, but who didn't have the audacity to actually try and get backstage like I did. I stood there until the staff indicated that Patton had "probably already left" and other fans started filing out, their unsigned books in hand.

My wife and I walked back to the parking garage very quietly. She could tell I was upset, but she had no idea what to say. I kept flashing between feelings of intense disappointment and embarrassment. The faces of all the friends and family I told I was going to meet Patton Oswalt flashed in my mind as I imagined having to tell them all one by one I didn't actually get to meet him. I mentally rehearsed how to say it in a way that played it cool like it didn't bother me and was no big deal.

We drove home in near-silence as I thought about what happened. I found it odd that the security guard hadn't told me that my name wasn't on the list, but instead that there was no list at all. If Patton had simply forgotten to add me to the list, then him remembering would have meant that I was the ONLY person on the list. How awkward would that have been for him? No entourage of people drinking and mingling, just him, me, and my wife. No celebrity would put himself in that kind of situation. It doesn't seem possible that he could have intended for me to be the only person on this list. Hell, that's not even a list, you can't have a list with one item on it.

And then it dawned on me. The problem wasn't that my name wasn't on the list. The problem wasn't even that the guard hadn't been given a list. The problem was, there never was a list.

I finally realized what you probably realized twelve paragraphs ago, that "You + 1 will be on the backstage visit list!" was actually just a nice way of saying "no" without making a fan think you're a jerk. This way, Patton could say yes and keep a fan, and just rely on that fan to blame the security guards for being stupid. This way, there was no risk of a disgruntled ex-fan taking a screenshot of his Facebook conversation and posting about a famous person telling the fan to fuck himself. He gets to stay cool, but also doesn't have to meet some random guy on the internet. It was the equivalent of an attractive person giving an unattractive person a fake phone number in a bar. I realized, I was just some random noncelebrity bothering a famous person and being told he'd have his people call my people. I was the waiter who tries to give Steven Spielberg his screenplay, the limo driver who tries to hand Dr. Dre his demo tape. I was a sucker.

I walked through the door of my house at the end of a very disappointing evening and looked down at my hands. There it was. "Silver Screen Fiend". A hardcover copy of a book I never had any intention of reading - purchased only so I'd have something that one of my favorite comedians could sign - completely unsigned. A rectangular object whose purpose for existence now seemed to only be to serve as a reminder of a humiliating experience, a totem of my commoner status. And there it would sit, on my bookshelf, untouched by black sharpie, mocking me for entertaining the thought that my fifteen minutes of fame was the same as actual fame, just shorter.

So I read it.

I figured, if I at least read the book then it served some purpose other than mocking me. Its placement on my bookshelf would be germane to it being a book that I read like everything else on it, rather than a waste of money that I bought too long ago to return to Amazon. And hey, maybe it would completely suck and I could give it one star on goodreads.

But in fact, the truth is that it's pretty good. It's not a terribly funny book, but it's an honest one. And though it does START with a huge stress on Patton's goal of watching classic films, that's pretty much done by the end of the first chapter, with only occasional callbacks later on. The rest of the book mostly deals with his career, covering his early start as a stand-up comedian, talking about his first acting gig on Down Periscope, and his time as a staff writer on MADtv. These sections of the book were weirdly fascinating and extremely honest - I particularly enjoyed Patton's self-introspection as he recounted his first-ever speaking line on film and how he overanalyzed all the ways he might say it. It reminded me of my own thoughts working through what I'd say to him when I met him.

Given the personal experience I've recounted in this review, you can imagine how hollow Patton's words rang for me when he discussed meeting Jerry Lewis, or how nerve-wracking it was sharing a stage with his "idols" like David Cross, Dana Gould, and Laura Kightlinger. Imagining Patton as a giddy youngster meeting celebrities he admired was difficult while also imagining him as an A-lister callously dismissing a fan by telling him that his name would be on a nonexistent list.

Overall though, and particularly for anyone who wasn't personally cast aside by Patton Oswalt, Silver Screen fiend is actually (unfortunately) a really good book. Entertaining without being "jokey," and very honest. It's a great look "behind-the-scenes" at show business, and it offers a lot of insight into Patton as a person and what made him who he is today. If you're into Patton Oswalt's comedy, don't let the title or even the book's description turn you off the book, I think you'll enjoy it.

Patton eventually responded to me on Facebook, long after I'd already given up and gone home. He assured me "you were supposed to be on the list" doubling down on the fiction. He asked me what I wanted signed, and offered to mail it to me. I told him no thanks.

This is just about the most you could expect from a book about Docker. It's far, far better than the documentation, it talks about best principles and practices, and every single suggestion is accompanied by detailed commands to type to accomplish the tasks. The book has a great throughline of developing and improving a small application, which is used as a reference in every single chapter.

It covers almost everything you want to know about Docker including more operational stuff like monitoring, orchestration, and security. Pretty much no stone is left unturned, what you want to know about using Docker for real is covered eventually.

Occasionally I wished the book went into a bit more depth, or I felt like the author was sort of hand-wavey. There were a lot of times when he'd say something like "don't do this in production" without much explanation of what you WOULD want to do in production. Additionally, there were frequent mentions of how this or that aspect of Docker will be fixed or changed soon, leaving the reader to both wonder if Docker is truly ready for prime time, as well as if this was the proper time to publish a book on the subject with the technology so in-flux.

My biggest complaint is actually about Docker itself. By later chapters, Mouat would show incredibly complex and lengthy commands to type that left me wondering if it was even possible for documentation to be good enough to get a person to the point where they'd be able to type that command from scratch. What would you do if you wanted to do something slightly different than Mouat's example? It seemed almost impenetrable at times.

One thing I felt was lacking was an example of persistent data storage. The identidock example that runs through the entire book is all non-persistent, every single container could be restarted with complete loss of state and have no effect. The closest thing to a database used, redis, was used as a simple cache that could be emptied upon restart with no penalty. But many applications need real-live databases that need to persist across container restarts, and there's basically no coverage of how one would accomplish such a thing. From my own Googling it looks like the agreed-upon pattern is a data-only container volume linked to the system needing to store data, but it would have been nice if the example application could have incorporated such a fundamentally basic need.

Overall the book is fair and does a great job of helping the reader understand the pros and cons of containerized deployments, and it takes you through pretty much everything to know, at least in the world of Docker. In terms of how you might want to change your applications to make them more containerizable, it's largely left to the reader. Nonetheless, I can't imagine there even being a book on Docker that's more thorough and properly-paced than this one, it's basically a Missing Manual.

Data and Goliath is an eye-opening read. I mean, I understand how I'm under constant surveillance due to things like my smartphone or cookies or Facebook, and I understand that the government gets access to a lot of this information via the Snowden leaks, but I guess I never fully connected all the dots enough in a single unified understanding of my world. Bruce Schneier provides it.

Most of the book is somewhat technical, helping the reader understand how data about them is collected and used. It does a good job of disseminating the Snowden whistleblowing information as well, so it's all very informative. That being said, the level of information often made me feel hopeless, like there was nothing that could be done and I almost had to just accept that this is how life is now.

The final few chapters offer some respite from this feeling of hopelessness. It contains sections on what governments ought to do, what people should do in the macro sense, and even what people should do in the micro sense, just for themselves to avoid surveillance. Schneier isn't idealistic about it either, he's pragmatic, and fully admits that there are some data people will be willing to turn over for convenience, security, or usability. There's nothing wrong with that, everyone's got to find their sweet spot.

Mostly though, I just came away feeling like Bruce Schneier is a national treasure. Can I vote for him for some kind of public office? Anything really? In a world of seemingly limitless insanity, he's a consistently sane voice. I highly recommend everyone read Data and Goliath.

At work, we selected this book for our development team's book club. So I'm going to be giving my thoughts as well as the thoughts of the rest of my team.

First and foremost, I thought this book was very well written. It's organized well, the "days" are paced well, and the code examples are excellent - easy to follow for the most part (the Wikipedia examples struck me as a bit odd in that they required substantial XML parsing that was not directly included in the book) and did a good job of illustrating the concepts.

While clicking around Goodreads, I clicked the author's name and saw that he actually wrote a book I've read and reviewed previously, "Debug It!" - I kind of eviscerated that book, and I'm happy to report that Paul Butcher's writing has substantially improved since then. I was very impressed with the quality of the writing in the book, the clarity of the prose, and the way in which Paul preemptively answered questions I was having, or told me they'd be addressed soon. It's the sign of a good author who is in touch with his audience when they can anticipate bumps.

One of my complaints, and in fact the complaint of my dev team, was that it simply had too much Clojure. I don't know if this is a fair criticism, but of the 7 concurrency models covered, 3 of them used Clojure (and one of them, the first, only used Java to show how crappy it is to use threads directly, and didn't cover a lot of the concurrency utils in Java).

I did finish this book, but to be completely honest the rest of the team stopped after during Week 4. The book was abandoned and we selected another book for book club. The reason was that people were growing increasingly irritated with the book's overreliance on clojure, and Week 4 was the straw that broke the camel's back. The chapter was on Actors, and rather than doing the obvious thing and doing all the examples with Akka, Elixir was chosen. So this was yet another language to adjust to, and in fact one in which Actors aren't even called Actors (they're Processes in Elixir). This set off my team's "blowhard" alarm and nobody wanted to continue further. It's a shame I didn't get to see their reaction to Butcher's conclusion, where he humblebrags about predicting that parallel programming was going to mainstream two decades ago.

In any case, here's a week by week breakdown, not in order:

Week 1 (Threads) - Great, really good overview, excellent examples of direct threading, and decent use of concurrency utils
Week 3 (Software Transactional Memory) - also great, and since this is clojure's bag it makes sense that this was a clojure chapter
Week 2 (Functional Programming) - this chapter was the first that irritated me and my co-workers. With all the functional programming languages out there, chosing Clojure (an impure functional language, of all things) seemed kind of obnoxious. I have a hunch this was chosen so as to introduce unfamiliar syntax before Week 3, which is fair, but it started to make it feel like this was "a clojure book"
Week 4 (Actors) - Bad. Use Akka, that's what everyone thinks of when they think actors, at least in the non-academic space (and using Clojure rather than Lisp or haskell puts you in a non-academic space).
Week 5 (CSP) - Fine... another Clojure chapter, but I'm honestly not familiar enough with CSP to judge if this was the best tool for the job. I generally find Clojure hard to read so, it's not my personal first choice, but I think it's the right tool for Week 3 because I'm semi-familiar with STM.
Week 6 (GPGPU) - This was a weird chapter to include. Parallelism using GPUs is a bit of a niche, and something that I'd imagine would be covered better in a book devoted to it. It just doesn't seem "general purpose" enough to be in a book about breadth, I found its inclusion odd.
Week 6 (MapReduce) - Fantastic. Really good hands on examples with Hadoop and Storm and EMR. Great stuff, learned a lot here.

So overall, the book is more good than bad, though Butcher makes some frustrating decisions. If you have no interest in Clojure, I think you might want to pass on this book, it's a bit overly reliant on that language and if you dislike reading it I think the book will irritate you. Otherwise it's good and I'd recommend it.

The problem with the "Seven Weeks" series is, every chapter you read it seems like it would be better in its own book. I have to remind myself that these books are about breadth and exposure, not detail. So the fact that there are better books on Hadoop, MapReduce, Threads, STM, and so on out there isn't relevant, because the point is exposure.

That said, I'd be remiss if I didn't suggest Venkat Subramaniam's "Programming Concurrency on the JVM" over this book. Like this book, it too is a breadth/overview book, but rather than covering the second half of this book, it instead focuses on the first few chapters worth of content, namely Threads, STM, and Actors. It goes a bit deeper on each of these subjects by utilizing the room saved by dropping CSP and GPGPU techniques, which I think both didn't really need to be included in this book. I really liked the Lambda Architecture chapter about MapReduce, Hadoop, and so on in this book, but I'm willing to lose it to get an improved version of the chapters on Threads, STM, and Actors. And it has to be mentioned, Venkat's book utilizes the right languages and libraries for those techniques (Java, Clojure, and Scala/Akka respectively).

So this book provides a bit more breadth than Programming Concurrency on the JVM, but it provides it to areas that I think are largely unnecessary. PCotJVM is a bit more focused on the stuff that really matters, and uses better tools for job in my opinion.

I have consistently written a short little review of every book I've read for the last few years, and I'm not willing to let this one break my streak. The problem is, I usually read programming books, and I've read hundreds of them so I have a lot to compare to, and thus my reviews of programming books are pretty well informed.

However, this is my second "new dad" book and, I dunno, it's fine I guess? I just have little frame of reference here. I learned some stuff, it's good good advice, and it's easy to read. I basically have no idea what I'm doing as a first-time-father-to-be, so any advice is good. It's a low bar.

There's a lot of breadth here, it covers every trimester as well as the first few weeks with the new baby, which is good. A lot of these books only focus on the pregnancy itself which, yeah I like being helpful to my wife, but it's kind of her thing and I'm not super involved.

One thing I should point out is the tagline of the book "Dude, relax; you’re going to be fine." didn't ring true for me. In fact, I found that I had to stop reading this book immediately before bed, as it would give me anxiety that would cause me to wake up and be unable to sleep. The book didn't relax me at all, quite the opposite. I appreciate all the "heads up" type moments the book conveyed, but relaxation was a distant memory while reading.

Anyway, it's pretty good. Readable, kind of funny, short, useful. It's a new dad book.

I read this because I loved Tina Fey's book, Bossypants, and Tina and Amy are basically BFFs for life, so I hoped it would be a similar experience.

Look, if you're going to write an autobiography, you need to have lived a pretty fascinating life. Politicians or high-up members of government, or people that have had a huge impact on the world, they tend to have really great autobiographies. So, who are you Amy Poehler? You were on a few TV shows and you had some kids? Doesn't it seem a bit pompous to write a book about oneself?

Tina Fey was in the same camp, just someone who was on television and had some kids, then decided to regale an audience with her various life experiences. And remember, Fey and Poehler are not people who even lived long lives and can thus offer wisdom of the ages. They're in their forties.

So when it comes down to it, these are both authors who really don't have much reason to publish an autobiography, and the cards are stacked against them in that it's almost impossible not to come off self-important. But Fey gets away with it, whereas, in my opinion, Poehler does not. Why?

The answer is simply, Fey's book is funnier. I'm not saying Yes Please is some kind of boring slog or that it's overly serious. It's a funny book, with lots of interesting little tidbits about Amy's life and career. I enjoyed a lot of it, but I think when all is said and done, if you're a 40-year-old comedian whose contributions to the world can be collected on a DVD shelf, you have to reach a particular threshold in hilariousness, and Fey just barely passes that threshold whole Poehler just barely does not.

So, overall, it's fine. If you really like Bossypants, there's a good chance you'll enjoy this. If you're a fan of Poehler in general, you'll definitely like it. Personally, I struggled to get through it a bit, and it didn't help that Poehler basically begins the book complaining about how hard it was to write and how unpleasant she found the whole experience - a fact that not only is brought up repeatedly through the book, but honestly just shows in the writing anyway.

Fey and Poehler are kind of joined at the hip - they hosted Weekend Update together, a lot of their movies star both of them, they host awards shows together, and so on. But I've always gotten this weird sense that Amy is the Funshine Bear to Tina's Grumpy Bear. Poehler seems to counterbalance Fey's dry sarcasm with a more earnest positivity. I could see preferring this book to Bossypants if you're generally a more positive person, but I like Fey's style and edge a bit more, and thus her book more as well.

Ever hear of the Baader-Meinhof Phenomenon? It's the name given for that weird feeling you have when you learn a new word you've never seen before, and then all of a sudden you're seeing it absolutely everywhere. It seems like every e-mail and every TV show is using this word, and you wonder to yourself how you managed to never notice it before, since it's all over the place now? Or maybe you start looking at a new car and researching it, and all of a sudden it seems like everyone on the road is driving that same car?

I had a very similar effect with this book. I've been a Java programmer for over a decade, but never really been terribly concerned with performance, or the internals of the JVM. I try to write good code in terms of using hashmaps and whatnot to do lookups in constant time rather than O(n) time, but microoptimizations were never my thing. I never really felt like it was something I needed to care about, I never really noticed any performance ISSUES in the products I've worked on during my career. But then whenever I'd finish a chapter in this book, I'd notice that the error messages the chapter mentioned, or the kind of things you might notice when performance is degraded started popping up. Within days of finishing the chapter on the Java Heap, we started experiencing Out of Memory errors on some nodes in our production cluster. I recognized the error messages from the book, and knew what tools to reach for because of it as well. After reading the sections on Threading and Java SE Optimizations, I immediately noticed us doing some goofy, ill-advised things in our code. But the out of memory errors had been happening for months I think, and the code I was noticing had been in place for over a year. This stuff had been all around me, and I just wasn't seeing it. The Baader-Meinhof Phenomenon in action.

Truth be told, this book was a bit of a slog to get through. I started it over a year ago, and the material is just so insanely dry that it was a battle. I'd rate myself maybe a 7 out of 10 in terms of interest level in stuff like JVM internals, flags, garbage collection algorithms, and so forth. I like systems stuff, I usually attend low-level system JVM type talks at conferences, but I still found the book, especially the first half, so incredibly dry that I could barely push my way through it. While talking to some buddies about this book, I estimated each chapter's length around 60-80 pages, and then when I checked it turned out most were only around 30 pages or so. Like a 1.5-hour movie that feels like 4, this book is almost punishing.

Don't get me wrong, it's full of useful information - in fact the degree to which it is densely, densely packed with information almost contributes to how dry it feels, since you can't read any part of it quickly due to how information-dense the pages are. I learned an absolute ton from this book and highlighted pages and pages worth of notes, but if you wouldn't give yourself a 6 or 7 out of 10 (or higher) on the scale of general-interest-in-JVM-internals, I think you probably stand no chance at making it all the way through the book.

If this kind of stuff is your cup of tea, definitely give this book a shot. I think it's the most up-to-date (it talks a lot about Java 7 and 8) of all of the books with the words "Java" and "Performance" in the title (I know of at least 3) and I think it's meant to effectively deprecate the others. If you're experiencing performance problems, or hell even if you're not but you want to be the person on your team who can fix them when they inevitably do arise, it's worth reading for sure. Just, be aware that you'll really have to like this kind of stuff to get through the whole thing.

You're wasting time reading this review, you could be reading this book instead.

Release It! is one of the most important books I think programmers can read, easily as important as the oft-cited classics like The Pragmatic Programmer or the GoF book. Release It! isn't about writing super-spiffy code, or object-oriented design, but it should drastically affect how professional programmers write their code. It focuses on what engineers need to do to get their software into a state where it can actually be deployed safely in a production environment. It covers patterns and antipatterns to support (or subvert) stability as well as capacity, and the section of the book covering this is simply excellent. But then it goes beyond that to also discuss Operational enablement. Even if you're not into DevOps, and don't want to really be involved in DevOps work, this book gives you the tools and tips to do what aspect of DevOps is the purview of pure developers.

Nobody who writes production enterprise software should write another line of code until they read this book. I honestly can't give it enough of a glowing endorsement. Like any other patterns book, a great deal of it will be familiar to people who have been in the industry for a while, and have come up with (or encountered) its principles on their own. But I guarantee, if there's a single thing in the book you haven't seen before, it'll be worth reading the entire book, pretty much every section is gold.

My only complaint about it is that Michael Nygard has a tendency to go on randomish tangents, especially when talking about "case studies," which generally come off as the author trying too hard to convince the reader he knows what he's talking about. A lot of these stories are about things he personally encountered in his career, and how he fixed them, and each one has a weird arrogant quality, it's a little offputting to be honest, like Nygard is almost bragging. I get that these sections underscore the value of the ideas in the book, but there's something about how they're written that comes off boastful, or irritating in a way I can't quite put into words. What's more, the book STARTS with a particularly long one of these kinds of stories, making it kind of tough to get into the book. I actually tried to read it years ago and gave up on it very early. Only recently did I decide to revisit it and keep pushing forward (based on a co-worker's recommendation) and I'm extremely glad I did.

I highly, highly recommend picking up this book and reading it cover to cover. It's a struggle at first due to the unfortunate decision to start it off with one of the most annoying sections of the book, but I implore you to power through it and keep reading. It's worth it.