User Profile

"Nonviolent Communication" might be a bit eyeroll-inducing, the concept of "When you X, I feel Y" statements are a cliche at this point. But push through it, this book is invaluable in improving communication skills.

I'm not sure any book has had as much of an impact on my ability to communicate effectively with other people. True, it's not "in my nature" but I'm hoping to fake it until I make it with this stuff, because I've noticed a marked difference with how coworkers seem to view interactions with me after employing the skills this book teaches, not to mention improved communication with my wife and even better parenting with my children.

It really is a game-changer, it takes work to think and operate this way but the payoff is huge. Hopefully with time this will become second nature to me (fingers crossed) but until then even being slow and deliberate with how I talk to people (including myself) to make sure I'm following the steps in this book is worth the payoff, everyone seems to really enjoy this manner of communicating, but I don't feel like a pushover. Even though my wife hasn't read the book, I can guide her through the feelings-based thinking when she's struggling with other people and it winds up really being useful.

The book itself is a little long-winded, it takes a bit too long to get to the point at times and you can feel things being repeated over and over. This may be to ensure that all readers have a chance to understand everything but it can be slightly frustrating when you feel like you get the material and want to keep moving on. Nonetheless this book is essential reading, I can't think of anyone I wouldn't recommend it to. Approach with an open mind and you'll be better for the experience.

I'm not going to say much about the "fable" format - a lot of these reviews seem not to be familiar with this particular style of book, and a reacting negatively to that. Yes, 75% of this book is a work of fiction with characters and dialogue that serve as a way for the author to convey his ideas in the format of a story, and yes as with The Phoenix Project and other similar Business Novels, the quality of this fiction is fairly hit or miss and it's mostly lots of straw men that a perfect examples of the principles the book wants to get across. If this format sounds like it would bother you, you won't like this book.

Now, as to the actual content - I think it's quite good. It's a deeper dive into the concepts of "The No Asshole Rule" which is basically to suggest that making "cultural fit" an important part of your hiring process is a good idea. Not just to implicitly avoid hiring assholes (this book is fond - very fond - of the word "jackass") but to make the fact that you're doing so very deliberate and well-known within your organization, as well as telling clients and partners so they should know to give you feedback if they wind up working with an asshole in your organization, and to tell prospective candidates as well so that they know that if they are an asshole, they'd be miserable in your organization and drop out. This is all really solid advice, and I think it's a good idea.

One needs to be careful about hiring for "cultural fit" in general, it's an easy mechanism to hurt diversity and inclusion, often it becomes a shorthand for "hire people like me" which leads to uniformity in workforce. That's why I think it was great for the book to, more than similar books, spell out exactly what makes someone a "jackass" and how to look for them while hiring as well as look for them in your organization to either help them improve or remove them. So much comes down to spelling out expectations for your candidates and employees; simply making it clear that you actually expect people to interact with each other in a respectful and compassionate way rather than just hoping people do (and making it clear that, if you don't, you're gone) goes a long way.

To get specific, Patrick Lencioni enumerates 3 primary positive traits to look for in candidates. He suggest they be:

1. Humble
2. Hungry
3. Smart

"Humble" can refer to more than thinking little of yourself - it means not thinking of yourself that much at all. Undervaluing your own contributions isn't humility, it's low self-confidence. The book spells this out a bit, and I think it's great advice, nothing to disagree with about looking for your employees to be Humble.

"Smart" refers to being socially smart, and I think the book's use of simply "Smart" to have a one-word trait is lamentable. "Socially Smart" is much clearer, and more inline with what the book is going for - this is the primary "Jackass" quality that keeps being referenced. Basically just, be polite to people, disagree in a respectful way, don't be hard to work with. As someone in the software industry, I see far, far, far, far, far too many organizations that are tolerant of behavior that's not socially smart simply because the perpetrators are other kinds of smart. Delicate Geniuses who are too important to fire, and are then empowered to act like raging assholes in both subtle and overt ways with no repercussion. I find this to be one of my industry's greatest failings, and I want everyone to read this book simply to give them a chance to understand how important it is you weed out people who aren't socially smart as early as possible, and help your current employees lacking in this area become more socially smart (or fire them if they can't hack it).

