Full Disclosure: I was a technical reviewer for this book
Your Code as a Crime Scene has a lot of extremely interesting ideas, and for those alone it'sFull Disclosure: I was a technical reviewer for this book
Your Code as a Crime Scene has a lot of extremely interesting ideas, and for those alone it's worth reading. The essential idea is exactly what the title says - this seems weird or impossible at first but I assure you, the title is genuine. Effectively what this book is about is using forensic techniques to figure out which spots in a large code base are most in need of improvement/refactoring.
There are lots of different kinds of things to look for and visualize in your code to help figure out dangerous areas in it, and the book takes you through each one, how it works, and how to get at the data to find these areas. It's really, really interesting, in fact it's one of the most interesting books on software I've ever read. At a previous job, we did something similar to find good candidates for our weekly Refactotum meetings - it was a script that used Git and our ticketing system to find files that were frequently modified, very large, and the source of a disproportionate number of bugs - the function for a evaluating the sort order of the files was kind of complex and involved, and I was actually pretty proud of helping develop it because it was such a neat way of viewing a codebase. I had no idea that some day there'd be a book all about stuff like that, with even more techniques. Really cool.
My main complaint with the book is that the author frequently uses a tool he wrote, code maat, to perform the analyses. I'd have much preferred more stress on the actual methods - I often came away feeling like I'd be unable to employ these techniques without code maat because I didn't get enough detail on the thinking behind the tool. In fact, I think the book often comes off as a code maat tutorial that was renamed. The other thing that bothers me is that often the code base analyzed to illustrate one of the book's ideas is the code maat database itself. This just seemed so self-referential to me, weirdly meta or something. It made it hard for me to really understand things - the code itself was already one step removed from the ideas, and then the codebases being looked at wound up kind of having the same leap. It's hard to explain, but the book would be much better if it analyzed popular open source projects that people use every day, and personally I'd have preferred less involvement from code maat itself - maybe a little paragraph or section at the very end showing how code maat could be used to automate a lot of the more manual work that the previous pages employed.
Overall, I actually highly recommend checking this book out - especially if you work on a large codebase and are concerned about its quality. There are lots of cool ideas in the book to help you find the biggest "bang for your buck" areas to improve the codebase....more
Meh, it's fine. Covers some basic stuff, as a first-time dad-to-be I found it useful and informative, but I have no idea what I'm doing so pretty muchMeh, it's fine. Covers some basic stuff, as a first-time dad-to-be I found it useful and informative, but I have no idea what I'm doing so pretty much any book will hit that mark.
The book is very light on details, but it's also very short and very easy to read. It took me two bus rides and I was done with it. Good way to tell the wife (or FPP as this book likes to call her) that I finished a "Dad Book" so that I don't look like a lunk....more
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 FacebData 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....more
I'm a big fan of the #NoEstimates movement. I've seen multiple talks, I fight against "story points" and other forms of estimate waste whenever possibI'm a big fan of the #NoEstimates movement. I've seen multiple talks, I fight against "story points" and other forms of estimate waste whenever possible, and I trumpet the "new" movement in agile of having no estimates. I recognize that estimates are a tremendously bad way of achieving predictability in software development - in short, estimates simply do not accomplish what they are meant to accomplish, and are thus a total waste of time. But I do have a dirty little secret... I don't really have an alternative.
I go around various places of employment saying that estimates are a waste of time, and they are, but when stakeholders, product owners, and business people try to get me to explain how they're supposed to get a sense of when products will be delivered without them, I wave my hands and mutter something about how you can achieve greater predictability using real data and tracking your team's throughput, cycle time, and lead time. I know I've heard people say this, and it makes sense to me, but I don't really know the specifics, and I've had a hard time finding them. I seem to get away with this nonsense simply because, as it turns out, businesses don't really need predicability as much as they think they do. Marketing teams and salesmen tend to work better when they're selling or marketing what's already done, rather than what's going to be done "soon". And business stakeholders, for all the claims to the contrary, never actually seem to use the relative estimation/cost for various projects to actually decide what projects to do - it always seems like there's a "most important thing" that needs to be done no matter what. We have an industry where tons of people are convinced that they need to know the exact date features are going to be done, but my experience has shown me time and time again that they actually don't need that, most of the time.
Notice I keep saying "most" or "usually". There definitely ARE times when companies need to get a sense of when something's going to be done. I know estimating doesn't work for that purpose - I'm fully convinced and on board with that idea. But I've been long seeking an understanding of how to achieve it for those situations when it's needed, and I've mostly gotten away with simply not having to know. My hope going into this book, which presents itself as largely the complete guide to the #NoEstimates movement, was that it was going to answer this for me.
In the end, it still felt pretty hand-wavey, I don't think I came away with what I wanted. The book plays a lot of lipservice to the notion of predictability without estimates, but I felt like it largely does what I keep doing, which is kind of deal in vague terms and assure the audience that it's possible, without really making someone understand exactly how. The final two chapters deal most directly with this question - everything leading up to it is mostly about why estimates are worthless and how much better off you'd be without them. But the last two mostly attempt to deal with predictability and they do an admirable job, but still felt a tad vague. There's quite a bit about how one can measure progress and know if your project is going off the rails, which is helpful I guess, but not what I was looking for.
Agile books can be kind of "culty" in nature, like they come across like someone trying to convince you to join their religion. This one is no exception, a tone that I felt was exacerbated by the unfortunate decision to write much of the book as a hypothetical fictional novel. There are characters working jobs and trying to deal with problems, and of course there are super-smart characters who explain the principles of the #NoEstimates book, and of course they wind up being completely right. One particularly hilarious scene near the end has the big boss character excitedly telling the main character, Carmen, that he's never seen anyone work so well, and he demands that she and her #NoEstimates buddy (Herman, get it, "her man"?) come work directly for him. It's so dorky and ridiculous, kind of has the same vibe as an infomercial where someone can't open a soda bottle right until Billy Mays comes in and says he's got the perfect product that will solve all there problems. It reminded me a lot of how The Phoenix Project was written, but at least that book stayed consistently in "novel" mode, not switching back and forth. At one point, Herman actually gives Carmen a copy of the #NoEstimates book in which they are characters, Neverending Story style, wrap your head around that one.
But here's my fundamental problem: #NoEstimates, the movement, is something of a new agile cult, and I know it - but I'm WAY bought in. Estimates are a complete waste of time, and I'd rather simply avoid them entirely. If this is a religion, I'm a devout member, even though I don't really understand all the sacraments or whatever. So even though I didn't feel like this book really helped me come away with how to answer the "okay smart guy, how do I get predictability then?" question, I'm still way, way bought into it. Like I said, I think people need these dates/predictions far less often than they think they do, and in my opinion it's better to simply say "I don't know" than to outright lie, which is what estimating is.
I recommend everyone working in this space read this book, at the very least to absolve you of the notion that estimates are valuable and worthwhile things to produce. I loved most of the book, but I had to knock a star off because it ultimately DOES fail to provide the sort of "silver bullet" I'm looking for. I'll have to keep searching for the book/post/video/lecture/conference that actually helps me understand how to have predictability without estimating - I mean, I'm sure it's possible, using cycle times and throughputs and whatever. Right?...more
I know I say this every time I read a fiction book but I'm not much of a fiction reader. I generally find fiction written in a way that irritates me -I know I say this every time I read a fiction book but I'm not much of a fiction reader. I generally find fiction written in a way that irritates me - too much describing by an author in love with his or her own writing. Simple descriptions of a location or an object go into far too much detail, droning on and on with flowery prose that I feel like is wasting my time.
But, I loved The Martian movie, and people keep raving about this book so I gave it a shot. I really wound up enjoying it a lot - the vast majority of the book is actually just log entries from the main character, Mark Watney, so the thing that annoys me most about fiction was entirely avoided. All of the writing seemed crucial, and the only time it went into "unnecessary" detail were the explanations of the science behind Watney's decisionmaking. I had no problem with this, because I'm a nerd.
In fact, this really isn't much of a "novel" in a lot of ways. The main character doesn't grow or change, nobody really has anything like an arc. Like the movie, this is just a science geek joyride - nerding out on science and space and problem-solving complex challenges on Mars. It's great.
I found pretty much every part of the book that WASN'T a log entry from Watney somewhat annoying - prose sections on the other ship, or back on Earth, for example. These sections were critical since they gave the reader information Watney didn't have access to (and thus couldn't be in log entries) so I get why they're included, but that doesn't make them enjoyable. Like I said, I really don't like reading fiction much. Luckily, these sections don't make up much of the book - most of it pure science awesomeness.
Anyway, really enjoyed this. I saw the movie first and was worried that I'd find the book boring since I knew what would happen, but there was enough content trimmed out for the movie version that there's still a lot here. If you enjoyed the movie, I highly recommend the book, and I'm really not the type of person who says that about movies and shows adapted from books (seriously, fuck Game of Thrones, the books are exactly what I hate in writing). And if you're into science or space in general, I'd recommend this book to you as well - it's a good time and relatively short and to the point....more
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 tAt 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....more
This is a pretty good book introducing Kanban to teams. There are some overview chapters on Kanban in general, some specifics about implementation andThis is a pretty good book introducing Kanban to teams. There are some overview chapters on Kanban in general, some specifics about implementation and issues that can arise, as well as specific chapters on transitioning to Kanban from Waterfall or from Scrum, and how to make Kanban work in an Enterprise.
I switched to Kanban at my last company, but the various agile coaches and experts largely handled the specifics. I loved Kanban, and tried to introduce it to my next company, but unfortunately that put me in the position of being the agile expert, and I lacked the knowledge to really make it stick. My typical pain points are actually using the process to come up with predictions for time-to-completion of work, which is only worsened by the fact that my last gig was part of the #NoEstimates movement and I can't figure out how to help my product owners and management types know when to expect work to finish, putting me in a position of advocating something that I know works, but cannot actually help make work.
I picked up this book because it was highly rated and very short, so I hoped it could get me up to a point where I'd be able to help my teams be more effective at implementing the kind of process that I have been advocating. It did a decent job of accomplishing this, I definitely know more now than I did (enough to realize how frustrated I am with JIRA as a Kanban tool), but I found the bits on predictive engineering and particularly estimate-less planning (which gets a sidebar mention with nothing else) lacking.
Definitely worth a read if you're interested in Kanban or looking to bring it to your team. The short length makes it an excellent book to introduce team members to Kanban as a 'required reading' sort of thing, and the chapter organization makes it easy to skip chapters that aren't relevant, such as chapters on transitioning from Waterfall (if you're not a Waterfall organization).
I'm still looking for the "perfect" Kanban book that's short, simple, straightforward, and answers all of my questions without presenting Kanban as a magic bullet. Most of these books present a sunshine-and-rainbows view of engineering without getting into the actual issues that can arise in Kanban with advice for how to deal with them, and this book isn't much of an exception to that. I haven't found this theoretical perfect book yet, but so far Agile Project Management with Kanban is one of the better candidates....more
This book has an interesting premise - a former HR person writing a book about companies and HR in particular, basically getting down to the truth ofThis book has an interesting premise - a former HR person writing a book about companies and HR in particular, basically getting down to the truth of corporations even when it's not politically correct. In other words, these are all the things your HR department at work knows to be true, but can't say are true while they work there.
Most of the book is pretty interesting, if somewhat predictable. Basically it just confirms that the worst suspicions you have about corporations are true. There are lots of little interesting tidbits though there are a number of things I flat-out disagree with. One thing the author says is that you should ask for raises and be offered promotions - never ask for a promotion. I totally disagree, I wouldn't have gotten my latest promotion unless I'd asked for it. Every company is different, so take what you read with a grain of salt.
If you're cynical or pessimistic, most of the book won't come as a surprise. Yes, your company age discriminates. Yes, your company fires people by making their work life suck so bad that they leave. Yes, you are never, ever, EVER to trust HR at your company - they are there to protect the company from you, not the other way around. The book does offer some useful advice for navigating around these issues, however.
The final section of the book went on for far too long and was mostly concerned with how to handle a promotion where you start managing people. I found this an odd inclusion - none of the content seemed like "insider secrets" consistent with the book's premise, it really just seemed like an ultra-light "10-minute-manager" type book. It's all stuff that's covered better in other books, it seems like it was included just to get the number of "secrets" up to 50.
All in all, I think this book is worth reading for anyone who works in a large-ish corporation, a great deal of it rang true for me and it offered solid advice in navigating the waters of corporate life through the lens of HR. It's a short book and a quick read, you should be able to get through it on a plane ride....more
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 doI'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....more
I heard about "The No Asshole Rule" in a technical conference talk about building out an engineering team. The notion of the book struck me as simultaI heard about "The No Asshole Rule" in a technical conference talk about building out an engineering team. The notion of the book struck me as simultaneously obvious and groundbreaking. The basic premise is this: we all know that it sucks to work with assholes, so let's not beat around the bush and actually formulate an official company policy to not hire assholes.
It made me think back to so many interviews I've done with various candidates over the years, and the pow-wow meetings after where we tried to decide on hiring or not. I remember one in particular, where we all recognized one candidate had a fantastic skillset, and we felt like we'd regret not hiring someone of his caliber. But there were a lot of coded messages in the discussion as well: "I'm worried he may not be a good cultural fit", "will he be an effective member of a team?" and so on. What we were really asking, though I'm not sure we were willing to say so at the time, was "this guy was kind of an asshole, right?" We wound up hiring him and quickly realizing that he was a dipshit, and he became the first person I've ever seen outright fired at that company. For a time, he was actually part of the interview committee as well, and the book was dead on saying that assholes hire other assholes, because he threw a fit about us wanting to hire someone that he despised. He basically made a "him or me" ultimatum, and we chose the candidate over him. If we'd had the No Asshole Rule in place, we could have more openly discussed his assholishness, and decided not to waste our time.
Now, one struggle I had was thinking, well, I'm kind of an asshole. So how does this affect me? Author Robert Sutton's definition of asshole came in very handy for me in this regard. There are two tests for an asshole. Test One, when talking to the asshole, does the target feel oppressed or humiliated? I'm definitely guilty of doing this, so things weren't looking good. But Test Two is, does the asshole aim his or her venom at people who are less powerful? Ah, good, I'm in the clear. My venom is always directed at equally-powerful peers or more powerful individuals. It's true, I can be very blunt with criticism, and I've on more than one occasion called people out for being unprofessional. I've even used the phrase "professionally negligent" a few times. I'm sure this has made people feel bad, but there's something I appreciate about brutal honesty, and I appreciate the same level of honesty directed at myself. But I've never directed this at people who were less senior than me, or in a lower position, generally it was senior engineer to senior engineer. So I guess I'm safe?
The book contains references to a number of studies in which assholish behavior was found to be detrimental at work, as well as a number of stories about specific companies who suffered from assholes, and stories of companies who went out of their way to weed out assholes and were rewarded for it. A lot of these stories and studies, I felt, needed stronger citations. There's a collection of 'Additional Reading' at the end, but the entries aren't cross-indexed with the actual mentions in the book, I'm not sure if a lot of the claims are cited at all. Anecdotes about companies I can understand, but public studies and experiments are another matter, I think they should have been easier to source.
One particularly interesting point made was, if you find you have assholes at your company that you can't do anything about, don't let them be involved in the hiring process, as they're likely to hire additional assholes. The book overall had lots of good tips, I also highlighted the suggestion to "Fight as if you're right, listen as if you're wrong" as a good tactic for conflict resolution at work (or really, in life). My favorite bit: treat certified assholes as incompetent employees. Dead-on.
There are lots of issues I have with the book, however. For all the great advice, it's got plenty of terrible advice as well. There's a very large section on how to deal with assholes at work that you can't get rid of. This follows the sections on how not to hire assholes in the first place, and how to get rid of assholes, so it's reasonable to have a section on how to work in an environment with permanent assholes, or asshole bosses. But I found the advice generally depressing. The advice basically boils down to, "don't let them get to you." One particular story is cited where a woman was being harassed regularly by her co-workers, and in a particularly assholey meeting she just relaxed and didn't care about what people were saying. This example is mentioned repeatedly in the book as a stellar example of how to deal with assholes. At one point the advice is given to "develop indifference and emotional detachment." This just seems like horrible advice to me. Maybe it's because I'm privileged to feel comfortable leaving a hostile job, but the advice seems to boil down to lay down and take it, but don't let it affect you. Man, FUCK THAT. Stand up for yourself, tell asshole dipshits to fuck themselves with a rake, get physical if you have to. Maybe it's pride or machismo or I don't know what, but if I was being treated the way that some of the examples in the book were being treated, there's no scenario that plays out where I just tolerate it and try not to let it bother me. I'd just leave, or make it my life's goal to get that person fired so I didn't have to. I'm absolutely not going to let someone talk to me like that, and nobody else should either. I'm not a human being at home and someone else's doormat in the office; I'm a human being 100% of my day, and I deserve to be treated like one, no exceptions.
In fact, a lot of the "just put up with it and don't let it bother you" advice came off like the kind of advice an asshole would give to people with no backbone, to keep the author and other assholes elevated above everyone (the book acknowledges that assholes do tend to get promotions). It's like the advice a fascist would give to the disenfranchised to keep them quiet. These sections of the book made me wonder about the authors intentions, like maybe he was actually a secret asshole trying to keep oppressed people oppressed for his own benefit. Here are a few choice quotes: "just get through each day until something changes at your job or something better comes along" and "passion is an overrated virtue in organizational life, and indifference is an underrated virtue" and "hide from your tormenters". The book also advises to win little battles against assholes to "sustain your spirit" and tells the story of someone who put laxative in treats that she knew an asshole would eat. This is just petty, childish bullshit (and criminal, in the laxative case). Passive aggressive little wimps and weaklings do stuff like this, and quite frankly it makes me feel like they DESERVE to be stepped on and steamrolled by people. Stand up for yourself, call assholes out for being assholes, and if you get fired for it, so be it. How could you live with yourself saying "yes sir" to someone mistreating you all day every day, but then snickering to yourself because you put ex-lax in his coffee? Just fuck off with all that, grow a pair. Shit.
There's also a section how to keep your inner asshole in check. This was very valuable to me, as I definitely can be an asshole, and it's probably something I should reign in. That being said, the book acknowledges the advantages to being an asshole, especially with regards to promotions and rewards. And I've seen the same thing in my professional career, the assholes tend to stand out among the crowd, and are promoted to leadership positions for it. In recent years, I've actually tried to be MORE of an asshole because I've seen the advantages it offers and yes, I've seen it work quite well for me. I almost want to separate Assholes into two categories: Truth-tellers and Bullies. The key difference between these two kinds of assholes is that Bullies punch downward while Truth-tellers punch upward (and sideways). Both kinds of assholes seem to get rewarded for it, but I have few qualms about being a Truth-teller. Being a truth-teller gives you so much practice acting like an asshole that it's easy to transition into Bullying, and I need to be careful about that - that's good advice. But don't throw out the baby with the bathwater, there are nontrivial virtues to asshole behavior, and it's easy to live with yourself while being an asshole as long as you aren't picking on people who are lower on the foodchain.
Overall, the sections of the book about not hiring assholes, and making The No Asshole Rule an official policy at your company are great. The discussions about how to treat assholes at work, and how to get rid of them are excellent. But the sections on how to tolerate assholes at work made me depressed, and even angry at both the author and the would-be advice-follower. I highlighted a lot of things from the book, and I think I've come away from it a better person (or at least, with a heightened awareness of when I cross over into Certified Asshole territory). I think the book is worth reading for anyone who is in a position of power at their company, such as managers (to avoid being assholes), or people with enough seniority that they do interviews for new team members (to avoid hiring assholes). But for lower ranks who want to simply know how to deal with assholes at work they can't do anything about, I don't recommend this book. For those people, it's full of passive aggressive little nuggets of immaturity, and advice to mentally check out of work and just hope the problem goes away. I cannot stress enough how repulsive I find that advice, and how much more effective I think it would be for those people to simply fight fire with fire and become assholes themselves. Being an asshole sucks, but it's better to be an asshole than a coward....more