The software craftsman: professionalism, pragmatism

Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site. Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider.

Marketing preferences may be changed at any time. If a user's personally identifiable information changes such as your postal address or email address , we provide a way to correct or update that user's personal data provided to us.

This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service informit. Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list s simply visit the following page and uncheck any communication you no longer want to receive: www.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest pearson. California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information.

This privacy statement applies solely to information collected by this web site. Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements.

If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Clean Craftsmanship: Disciplines, Standards, and Ethics. Add To My Wish List. 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. 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. 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. 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? Therefore, I'm great. 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. 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. 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 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. 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. 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. 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.

View all 3 comments. This book frustrated me. I once had the fortune of seeing Sandro give a talk at the Software Craftsmanship North America SCNA conference in , and found his talk uplifting, and inspirational. As a result of that, when I saw this book had been released it was an "instant buy" for me. Ultimately though I was incredibly disappointed by this book. I wanted to like this book. And honestly, much of what Sandro espouses in this book I agree with and believe.

But, This book frustrated me. But, this book is poorly written and filled with anecdotal "evidence" to support his claims. This is a shame, as there is much well documented, well-researched evidence to support much of what he argues for. By in large if you've ever followed the software craftsmanship community, you'll have heard everything that you'll read in this book.

TDD is great so it's an encouraged practice, but we don't hold practices in a dogmatic way. Pragmatism is key. You can't be a great developer without being passionate. Commit yourself to lifelong learning. The craftsmanship movement is about raising the bar. On and on and on, it's all the standard tropes you hear in conversations about software craftsmanship.

I went into this book expecting to see something new, or some deep insights, instead I got a series of blog posts that felt very much like preaching to the choir. There's also lots of heavy-handed "preachyness" in this book. Lots of defamatory comments towards managers, agile coaches, and architects though back-pedalled in the appendix , and lots of "if you don't do this, then you're doing it wrong" type rhetoric, which I found surprising.

The craftsmanship community is supposed to be about celebrating diversity and being welcoming of anyone, of any skill level so long as they're willing to better themselves and learn more. Lots of straw man commentary, painting conversations with Dilbert-esque pointy-haired bosses in a very biased light. Lots of sweeping generalizations, and little in the way of new insights. There's a lack of focus or coherent theme to the book. Who is this for? Is it for "apprentice" craftsmen?

For people who've heard about this software craftsmanship thing and want to know more? For the Bob Martin's of the world? It's so inconsistent, some of it feels written for an audience who's only vaguely familiar with the craftsmanship movement, and other parts feel like unless you've been writing code for decades you'll have trouble relating. I'm being overly harsh, there are nuggets of really good insights in this book and he certainly knows the craftsmanship movement.

The thing is though there's nothing you won't get from simply reading the blogs or books of some of the people in the craftsmanship community. If you've read Clean Coder by Bob Martin, there's no reason to read this book. View all 5 comments. Sep 23, Andreea-diana Cristei rated it it was amazing. I started reading this book when I first heard about the Software Craftsmanship concept but I wasn't prepared to really understand it so I don't remember how but I abandoned it.

Later on, after 5 years, 2 workshops on Crafting Code and Crafted Design and several pass-it-on for those workshops, I picked up the book again and everything made sens. It was such a pleasure to be reading it after the workshops as many, many references were found in the book. I was scared I was reading it too fast and I started reading this book when I first heard about the Software Craftsmanship concept but I wasn't prepared to really understand it so I don't remember how but I abandoned it.

I was scared I was reading it too fast and I am missing all the great references. It was so inspiring to see that above being a true craftsman, the author took his time to put it all in this book. I would recommend it to anyone, from developers, engineers, testers, scrum masters, delivery managers, project managers, recruiting staff as Sandro Mancuso took time to go through the craftsmanship concept, its nuances, its traits and benefits.

I recommend this book as starting point for the software craftsmanship journey, as a reference guide along the way and for sure as a reminder about why we love this job.

Oct 25, Victor rated it really liked it Shelves: read-tech. I've been reading blog posts by Sandro and watched his talks for a while now.

I've learnt a lot on his Crafting Code and Crafted Design courses. So I had high expectations from this book. It didn't disappoint. The book delves into the many aspects of software craftsmanship, from technical practices to recruitment, interviewing, career progression and creating a learning culture.

Book description Be a Better Developer and Deliver Better Code Despite advanced tools and methodologies, software projects continue to fail.

Show and hide more. Table of contents Product information. Ideology and Attitude 1. A Full Transformation 9. Study in Scarlet. The Iliad. The Lost World.

The Odyssey of Homer. The rescue. The Robert C. The White Company. Under western eyes.