"Hungry" is my biggest sticking point with this book. As the author talked about looking for Hunger, I became worried this could be easily reduced to looking for people to work after hours or on weekends. Sadly, my concerns came to pass as working outside of 9-5 hours did indeed become a good way to figure out and evaluate who is and isn't hungry. In fact the author even argues that a candidate who asks a lot of questions about working hours in the interview is likely not a Hungry person, and may be avoided. I find this to be a completely terrible idea - I think work/life balance is extremely important to prevent burnout, and it's not hard to value passion in one's work while still balancing hobbies, family, and personal life. The fact that I say this, as far as I can tell, would exclude me from Lencioni's hiring processes. I do ask about work/life balance in interviews, I find many companies in my industry have a terrible attitude toward balance and I like to sniff them out when I interview somewhere. Lencioni even makes a point that someone who is passionate about their hobbies is likely to be less passionate about their work, and may not be an ideal team player. I just find all of this reasoning to be very dangerous, and while I appreciate the sentiment of wanting to find people who are passionate/hungry, the specific advice given in the book to find those people I think is pretty bad.

Overall I liked the book enough to overlook its shortcomings. Even as I disagree with the author's suggestions for sussing out a full 1/3rd of the ideal team player traits, and even as I cringe at the out-of-place preaching for Jesus (yes it's in there), I still find the rest of the contents of the book super valuable and would recommend reading it.

This book was a little disappointing, not because it's bad but because it wasn't quite what I was looking for. The book advertises itself as a collection of solutions to problems people encounter when embracing remote work, but more than anything else the problem it solves is "how do I convince management to embrace remote work?"

Most of the book is structured as a work of persuasion, something that's intended to convince people to go remote. A lot of it seems geared toward executives and managers, or giving lower-level employees ammunition and counterarguments for common objections. That's all well and good, but as someone who is already on-board with remote work and pretty experienced doing it for over 5 years, I don't personally need any convincing - I need help.

Going remote poses unique challenges and difficulties, and I thought the book might help give me some practical solutions to issues I've had with remote work as someone who prefers it and wants to be more successful with it. There's a little of that in the book, but it's mostly meant to persuade. I decided to read the book because I'm joining a new team that is fully distributed and having some struggles, and I was hoping this book would help me help them - but that's not really what's in here.

That said, since reading the book by total coincidence I've found myself involved in multiple conversations with people skeptical of remote work, and I used multiple arguments and examples I got directly from the book during the section of the book I felt like I wasn't getting much from, so maybe it's better than I give it credit for.

If someone is on the fence about remote work, this book is great. If you want to go remote and you need help convincing your team, your manager, or your company executives, this book is great. If everyone is already on board with remote work and needs practical solutions to issues that arise, the book is... fine? I guess? It's mostly fine.

You need to read this book. Actually, scratch that, your manager needs to read this book, and his or her manager as well. All the way up the ladder. This is more than just a book, it's a manifesto for sanity and calmness at the office.

Nearly every (two-page) section is gold. It reads quick, it's well-written, there's no extra fluff or padding. Just straightforward advice for how to run your company and culture to maximize happiness at the office, written by people who have been successful. This book puts into succinct words exactly what I've been saying to various people for years, it's so validating to see the co-founders of a successful business reiterate what I keep telling people, as well as giving me new annoying things to tell people who won't listen.

This book is a must-read, I recommend it to absolutely everyone. Even if you don't think it's "crazy" where you work, it's probably crazier than it needs to be. It's going to be a sad day 15 years down the road or whenever that Basecamp goes out of business and this book will just seem like a graveyard of great ideas. Please read it now while it still seems like good advice so that your organization can add to the voice it represents.

The day I finished this book, I opened up my computer and saw that Hope Hicks, a "character" who is central to a good portion of this book, resigned. The day before, Jared Kushner - who is mentioned on nearly every page - had his security level downgraded. The Mueller investigation is still ongoing, and the future of Trump's presidency is very uncertain.

