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
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
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
I've been seeing lots of talk about Microservices, and it's something I have virtually no experience with. Since my coworkers have mentioned hearing lI've been seeing lots of talk about Microservices, and it's something I have virtually no experience with. Since my coworkers have mentioned hearing lots of hubbub about Microservices, I decided to run a little book club for my team. So here is not only my review, but the reviews of my teammates, based on their feedback when discussing chapters every week.
I really enjoyed Building Microservices, I think it either already is, or soon will be, considered the bible of Microservice architecture. When I first got the book I was worried it was going to be impractical, or come off as an advocacy book - "here's why you should do microservices". My favorite NoSQL book is Martin Fowler's, largely because he introduces the book by saying you should use a relational database most of the time. It's a realistic attitude, one in line with my "choose boring technology" mantra, and it makes an author come across as a realist who builds software and not a young fanboy of the latest-and-greatest resume builder. Sam Newman surprised me by offering a similar tone in this book. He essentially says, don't build Microservices. Build monoliths, and then if the need arises, split it into microservices. Never start with microservices as the goal, and don't build greenfield microservice projects. It's a surefire way to get the domain wrong, and be forced to eventually merge everything into a monolith just to re-split it across correct bounded contexts. I felt like this advice was very practical, it lent a lot of weight to the book in my eyes.
The book is organized very well. There are a few chapters introducing Microservices and underscoring the value of utilizing a microservice-based architecture. These chapters never come off as fanboyish advocacy though, it seems like a real presentation of reasons why you might want to migrate toward microservices. After that things start getting a bit more technical, Newman discusses how microservices can and should talk to each other, how to go about splitting an already-existing monolithic codebase, how to deploy microservices, testing, monitoring, and security.
Every week my book club would meet, the refrain I kept hearing was "when are we going to get to the meat of the book?" Every chapter felt, to the group, like it was just getting warmed up, but never getting concrete enough. I think a lot of them were expecting more technical information, or even code. But a lot of the sections basically just wind up saying "make sure you get this or that right, it can be tough!" without a lot in the way of helping the reader get things right. Many of my coworkers said they wished the book was MORE opinionated, giving more concrete advice rather than just warnings to be careful when making particular decisions.
A few particular areas where I felt like the book could have gone into more detail is with regard to how to handle common stuff (for example, if monitoring or caching is part of every microservice you build, should it be in a common library? Who owns it? How does it get updated?) and how to structure a team so that microservices are consistent in terms of interface design and standards (is it a committee? Is it one person from each team?). These are things I think are easy to get wrong - I'd have liked a bit more guidance.
By far the best chapter of the book is the second-to-last chapter. Microservices at Scale gets into the nitty-gritty of a microservice architecture at a technical level that most of the other chapters don't quite. Discussions of patterns, circuit breakers, bulkheads, and so forth litter the (very long) chapter. It name-drops real projects and open source tools that can be used for microservices - I made more notes in this chapter than in any other in the book.
Overall the book is well-written and engaging. It's never too dry like O'Reilly books can often be, I really enjoyed it and learned a lot. I'm not sure if we're going to adopt microservices at work, but the book definitely helped me understand microservice architectures at a level where I can make informed decisions regarding their usage, and I feel like I'd be hitting the ground running if I decided to move forward in building them. I think the book is probably worth a read for most engineers in a position where they make software architecture decisions....more
Ever hear of the Baader-Meinhof Phenomenon? It's the name given for that weird feeling you have when you learn a new word you've never seen before, anEver hear of the Baader-Meinhof Phenomenon? It's the name given for that weird feeling you have when you learn a new word you've never seen before, and then all of a sudden you're seeing it absolutely everywhere. It seems like every e-mail and every TV show is using this word, and you wonder to yourself how you managed to never notice it before, since it's all over the place now? Or maybe you start looking at a new car and researching it, and all of a sudden it seems like everyone on the road is driving that same car?
I had a very similar effect with this book. I've been a Java programmer for over a decade, but never really been terribly concerned with performance, or the internals of the JVM. I try to write good code in terms of using hashmaps and whatnot to do lookups in constant time rather than O(n) time, but microoptimizations were never my thing. I never really felt like it was something I needed to care about, I never really noticed any performance ISSUES in the products I've worked on during my career. But then whenever I'd finish a chapter in this book, I'd notice that the error messages the chapter mentioned, or the kind of things you might notice when performance is degraded started popping up. Within days of finishing the chapter on the Java Heap, we started experiencing Out of Memory errors on some nodes in our production cluster. I recognized the error messages from the book, and knew what tools to reach for because of it as well. After reading the sections on Threading and Java SE Optimizations, I immediately noticed us doing some goofy, ill-advised things in our code. But the out of memory errors had been happening for months I think, and the code I was noticing had been in place for over a year. This stuff had been all around me, and I just wasn't seeing it. The Baader-Meinhof Phenomenon in action.
Truth be told, this book was a bit of a slog to get through. I started it over a year ago, and the material is just so insanely dry that it was a battle. I'd rate myself maybe a 7 out of 10 in terms of interest level in stuff like JVM internals, flags, garbage collection algorithms, and so forth. I like systems stuff, I usually attend low-level system JVM type talks at conferences, but I still found the book, especially the first half, so incredibly dry that I could barely push my way through it. While talking to some buddies about this book, I estimated each chapter's length around 60-80 pages, and then when I checked it turned out most were only around 30 pages or so. Like a 1.5-hour movie that feels like 4, this book is almost punishing.
Don't get me wrong, it's full of useful information - in fact the degree to which it is densely, densely packed with information almost contributes to how dry it feels, since you can't read any part of it quickly due to how information-dense the pages are. I learned an absolute ton from this book and highlighted pages and pages worth of notes, but if you wouldn't give yourself a 6 or 7 out of 10 (or higher) on the scale of general-interest-in-JVM-internals, I think you probably stand no chance at making it all the way through the book.
If this kind of stuff is your cup of tea, definitely give this book a shot. I think it's the most up-to-date (it talks a lot about Java 7 and 8) of all of the books with the words "Java" and "Performance" in the title (I know of at least 3) and I think it's meant to effectively deprecate the others. If you're experiencing performance problems, or hell even if you're not but you want to be the person on your team who can fix them when they inevitably do arise, it's worth reading for sure. Just, be aware that you'll really have to like this kind of stuff to get through the whole thing....more
The Phoenix Project is a bit of a strange book. It's part novel and part technical book, in which a hapless IT worker is promoted to VP of IT and handThe Phoenix Project is a bit of a strange book. It's part novel and part technical book, in which a hapless IT worker is promoted to VP of IT and handed ten pounds of shit in a five-pound bag. The book follows him as he tries to salvage his department and the company.
The situation and characters are painfully relatable. I sympathized more with Bill than any character in any book I've read recently, and I absolutely hated that Sarah more than any book villain, based entirely on her e-mails and who she decided to CC on them. Parts of the book felt copy and pasted directly out of parts of my career.
The first third of the book establishes the situation Bill is in. This portion of the book is incredibly engaging, I felt absolutely sucked in. Unfortunately, the book loses a lot of steam as soon as Bill actually starts to turn things around for his department. The main thesis of the book is that one can apply manufacturing principles to IT work to great success. This is not a new idea, it's the main thrust of the Lean movement. The problem is, rather than Bill going to the company manufacturing plant and learning these things himself, a super-wise sage Erik comes in and just tells Bill everything.
Erik is a complete Mary Sue for the author. Able to accurately predict everything everyone will say and do, almost flawless, and of course his primary character flaw is that he's eccentric (he eats granola bars totally weirdly you guys!!) and otherwise perfect. Bill constantly calls Erik to talk about what he's learned, or to ask questions, and Erik never tells him to fuck off because he's busy. He just dispenses the sage wisdom of Lean. It has a very cultish vibe, like a video produced by a weird religion or something.
I think there's a lot to learn from the book, but not as much about Lean as someone might get from the Poppendieck's classic Lean Software Development book. I also think there's a lot to enjoy about the book, but not as much as one might get from, like, The Da Vinci Code or whatever. In other words, the attempt to be both a technical book and a novel makes it inferior as either one.
The novel format and the short length make this a good book to give to someone working in a dysfunctional organization, without feeling like they're being handed a technical book. However, the preachy and somewhat dull writing of the "here's the Lean tutorial" bits I think might turn people off. That being said, a number of coworkers have found the situation extremely relatable, and are indeed using terminology directly from the book, and clearly making suggestions informed by it, so it does seem to have been at least somewhat effective.
Worth a read for fun, but if you're familiar with Lean development, you likely won't learn too terribly much....more