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
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
First, some context. I'm really big on the "Software Craftsmanship" movement - I'm signer #227 of the Software Craftsmanship manifesto, and my businesFirst, some context. I'm really big on the "Software Craftsmanship" movement - I'm signer #227 of the Software Craftsmanship manifesto, and my business card says "Software Craftsman and Computer Science Geek" because I think that's the phrase that delivers the best bang-for-the-buck in terms of getting across what I'm all about. Moreover, while I liked Pete McBreen's original 'Software Craftsmanship' book, I didn't love it, and I've been looking for a book that I'd suggest as the first book to introduce a reader to the Software Craftsmanship ideology. Finally, I've been excited about Sandro Mancuso's book for a while, I've been following it's creation on Leanpub for over a year, eagerly awaiting the day it was 'done'; when I saw that it was picked up by Prentice Hall and made part of the Robert C. Martin Series, I was pretty excited. All of this is to explain that I really, really wanted to like this book. I wanted this to be the new go-to book for the Software Craftsmanship ideology, the book I could suggest to people who think it's elitist and annoying of me to have the title on my business card. Unfortunately, it came up very short for me.
The biggest problem with the book is one that I can't quite speak about without seeming unfair, or possibly even offensive. But I want this to be a thorough review of the book, in order to help others decide if they want to read it, so I feel like I have to mention this. The book is written... oddly. That is not to say it's full of grammatical errors or anything like that, but the style of writing is very off, something doesn't feel quite right about it. As I was reading, it felt like it had been intentionally written for a very low Flesch-Kincaid reading level or something, with very short sentences and words arranged in a clunky, somewhat unnatural order. Not incorrect, but off-putting. I kept reading and eventually commented to my wife: "you know what this book reads like? It reads like the book of someone who wrote it in English even though English is not their native language." Sure enough, sometime around Chapter 8 the author himself confirmed that English is not his first language. Now, I'm not trying to knock the guy for not speaking English natively, and his grasp of English is very, very good. Again, nothing was "incorrect". However, the book is kind of unpleasant to read as a result of this, particularly if you read a lot. It's not that it's written incorrectly, but it's far from being "well-written" - it sits somewhere in the zone of mediocrity.
The book tries to distill the entire Craftsmanship philosophy/movement into a single book, a point of reference for anyone curious, and he tries to cover every aspect Software Craftsmanship. Since I think SC is full of great ideas, it's no surprise that I found the book full of great ideas. I love the notion of engineers owning their own careers, buying books and going to conferences on their own if their company won't pay for things like that, because the company doesn't own your career, you do. The book has a great analogy of how bizarre it would be if you hired a plumber to fix your kitchen sink, and he asked if you could buy him a book or send him to a conference first. There's a small section on how to be a good manager of a team of craftsmen that I also enjoyed.
However, a lot of the best parts of the book were simply taken from other books. Done with attribution of course, and the whole idea of this book is to distill wisdom for various sources into a single reference, but I can't help but notice how often the things I enjoyed the most were from elsewhere. There's a great section on Autonomy/Mastery/Purpose that was taken right out of "Drive". There's an entire chapter on Driving Technical Change lifted from a book of the same title (with a bunch of extra stuff added that was more in line with the quality of the rest of this book). The things that were not directly lifted but were instead reworded/summarized tended to be the bulk of the book, and tended to be mediocre. The things that I felt the author really added, the original contributions to the topic, were often poor. The Driving Technical Change chapter had the author adding all sorts of different categories of people who resist the changes you're pushing for, including "The Indifferent", "The Wronged", "The Inept" and so on. It really highlighted for me the complete lack of an entry for "The Person Who Actually Has A Good Point Against What You're Pushing For, Who Maybe Should Cause You To Rethink The Technical Change You're Driving."
The worst parts of the book, by far, were the stories. The author frequently regales us with tales from his career to help illustrate points, and it very much came off like someone trying to present a very young career as though it was much more lengthy and significant. Some of the attempts to link concepts to career occurences seemed like a bit of a stretch, and it served to actually work against illustrating the concepts in a lot of places. Many of his stories simply made the author seem obnoxious, to be perfectly blunt. I'll give a few examples.
In Chapter 9 he tells the story of when he was brought in to help another development team improve. It seems pretty clear from the outset of the story that the person who hired him thought he was bringing in "The Bobs" to evaluate the team members and make recommendations on how to change staffing. But the author takes this moral high-ground stance and says "you called me here to help the developers and not to get them fired" and refuses to answer the question. He goes on to explain that it's not the developers' fault that they are bad, since they didn't "kick the front door" to work there. As someone that has worked with horrible developers, I found this stance to be completely irritating. Sure, the hiring team bears some responsibility for letting people through that aren't up to snuff, but quite frankly it's much more costly to pass on a great developer than it is to hire (and then fire) a bad one, since great developers are so rare and the missed opportunity cost is immense. Teams *SHOULD* try to err on the side of hiring rather than non-hiring, but they have to also be willing to let people go that aren't good enough. So this whole notion of not "kicking down the door" somehow absolves bad engineers from being bad is absurd - they DID send their resumes and interview and accept the offer, and that's as much "kicking down the door" as you're going to get. The author ends this section hilariously, after refusing to help fire bad engineers since he didn't take the job to get people fired, he concludes with "the selection process must be changed and whoever is behind it should be fired."
In Chapter 14 he tells the story of an argument he got in with a Software Architect at a job. He gives us an entire line-by-line script in which the Software Architect keeps walking into debate traps and the author keeps supplying him with Epic Zingers to completely shut him down. The whole thing reads like an absurd fan fiction, like the 'ideal conversation' that you have with yourself in the shower the next day where you think of the perfect thing to say to respond to everything, and completely destroy your opponent with your wit and cleverness. I'm just reading the whole thing thinking "right, that happened." And what's great is, the author himself, in his own idealized version of this fake conversation, STILL manages to come off pompous and elitist (two of the main criticisms lobbed at the Craftsmanship movement). The argument is basically around a theoretical Ivory Tower Architect who makes all the tool/technology decisions and other teams have to follow those decisions when building their software. The author, rightfully, finds this position problematic since it creates a separation between who is responsible for the decisions, and who is accountable for them. But he completely shuts the architect down in a half-page rant (that I'm TOTALLY sure happened as described, on the spot) ending with him threatening the Architect by saying that he'll tell stakeholders "to talk to you about any delays and problems that may be caused by the technology choice." Again, he's not WRONG about this dynamic being dysfunctional, but he SURE is kind of an asshole about it.
In Chapter 12, he tells the story of how he was working with a team that refused to write unit tests because they couldn't afford the time. He says he tried for 8 months to get people to work more like him, but was unsuccessful. The entire effort took "seven years to complete and cost more than ten million pounds." Sure seems like a terrible project, but then the author goes on to say "Looking back, our rough estimation was that the same project with [...] five talented and passionate developers would have taken between 18 and 24 months to complete, costing less than two million pounds." Look, I'm a huge fan of TDD and passionate engineers and craftsmanship but really, how is this even a serious argument? Compare a failed project's numbers to numbers you COMPLETELY MADE UP to illustrate how much better your philosophy works? This isn't even an "I told you so" argument, it's simply saying that he's confident it'd have gone better if people listened to him more, therefore people should have listened to him more. Well, uh, oh yeah? If you guys had hired me for the project, by my rough estimation I'd have completed the entire project in under 2 hours for less than $200. Therefore, I'm great. Ridiculous.
The most irritating story to me was one in which the author and his team wanted to give business folks something "real" to work with instead of mockups while developing. So they created a fully-styled version of the entire web application they were asked to build, but made most of the pages 'read-only' or backed by an in-memory data store that vanished on restart. He argued this allowed stakeholders to really see what they'd be getting, building a horizontal slice of the application instead of a steel thread/vertical slice. This worked out great for the author at that particular organization, but I consider it massively, massively bad advice for almost any team, and I think it borders on professionally irresponsible to advocate it in a book that people are going to read looking for guidance on how to be a Software Craftsman. Building a perfect-looking "fake" web site that can't actually be launched because it follows no nonfunctional requirements such as persistence, scalability, etc, is a surefire way to have your stakeholders think the product is "done" when it's nowhere close. When building usable interfaces to hash out the details of how a product should work, the WORST thing you can do is spend the time to fully style it with CSS and the like, because it gives off a sense of completeness that is completely inaccurate. It's far better to avoid using the corporate colors, and even use Comic Sans as the main font, simply so that it visually conveys "work in progress" to anyone who gazes upon it. Never show your business stakeholders a product that *LOOKS* like it works perfectly, they will want to launch immediately, and now you're having to explain databases and concurrent user load to business people who care about functionality and features. Terrible, terrible advice.
The book is needlessly contradictory in many places as well. The author explains that practices like TDD shouldn't be done sometimes but "must be adopted wholeheartedly", but then explains that the way to get other people to adopt practices you like is to be an example, and do those practices on your own until others join in. Isn't the team doing the practice "sometimes" by that very thing? I love TDD, I love pairing, but I'm also pragmatic and there are plenty of times when it's not the right thing to do - lots of code where writing the tests afterwards is better than before, or cases when pairing is just not going to work for a task. I'd never agree with the "all or nothing" approach the author advocates early in the book, and I find it humorous that even he couldn't agree with it for the entire duration of his own book.
The most frustrating chapter for me, by far, was Chapter 9: Recruitment. I think that recruiting and hiring good engineers is the biggest challenge facing the entire software industry, and it's bizarre to me that this is one of the things we're worst at with so few books being written about improving it. It really seems like, as a group, we simply don't know how to do it well. So whenever a book comes along, or even a chapter, devoted exclusively to talking about recruitment, I get pretty pumped up about it. But I found the advice in Chapter 9 to largely be just dreadful.
The author falls into the classic problem of relying on things like a person's blog, twitter, github account, and OSS contributions to evaluate them as a candidate. It's been shown time and time again that these kinds of criteria disproportionately exclude certain groups of people, and rely on a 'free time privilege' that is lacking in a lot of socioeconomic groups. In other words, this kind of filtering is a really good way to hire exactly one type of engineer over and over again. The author argues that 'passion' is the most important trait in a good engineer, but seems to largely define that passion in terms of what the engineer does outside of work hours. I find this extremely unfair, I've worked with lots of engineers who are excellent and passionate, but whose passion exists from 9 to 5. They may read blogs and books after hours a bit, but they have children and families and simply cannot push those things to the side to be more passionate about code. I'm not sure I even want to meet someone who is more passionate about his code than his children. This whole "it's what you do outside of work that defines your employability" movement has been taking a lot of flack recently and rightfully so, and it pained me to see this same dangerous mentality repeated in a book as though it's an integral part of the Software Craftsmanship movement to which I subscribe.
The specifics of recruitment I found just as problematic. The author argues against asking interview candidates specific questions that align the candidate with what they believe to be 'good' (fine), or asking questions that have specific right answers like API questions (fine). But then he also argues against using algorithms. He makes a decent argument against using them in interviews (the most common problems in a codebase are not algorithmic in nature), but leaves little alternative. Don't conduct phone interviews. Don't have them write code on a whiteboard. I'm sorry but what exactly am I supposed to do to evaluate someone? Is it really THAT unreasonable to ask a candidate to code a 10-20 line function on the whiteboard to solve a well-defined small problem? The value of these kinds of questions is that the 'domain' can be understood in seconds. Shuffle a deck of cards. Write fizzbuzz. Find all the anagrams of a word. I can explain these problems in no time at all, and coding the solutions should take just a few minutes. You're telling me that this is useless because it's preventing the candidate from using their "real tools"? It's not okay to make sure that a candidate can write a single function in the language of their choosing?
The author instead advocates two approaches for interviewing. For the on-site interview, a full pair programming session solving a real problem using tools that they are comfortable with. I love this approach myself, but the fact is, if the company doesn't regularly do pair programming it's extremely misleading and unfair to the candidate. So if you haven't adopted pair programming team-wide, what are you supposed to do? It would seem the answer is that you can't be a team of craftsman unless you're pair programming, which is the exact kind of XP practice dogmatism that Craftsmanship is frequently criticized for, and the entire Appendix of the book is attempting to dispell.
The other approach is the "programming assignment" approach, in which candidates are given a programming task to complete ahead of time. Then the interview consists largely of discussing the implementation. Again, I like this approach as well, but it's not always going to work everywhere, and it strongly filters out people who simply cannot carve away the time outside of work hours for this kind of stuff due to their lives not being as charmed as the author's. The most jaw-dropping section of this book is so stunning that I simply have to include the entire excerpt:
"During times when we are not ready to hire but still have applicants, we tell them at the very start of the recruitment process that we are not hiring straight- away. We suggest that if they want to go through the selection process and pass, they would be the first ones we would call as soon as we were ready. As part of our selection process, we ask developers to complete a code assignment that may take at least a weekend to complete. In order to convince them to go through the process, even knowing that we are not ready to hire, we promise to provide them with a very comprehensive review of their code. With this approach, applicants at least get some valuable advice on their code, and we can build a pool of tal- ented developers who have passed our selection process, and we can call them when we are ready to hire."
Man. Just... screw you. It's okay you wasted your weekend completing an assignment for a company that's not hiring, because we'll give you a half-assed code review and we're great so you should appreciate that. This attitude is contemptible.
Overall, this book had some good tidbits here and there but they seemed to be drowned out by the preponderance of bad advice and infuriating writing. The book exemplifies the exact kind of snotty elitism and cockiness ("Testers should find nothing. Zero. Nada.", "only incompetent people are scared to lose their jobs", "asking candidates to write code on a whiteboard is a very stupid idea", "[introducing abstractions early] is not smart; it is stupid", "Developers who are experienced with test automation will very rarely use a debugger") that plagues the public view of Software Craftsmanship. It even does this while the author specifically addresses that criticism in the appendix, simply stating that the author finds this claim "surprising" since the Craftsmen he's met are great. And on top of all that, it's written poorly, which I largely attribute to the author not learning English until his adult years, as well as the fact that this book was written almost entirely on Leanpub with no editor until it was rebranded as a Prentice Hall book.
I'm still looking for my perfect Craftsmanship book. At present, it remains the duo of Clean Code/The Clean Coder and augmented with "Apprenticeship Patterns". I'd recommend all three of those books well above this one. I honestly can't recommend this book to those who are curious about Software Craftsmanship, because I think I think it will mislead then. Nor can I recommend it to those who consider themselves Craftsmen and want to improve their craft, as I think the content consists of a mix of things you already know, and things you will find actively irritating....more
Soft Skills is a book for software development that isn't about software development. Author John Sonmez discusses how to manage your career, how to iSoft Skills is a book for software development that isn't about software development. Author John Sonmez discusses how to manage your career, how to interview, how to prepare a resume, how to market yourself, how to improve your ability to learn and take in new information, how to experiment with new technologies, how to improve your productivity and, surprisingly, even how to manage your finances and how to stay in physical shape.
The book is, for the most part, extremely valuable. A lot of the material in the Career section has been covered in other books such as The Passionate Programmer and Land the Tech Job You Love, but the section is still somewhat useful. The section on Marketing oneself was similar, I've heard a lot of the same advice for programmers before: have a twitter account, use github, contribute to OSS, speak at conferences, write a book, etc. The section on Learning was okay but a bit abstract, and mostly common sense. For the most part, those were really the sections I was expecting from the book honestly, based on the title. I figured the book would mostly be about enriching the skills that help you thrive at work, that's typically what I consider "soft skills" at the office. I expected some stuff about navigating corporate ladders or even communicating with coworkers but there really wasn't much of that. I expected the career/marketing/learning stuff as well, and that was there though not particularly stellar.
However, the chapters that I wasn't expecting were phenomenal. The section on Productivity was great, with lots of useful tips for how to be more productive, track your productivity, and get past hurdles like procrastination. When I saw the section title I thought it was just going to be a lot of "OMGZ POMODORO TECHNIQUE!" which was there of course, but there was a lot more that was useful too.
The Financial section is the one I consider the "worth the price of admission" section of the book. If you're a software engineer, you owe it to yourself to at least read this section. It's about salary negotiation, investing, stock options, debt management, retirement plans, and more. These are things that I always wished I knew more about, but it's not taught in school and the internet is rife with scams rather than useful information on these topics. It's weird because it's always tough to ask about this sort of thing at work - people somehow expect everyone to understand 401k's and stock options, and folks are weirdly cagey about giving advice/help on these matters. The chapter on Stock Options was the first thing that finally made the subject make sense to me, and there's two sections in the Appendix about money and stock markets that are required reading as well.
The Fitness section was also great, good solid advice contained therein. There are also two more appendix sections on nutrition and fitness that are phenomenal, and they alone were better than the entirety of O'Reilly's Fitness for Geeks book. The final section, "Spirit" is largely useless. Lots of froo-froo garbage and nonsense, I found myself skimming a lot of it because I was hurting myself rolling my eyes.
Overall, the book is pretty well-written and conversational. Information is pared down into consumable chunks, and each chapter is generally only a few pages long so it's easy to pick up, read a little, and put back down. There's a bit of a vibe/tone of a sleazy car-salesman to Sonmez's writing, you sort of occasionally feel like you're listening to a Tony Robbins self-help lecture, there were multiple times when I sort of felt like I was taking advice from a douchebag. Later, on page 334, the author includes a few pictures of himself from his male-modeling days and confirms, yep, you're reading the words of a douchebag.
Tone/eyerolling notwithstanding, the book contains tons of useful advice and practical information. There's a large amount of stuff that should probably be taken with a grain of salt, especially regarding finances because the author seems to think he's in a position to give financial advice due to "retiring" at 33 years old, but includes a section on how he accomplished this that basically boils down to "I got really really lucky" and even includes a bit of "I'm a Christian and I was rewarded for my tithing". He also rented gumball machines for a while. Er, what?
In any case, I highly recommend this book to software developers, particularly the section on Finances and, if you've never seen it in another book, the sections on Career and Marketing Yourself....more