The reason I mention all of this is that the fundamental issue with the book is that, frankly, it was written too early. It's the first section of a nonexistent book called "The Downfall of the Trump White House." It feels incomplete, like the book ends when stuff is just getting warmed up, and the book would be stronger if it was written in the aftermath of Trump, or at least when the Russia investigations (which take up about half the book as-is) are completed. Narratively, it's unsatisfying to just end the book abruptly in the middle of all of these insane goings-on. I realize that Michael Wolff basically had this info and could sell a lot of copies of the book in the heat of the presidency rather than in the aftermath of it, but it just seems woefully incomplete.

Overall it's a good read - a bit rambly at times and of course I have no way to verify how accurate it all is, but it's definitely an enlightening account of this accidental president. Worth reading, I hope there's a sequel when these 4 years are up.

I found this book kind of a struggle to get through. It didn't read like a lot of other patterns books, in which it often feels like an expert is presenting patterns and you sort of wonder if the authors are the people who designed or came up with the patterns, but more like a nonexpert that is trying to catalogue patterns they are seeing for their own notetaking purposes. It feels kind of like a student Literature Review paper in a way, nothing ever really coalesces into a coherent educational book. It's hard to explain I guess, but suffice it to say that this book didn't really "work" for me.

It's got many issues throughout, a handful of grammatical mistakes, and technical issues ranging from misleading or confusing to outright incorrect. The example code is often a bit too short, it never really "illustrates" the point of a particular pattern, but instead seems to just be the bare minimum amount of code to implement a pattern and move on. Every section of each pattern just seems to be as terse as possible, almost like the author was unsure of what he was saying, and didn't want to risk being incorrect by saying any more than was strictly necessary.

The book's strongest section was its last, on Functional Patterns. This section was good but also contained some incorrect statements. One thing I found particularly odd is the mathematical approach to discussing these functional patterns (despite simple mathematical mistakes like incorrectly defining associativity) - it never really creates the bridge between academic functional programming and Scala. As a simple example, the author builds up definitions of Functor, Applicative Functor, and Monoid, then illustrates how a Monad is the combining of those three things. This is a common explanation/definition for a Monad within the world of pure functional programming - but Scala's author defines a Monad as anything that defines map() and flatMap(). I think it would have been nice to show how these definitions of Monad actually mean the same thing, illustrating how the methods can all be generically defined by relying on those, but the book never creates that bridge. Even the names of functions used like 'fmap' and 'join' are a bit strange - the entire book uses Scala but Scala's version of 'fmap' is typically just called 'map'. It's almost like somewhere out there there is a Haskell book called 'Haskell Design Patterns' which is character-for-character the same book, but then the author realized the book might get more eyes if he just changed all the code examples to be Scala and otherwise changed nothing else.

Compare this to the classic "red book" Functional Programming in Scala by Bjarnason and Chiusano, which covers similar material but is so perfectly in harmony with the Scala language itself that a good portion of the book is rebuilding a number of components in the standard library from scratch.

The weakest section of the book is by far the Gang of Four Design Patterns section, in which all of the classic GoF patterns are covered, but not really in a way that takes advantage of the fact that Scala is a functional programming language. Like rather than each pattern being something akin to "the purpose of this pattern in an OO language is this, so we can accomplish the same thing by doing that in a functional language", they're just straighforward GoF implementations in Scala. In other words, they're the kind of code you see when a Java programmer just translates working Java code directly into Scala without regard for FP as a paradigm.

The only other section worth mentioning is the Code Reuse Patterns section which is often decent, but contains coverage of 3 patterns for dependency inversion that were covered in just the briefest, most cursory way imaginable. Once again, it almost felt like it was being sped through so as to not make any additional mistakes, as if it was written by someone that didn't really feel confident in the material and didn't want anyone to notice.

Overall this book doesn't feel like it was meant to be read by someone looking to learn anything. It seems like a student's semester project that was published by Springer without being copyedited. Like someone's personal Wiki page got printed out. It feels very minimal effort, not like the kind of book an author writes with their audience in mind and a goal of educating. There are some other patterns books, like the aforementioned red book (not strictly a "patterns book") or Functional Programming Patterns in Scala and Clojure by Bevilacqua-Linn, which are vastly better ways to spend time.

I think the Scala programming community is desperate for a fantastic patterns book on functional patterns using the language but so far every book I've found falls a bit short. Of them, this one falls the shortest. Skip it.

