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
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