This book contains a lot of great information for Scala programmers, but it's kind of buried in a frustrating reading experience.

A lot of what you'll learn in this book is that many of the ways you use Scala normally are slow, I particularly enjoyed learning how Option, something I take completely for granted but has the potential to hurt performance in critical areas. It's not just a complaint either, the author basically offers an alternative Option implementation that doesn't suffer from this (and also, isn't as expressive, and is basically Java). There are also some great sections about Free Monads and an absolutely fantastic coverage of the differences between Scala collection types and performance. It's a lot deeper than you might think, it's not just "oh this one is O(n) and this one is O(logn)", it's extremely detailed and informative.

The main issues I have with the book are the writing style and the example used for illustration. The writing style is fluffy and feels both padded and out of place. The author basically takes the reader through almost a choose-your-own-adventure story where "you" have started a new job, and you're talking to people to understand their performance issues, and helping them out. They all have names like "Dave from so-and-so department" and it just feels totally unnecessary. He gets in some cracks about "you" avoiding scrum masters to get real work done and how happy you're making this or that group and increasing the company's bottom line. One one point, "You double-check with Gary to confirm that MVT strategies are thread-safe. He responds with a thumbs up emoji, which gives us the green light to parallelize execution of trading strategies." It just feels so out of place, it kind of reads like the author wrote a dry, matter-of-fact book and then someone told him to make it more of a story to keep readers engaged, and then he shoehorned all of this stuff in like it's The Phoenix Project. It's kind of grating.

The other gripe I've got is that there's a single domain example used as a throughline through the entire book: a high-volume stock trading application. I recognize that this is a fitting example because these kinds of applications really REALLY care about throughput, latency, and performance concerns - I have a buddy who used to work at one of these places and they universally insist on using C++ with a lot of assembly callouts to get nanosecond improvements. However, if you basically know fuck-all about the stock market, a lot of the terminology and domain specifics might go over your head, and there's little to no attempt to explain any of it as the author assumes a base level of familiarity with these concepts. This is probably a personal failing on my part because I hate the stock market and I don't mess around with it much, but I found myself occasionally struggling to understand exactly how the domain worked, and since it's critical through the ENTIRE book, this affects the whole reading.

This book is definitely worth skimming, but I'm not sure if it's worth a full sit-down read. I think the sections can largely be read independently, they rarely build on each other so it's worth going through and picking up the areas where you're particularly interested in performance. If you do Scala full-time, it's definitely worth flipping through if only to find out what kinds of things to look out for, so that you can circle back to the book later on if you encounter particular performance issues.

I really liked this book but also was a bit disappointed by it. I'm a huge fan of Robert Martin's work, I've read his previous books and I love Clean Code and The Clean Coder. Based on the title and artwork I had kind of assumed that this was just the next step of the Clean Trilogy, this time focusing on architectural concerns.

It is kind of that, but it's mostly not quite that. Really, this book is a lot of background information to understand the "meat" of the book, and the meat of the book is Martin presenting his Clean Architecture pattern, which he proposed in 2012 and has been presenting and training a lot on: 8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html

In that way, this book feels much more specific than Clean Code or The Clean Coder. While those two books are general advice for software professionals, this comes off more as an extended design pattern book that only covers one singular pattern. It's presented as The Only Right Way, and while I personally agree with Martin's perspective and his loathing for framework-heavy architectures, it was a bit disappointing that the book was mostly a very deep dive on a blog post from five years ago.

The "buildup" stuff is actually more interesting. It's about applying SOLID principles to architecture and I really enjoyed this section of the book, I felt like I finally grokked dependency inversion at a component level, and there's a lot to apply to architectural problems I face. That section of the book feels very general, though like most of Martin's work it's yet another rehash of SOLID and talking about FitNesse, two things he's gotten a stunning amount of mileage out of to a point where you kind of wonder if he's ever done anything else (he has, but boy does he return to these wells a lot).

In a way this is two shorter books smashed together. One is Clean Architecture, a book about building clean architecture using SOLID principles (and a few new ones). The other is a book about the Clean Architecture Pattern, a particular way to architect systems that shares a lot with Allistair Cockburn's Hexagonal Architecture pattern. These two concepts use the exact same name to, I think, intentionally get readers to conflate the two concepts as one and come away feeling like Martin's proposal is the only possible way to architect a system in a way that is clean. But one of these things is "clean architecture" and the other is "Clean Architecture", and it's often hard to see what is what. This is by design, I think.

In any case, the book is really good and I got a lot of out of it, though it wasn't what I was expecting really. The first half (or so) of the book feels like 80% rehash of stuff I've seen from Martin before, with 20% extremely good and useful new stuff. Then the second half of the book is a completely different topic presented as the same topic, which I enjoyed but I can see a lot of readers being turned off by. I still would recommend the book and I think it's worth reading for anyone who feels like "architecture" is part of their job.

This remains one of the most important books software engineers can read. The second edition is even better than the first, updated to fix a lot of the "outdated" criticisms the first book gets, incorporating the modern DevOps movement, microservices, and modern technologies used in software engineering.

I really just can't say enough about this book. It's required reading. If you're responsible for code that runs on networked production systems, failing to read this book should be a fireable offense. Skipping "Release It!" is professional negligence. Stop what you're doing and read this before shipping another line of code.

Release It! is all about how to build cynical software, and once you start down that path you find that you can no longer think any other way. This book changes you and your career, it's just phenomenal. Even if you think you know everything in it because the patterns and practices it describes have become widespread, it's still worth reading.

The second edition fixes - or at least somewhat improves - every minor complaint I had about the first edition, and reorganizes the information, adds a lot of great new sections, and removes outdated cruft. It's superior to the first edition in every way, and that was a 5-star book for me.

I've been working with Scala for around 6 years now, and finally left the job where I learned it for another job also using Scala. I'm a huge fan of unit testing and test-driven development, but at my previous gig we all used a scala testing framework and mocking framework developed in-house, meaning 100% of my scala testing experience was with something that I'd be unable to transfer to the new job. Testing in Scala seemed like the perfect book to round out this missing skillset for me.

Unfortunately, the book is fairly disappointing. Frankly, it contains no more information than reading the tutorials and documentation for ScalaTest, Specs2, and ScalaCheck. In fact, I think the book contains LESS information than those tutorials and user guides, it only barely covered writing custom matchers and left out a lot of more advanced material.

I guess I expect a bit more from an actual book, maybe cover the API basics and then get into usage patterns, best practices, advanced usage, and so on. If you're charging someone money for the words, it seems like it should contain more information than what's free on the web site for the technologies being covered, I think. Hell, I could have written this book just from following those tutorials, having never worked with or achieved expertise with the technologies in question. There's no meat here.

Whenever programmers ask other programmers for book suggestions, there's always some smartass that says something like "The Art of War" because of blah blah blah about corporate politics. Hoo boy you're clever, you suggested a non-programming book, way to not play by the rules. You really march to the beat of your own drum there, slick.

Similarly, I constantly see "The Design of Everyday Things" suggested in these kinds of conversations. I think it's supposed to give engineers great insights into design and how humans interact with objects around them. This is supposed to change our outlook for the software we build for people.

Well, I don't think it did that at all. Really, the only thing to take away in that regard is "think about how people use your software". In other words, I think a great many UX-centered books are vastly superior in this regard.

That's not to say this book is bad. In fact, I imagine there are people reading my review right now thinking "who gives a shit that this guy is a software engineer?" Indeed, this book is great. Very enjoyable, and very informative. It made me think about every day objects I've never even given a second thought to. There's an entire section on sink faucets that blew my mind. But ultimately, the book is really about exactly what the title says it is, the design of everyday things and objects. There's some hinting at a greater, broader meaning than this, but it never comes to much.

Definitely a great read, worth it for sure, but don't buy into the "everyone who makes software should read this book" hype.

I'm starting a new job soon, decided I'd give this a read. It's short and sweet, easy to get through in a single sitting.

The book definitely seems outdated, even antiquated in many ways. Some of the advice feels like something you'd hear 20 or 30 years ago. I especially like all the attention to cleanliness and well-manicured fingernails, that feels super relevant in a world where my coworkers have sleeve tattoos and 5-inch ear gauges.

The book also suffers from broadness. It's meant to apply to any new job, blue collar, white collar, office, bagging groceries, whatever. In that way, it often felt too broad to be terribly useful. A lot of the advice is about dealing with your manager, getting help, asking for guidance and evaluation from them, etc. I can see this being useful if you're the newest waiter at a restaurant or something, but as a software engineer I assure you that my supervisor will want me to be much more self-sufficient than this, and a lot of it would be seen as a nuisance. I particularly laughed at the sheets at the end you're supposed to print out to go over your first 30 day performance with your manager, I imagined handing that to my boss and having them just laugh me out of the room. It stinks of desperation and a lack of self-confidence.

Overall, a useful read, I'll definitely be keeping in mind in my first 30 days. I liked the weekly goals, and what to focus on each week. I particularly like the idea of focusing my first week mainly on personal relationships, and my second week on actual job performance. This isn't in my nature and I think it's a good idea. My natural inclination is to get in there and start kicking ass immediately to prove I was a good hire, but the book basically convinced me this is a super-stupid thing to do because it ignores the value of creating personal relationships at work, and it creates an unsustainable pace. I'll definitely be taking this advice to heart.

This is a weird book. When you're reading it, it almost seems like it's some kind of ancient tech book, like something from the 80's, where people were just figuring out how to build software and patterns were first starting to emerge. Kind of like when you read The Mythical Man Month or The Structure and Interpretation of Computer Programs, it's talking about things you recognize but using terminology that has since been replaced, so it serves as something of a strange time capsule from when it was written.

Except, this book came out in 2012. 4 measly years ago. When you read it, it constantly refers to things that you're likely to have seen if you've done any service-oriented development at all, but it takes you a minute to realize the book is discussing something you already know because it's using terminology you don't. For example, the second pattern, "Active Service", once you finally get through the section on it you realize it's just talking about a service frontend that calls multiple other services. That's an "Active Service"? I've built dozens of these things and I've never heard it called that. You go through the entire section on the "Decoupled Invocation Pattern" and it all seems familiar and then suddenly you're like "wait, are you just talking about asynchronous services?" You go through the "Service Instance" section and get to the end and ask "wait is this just a Cluster?", you get through Virtual Endpoint and ask "wait you mean a Load Balancer? Why the hell are you giving everything such weird names?"

It's kind of nice to have everything gathered together in a single spot, but I don't think there's much to learn here if you have any experience with SOA at all. A lot of "patterns" books tend to contain things you've sort of developed or done on your own, but they usually have some eureka moments as well where you see something new. In SOA Patterns's case though, it all seemed pretty introductory, like I don't think you could get through a "Introducing SOA" type book without covering 100% of the material in this book, so all this book really did was add goofy names to a lot of it that nobody else uses. Which, given that the entire point of patterns is to give standard terminology to developers to help communicate, I think SOA Patterns actually subtracts more than it adds.

The organization of the book leaves much to be desired as well. Even with the sections clearly labeling "problem" and "solution", I still often struggled to even figure out what some sections were trying to show me in terms of problems that specific patterns solve. There's even an entire chapter for "Message Exchange Patterns" which actually only contains a single pattern, Saga.

The weirdest section of the book by far was 10.1, "REST vs SOA", yes you read that title right. Versus. I had been suspecting while reading the book that the author's notion of SOA was limited to SOAP and XML and this section confirmed it, seeing REST not as a particular way to DO SOA, but as a competitor to it somehow. Again, I'm not saying that this wasn't, at some point, a common viewpoint, but it once again makes the book seem like something released a decade ago, not a mere 4 years.

Overall the book just seems hopelessly out of touch or out of date at this point. It discusses the Service Bus pattern, something that most shops are trying to move away from for the most part. An entire book on service-oriented development and there's not a single mention of the latest-and-greatest in that space, "microservices". The closest thing to a mention was "nanoservices" which you can find in the "antipatterns" section of the book.

Skip it, if you're even familiar enough with SOA to be interested in a patterns book, you know everything inside. And what you don't know, the book doesn't cover at all because it reads like a book that's a decade out of date.