What do you think?
Rate this book
Robert C. Martin Series
The Software Craftsman: Professionalism, Pragmatism, Pride
• A manifesto for the reinvigorated Software Craftsmanship movement: how to become a better developer and deliver better code • Offers exceptionally practical and actionable advice on improving software quality and project success rates • Reveals what Software Craftsmanship means today, and why it's more important than ever • The newest book in our internationally-respected Robert C. Martin Series
288 pages, Unknown Binding
First published December 3, 2014
About the author
Sandro Mancuso
2 books294 followersSoftware craftsman, author, co-founder of Codurance, and founder of the London Software Craftsmanship Community (LSCC). Sandro has been coding since a very young age but only started his professional career in 1996. He has worked for startups, software houses, product companies, international consultancy companies, and investment banks.
During his career Sandro had the opportunity to work in a good variety of projects, with different languages, technologies, and across many different industries. Sandro has a lot of experience in bringing the Software Craftsmanship ideology and Extreme Programming practices to organisations of all sizes. Sandro is internationally renowned by his work on evolving and spreading Software Craftsmanship and is frequently invited to speak in many conferences around the world. His professional aspiration is to raise the bar of the software industry by helping developers become better at and care more about their craft.
During his career Sandro had the opportunity to work in a good variety of projects, with different languages, technologies, and across many different industries. Sandro has a lot of experience in bringing the Software Craftsmanship ideology and Extreme Programming practices to organisations of all sizes. Sandro is internationally renowned by his work on evolving and spreading Software Craftsmanship and is frequently invited to speak in many conferences around the world. His professional aspiration is to raise the bar of the software industry by helping developers become better at and care more about their craft.
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 117 reviews
July 27, 2015
First, 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:
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.
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.
January 31, 2015
This book frustrated me. I once had the fortune of seeing Sandro give a talk at the Software Craftsmanship North America (SCNA) conference in 2013, 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. Rather I wanted to *love* this book. And honestly, much of what Sandro espouses in this book I agree with and believe. 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. See, the thing is when you make empirical claims (ie - if you do TDD you will reduce bugs and therefore reduce costs, or if you pair with other developers you will create a culture of learning which will improve productivity, or if you hire craftsmen your company will be better off), you need to back that up with empirical evidence, not just "I had this job once where we did this & it worked...".
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.
There's also lots of inflammatory/adversarial commentary (ex: "QA teams are an anti-pattern", "are you good enough to work on legacy code?", "tech debt items are an excuse to justify bad code", "software craftsmen are never scared to lose their jobs", "only incompetent people fear losing their jobs", "university degrees don't mean anything", etc) that feels very elitist & arrogant. 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.
Ultimately though I was incredibly disappointed by this book.
I wanted to like this book. Rather I wanted to *love* this book. And honestly, much of what Sandro espouses in this book I agree with and believe. 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. See, the thing is when you make empirical claims (ie - if you do TDD you will reduce bugs and therefore reduce costs, or if you pair with other developers you will create a culture of learning which will improve productivity, or if you hire craftsmen your company will be better off), you need to back that up with empirical evidence, not just "I had this job once where we did this & it worked...".
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.
There's also lots of inflammatory/adversarial commentary (ex: "QA teams are an anti-pattern", "are you good enough to work on legacy code?", "tech debt items are an excuse to justify bad code", "software craftsmen are never scared to lose their jobs", "only incompetent people fear losing their jobs", "university degrees don't mean anything", etc) that feels very elitist & arrogant. 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.
June 11, 2020
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.
I agree that most organization focus too much on process-oriented agile and often ignore the technical practices. This book aims to solve that. I liked the chapters on learning and driving technical change. These contain practical advice and examples of how to improve technical practices and create a culture of learning within a team. I also found the chapters on recruiting and interviewing quite insightful. I do think that we, as a industry, sometimes really suck at this part. The advice in this book can help us make things better. Mind mapping a conversation seems a great way to lead an interview.
The book has a personal tone. Sandro uses a lot of stories and anecdotes (from his experience) to back his statements, which I appreciate. It doesn't contain references to research or data to prove the validity of the statements (if you want that, I recommend Accelerate: Building and Scaling High-Performing Technology Organizations. These two books can help you build arguments for introducing technical practices).
But, the tone is also the main thing that I didn't like. I think that the author is sometimes condescending and the book has several rants (against managers, agile coaches, architects) which I found off-putting. Saying that 9-to-5 developers should look for another career and that only incompetent people are scared to lose their jobs are two examples of things that I don't agree with.
I agree that most organization focus too much on process-oriented agile and often ignore the technical practices. This book aims to solve that. I liked the chapters on learning and driving technical change. These contain practical advice and examples of how to improve technical practices and create a culture of learning within a team. I also found the chapters on recruiting and interviewing quite insightful. I do think that we, as a industry, sometimes really suck at this part. The advice in this book can help us make things better. Mind mapping a conversation seems a great way to lead an interview.
The book has a personal tone. Sandro uses a lot of stories and anecdotes (from his experience) to back his statements, which I appreciate. It doesn't contain references to research or data to prove the validity of the statements (if you want that, I recommend Accelerate: Building and Scaling High-Performing Technology Organizations. These two books can help you build arguments for introducing technical practices).
But, the tone is also the main thing that I didn't like. I think that the author is sometimes condescending and the book has several rants (against managers, agile coaches, architects) which I found off-putting. Saying that 9-to-5 developers should look for another career and that only incompetent people are scared to lose their jobs are two examples of things that I don't agree with.
September 21, 2015
This is a must read book by all the software developers. It probably contains everything you need to know. If I summarize my take away from this book, the author suggests us to blog, read books, follow technical websites, use social media and know who to follow, practice programming everyday by trying Katas, having pet projects, contributing to open source, take part in user group and community activities and more pair programming. He also highlights the values of TDD, use of continuous integration. He tells the readers to think about career development one job at a time. He suggests to select a job where we have autonomy. The job criteria should matches to our purpose and leads us to mastery. We can take the decision to terminate the job when any of them (autonomy, mastery and purpose) are deviated from our expectation. He also explains the cost of employing 9-5 developers in team and the value, a passionate developer can bring to a company and to other fellow developers. Further he highlights that being passionate about your job will take you to your ultimate goal, to become a software craftsman.
September 23, 2019
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 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.
March 12, 2015
*edited*
I came back to change my review of this particular book. At first it feels like an in-your-face reality check, but I think the author truly lets his pride get in the way.
This book is a piece focused near solely on selling TDD as the end-all-be-all of programming tools. Perhaps worst of all though is Mancuso's intensely masculine and patriarchal tone. SImply using feminine pronouns when referring to unknown subjects doesn't cut though the deeply embedded culture of toxic masculinity in code culture, and you can hear it throughout this book.
Mancuso advocates for a life-style built around code, and a one dimensionalism that is oppressive in its pervasiveness. Instead of reading this, try out other helpful books such as Pragmatic Programmer, Extreme Programming: Explained, and many more.
I also highly recommend Unlocking the Clubhouse: Women in Computing which is an excellent survey that will help provide some perspective.
I came back to change my review of this particular book. At first it feels like an in-your-face reality check, but I think the author truly lets his pride get in the way.
This book is a piece focused near solely on selling TDD as the end-all-be-all of programming tools. Perhaps worst of all though is Mancuso's intensely masculine and patriarchal tone. SImply using feminine pronouns when referring to unknown subjects doesn't cut though the deeply embedded culture of toxic masculinity in code culture, and you can hear it throughout this book.
Mancuso advocates for a life-style built around code, and a one dimensionalism that is oppressive in its pervasiveness. Instead of reading this, try out other helpful books such as Pragmatic Programmer, Extreme Programming: Explained, and many more.
I also highly recommend Unlocking the Clubhouse: Women in Computing which is an excellent survey that will help provide some perspective.
September 20, 2018
I would recommend this book to any junior developer. Hell, I'm thinking this is a good read for everyone new to a job, as some of the underlying principles really apply to any industry. Having said the latter, it is developer centric, so may confuse the non initiated.
I am a Product Owner / Business Analyst and have been in the industry for over a decade, but still found it an interesting, at worst confirming, at best inspiring and thought provoking read.
Yes, at times it can come across a bit preachy, but hey, that's ok...
I am a Product Owner / Business Analyst and have been in the industry for over a decade, but still found it an interesting, at worst confirming, at best inspiring and thought provoking read.
Yes, at times it can come across a bit preachy, but hey, that's ok...
March 25, 2017
Kind of meh. Because I already agreed with a lot of what was said, I don't think I learned a lot from this book. It's a good book, but I'm not its primary audience.
There were, however a few nuggets about interviews and high level career plan that I think were valuable to me. For example, the practice of involving junior devs in the interview process is something that I'd like to try.
I was annoyed by the grammatical overuse of "to".
There were, however a few nuggets about interviews and high level career plan that I think were valuable to me. For example, the practice of involving junior devs in the interview process is something that I'd like to try.
I was annoyed by the grammatical overuse of "to".
April 15, 2021
Good ideas, though I was really surprised how I disliked the book tone. In some places it seemed arrogant and even offensive. I usually love these kind of books (especially this series) and they revive passion in me, but this did nothing for me.
P.S. It almost seem it should have been called "The TDD Craftsman" as it was hard to find a page without mentioning how good is TDD and how the author is proud of using it.
P.S. It almost seem it should have been called "The TDD Craftsman" as it was hard to find a page without mentioning how good is TDD and how the author is proud of using it.
January 31, 2015
This book frustrated me. I once had the fortune of seeing Sandro give a talk at the Software Craftmanship North America (SCNA) conference in 2013, 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. Rather I wanted to *love* this book. And honestly, much of what Sandro espouses in this book I agree with and believe. But, this book is poorly written, 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.
The thing is when you make empirical claims (ie - if you do TDD, you will reduce bugs, and therefore reduce costs), you need to back that up with empirical evidence. In this book that is not only lacking, it's nonexistant.
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, but we don't hold practices in a dogmatic way. You can't be a great developer without being passionate. Commit yourself to lifelong learning. 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, 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 and designers (though back-pedalled in the appendix), and lots of "if you don't do this, then you're doing it wrong" type rhetoric. I found this 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.
There's also lots of inflammatory commentary (ex: "QA teams are an anti-pattern", "are you good enough to work on legacy code?", "tech debt items are an excuse to justify bad code", "software craftsmen are never scared to lose their jobs", "university degrees don't mean anything", etc) that feels very "ivory tower"-ish.
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.
At a fundamental level, Sandro seems to boil down craftsmanship to simply being about "passion", without sufficiently articulating what it means to be passionate.
I'm being overly harsh, there are nuggets of really good insights or tidbits in this book, though there's nothing you won't get from simply reading the blogs or books of some of the people in the craftmanship community. If you've read Clean Coder by Bob Martin, there's no reason to read this book.
Ultimately though I was incredibly disappointed by this book.
I wanted to like this book. Rather I wanted to *love* this book. And honestly, much of what Sandro espouses in this book I agree with and believe. But, this book is poorly written, 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.
The thing is when you make empirical claims (ie - if you do TDD, you will reduce bugs, and therefore reduce costs), you need to back that up with empirical evidence. In this book that is not only lacking, it's nonexistant.
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, but we don't hold practices in a dogmatic way. You can't be a great developer without being passionate. Commit yourself to lifelong learning. 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, 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 and designers (though back-pedalled in the appendix), and lots of "if you don't do this, then you're doing it wrong" type rhetoric. I found this 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.
There's also lots of inflammatory commentary (ex: "QA teams are an anti-pattern", "are you good enough to work on legacy code?", "tech debt items are an excuse to justify bad code", "software craftsmen are never scared to lose their jobs", "university degrees don't mean anything", etc) that feels very "ivory tower"-ish.
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.
At a fundamental level, Sandro seems to boil down craftsmanship to simply being about "passion", without sufficiently articulating what it means to be passionate.
I'm being overly harsh, there are nuggets of really good insights or tidbits in this book, though there's nothing you won't get from simply reading the blogs or books of some of the people in the craftmanship community. If you've read Clean Coder by Bob Martin, there's no reason to read this book.
October 26, 2016
Motivating book with good advice on how to improve your career!
* Similar to The Clean Coder;
* Explains problems and solutions with Waterfall and Agile;
* Goes to great lengths to draw the advantages of XP practices;
* Methods for crafting your career path;
* What it means to be a Craftsman - somebody who loves details, design and work and plans for long-term;
* Coding has become a social activity - reading, pairing, katas, open source, going to events;
* How a really good job description should look like - i.e. hire attitudes, train skill;
* I should have read it before applying to my first or second job - could have avoided many of my mistakes.
On the negative side, I was disappointed to see that it didn't contain references to works of others (e.g. "see Kahneman's Thinking Fast and Slow for an in depth explanation of Confirmation Bias"), like e.g. Peopleware does (which bases its claims on actual studies). It was rather filled with Sandro's personal anecdotes - which might be ok if it were an audiobook about his life -, where in the end it turned out that he was right all the time, and notes that he doesn't want to blame management ... but does it anyway.
I was expecting it to be more scientific/objective/detached, but I felt that there was too much personal image building, i.e. they didn't serve the reader's evolution in any way.
I wanted to hear about how to become a better craftsman, what I got instead was how Sandro became one. I really respect him for that, but the book's title wasn't "The Sandro Craftsman".
The style of writing was also blog-like: it has a first-edition feel, i.e. it doesn't converge, it's often way too verbose, it's not focused enough, it still needs a lot of polishing.
It's still very inspiring and I do recommend the book. Sandro is a good guy with respectable intentions, but he has probably fought so much to get where he is (and has to keep a good public image), that it's easier for him to talk about all the negative experiences - that we're all too familiar with -, instead of how it should be done - based on not just his personal experiences.
I'm waiting for the second edition, hoping it will keep all the amazing stuff, with the same inspirational content, but in a less verbose format and more backed-by-science claims - available in an audiobook format also.
* Similar to The Clean Coder;
* Explains problems and solutions with Waterfall and Agile;
* Goes to great lengths to draw the advantages of XP practices;
* Methods for crafting your career path;
* What it means to be a Craftsman - somebody who loves details, design and work and plans for long-term;
* Coding has become a social activity - reading, pairing, katas, open source, going to events;
* How a really good job description should look like - i.e. hire attitudes, train skill;
* I should have read it before applying to my first or second job - could have avoided many of my mistakes.
On the negative side, I was disappointed to see that it didn't contain references to works of others (e.g. "see Kahneman's Thinking Fast and Slow for an in depth explanation of Confirmation Bias"), like e.g. Peopleware does (which bases its claims on actual studies). It was rather filled with Sandro's personal anecdotes - which might be ok if it were an audiobook about his life -, where in the end it turned out that he was right all the time, and notes that he doesn't want to blame management ... but does it anyway.
I was expecting it to be more scientific/objective/detached, but I felt that there was too much personal image building, i.e. they didn't serve the reader's evolution in any way.
I wanted to hear about how to become a better craftsman, what I got instead was how Sandro became one. I really respect him for that, but the book's title wasn't "The Sandro Craftsman".
The style of writing was also blog-like: it has a first-edition feel, i.e. it doesn't converge, it's often way too verbose, it's not focused enough, it still needs a lot of polishing.
It's still very inspiring and I do recommend the book. Sandro is a good guy with respectable intentions, but he has probably fought so much to get where he is (and has to keep a good public image), that it's easier for him to talk about all the negative experiences - that we're all too familiar with -, instead of how it should be done - based on not just his personal experiences.
I'm waiting for the second edition, hoping it will keep all the amazing stuff, with the same inspirational content, but in a less verbose format and more backed-by-science claims - available in an audiobook format also.
April 22, 2017
This could be a useful book if for people who don’t have much experience working in the software industry, or those have only worked in organisations that develop software in a waterfall style. It provides a reasonable overview of how software craftsmanship should and could work on an individual and company basis, for example giving ways to constructively deal with deadline pressure and ideas for improving hiring practices. However, anybody who knows a small amount about agile development practices or software craftsmanship in general will probably find this book basic and stating the obvious.
I found the writing style rather patronising. The book is full of disaster stories about times the author had worked with people who couldn’t be helped - he lists 13 different types of skeptical people that craftsmen have to deal with in organisations (ivory tower architects are THE WORST apparently).
He also says that the majority of 9-5 programmers should be fired. I take issue with this. Some of the best programmers I know have no problem with leaving their work at their desk when they leave the office on an evening. Encouraging the idea that all developers should be frantically working on pet projects in their spare time outside of work is damaging to the industry and makes it far less inclusive.
I found the writing style rather patronising. The book is full of disaster stories about times the author had worked with people who couldn’t be helped - he lists 13 different types of skeptical people that craftsmen have to deal with in organisations (ivory tower architects are THE WORST apparently).
He also says that the majority of 9-5 programmers should be fired. I take issue with this. Some of the best programmers I know have no problem with leaving their work at their desk when they leave the office on an evening. Encouraging the idea that all developers should be frantically working on pet projects in their spare time outside of work is damaging to the industry and makes it far less inclusive.
November 9, 2017
I am quite sold on agile methodologies and focusing on great codes. So the concepts discussed in this book where quite familiar.
However, What I liked is the emphasis the book puts on the importance on the job of a developers. I’ve seen so many people around me trying to move forward with their careers by just moving as a management role. I really felt that development was not a good career to pursue. Even myself I was « proud » of starting a position as an architect.
But eventually, I was not happy and I really enjoyed creating value through high quality code. I thought this is where the true value of a product was actually being built. Even as a product manager, I enjoyed spending time in the development team.
So this book really gives a very positive message about following the development career path and I hope this will have an impact on how people are seeing developers
Very inspirational and honest, thank you Mr Mancuso :)
However, What I liked is the emphasis the book puts on the importance on the job of a developers. I’ve seen so many people around me trying to move forward with their careers by just moving as a management role. I really felt that development was not a good career to pursue. Even myself I was « proud » of starting a position as an architect.
But eventually, I was not happy and I really enjoyed creating value through high quality code. I thought this is where the true value of a product was actually being built. Even as a product manager, I enjoyed spending time in the development team.
So this book really gives a very positive message about following the development career path and I hope this will have an impact on how people are seeing developers
Very inspirational and honest, thank you Mr Mancuso :)
November 3, 2023
This an immensely cathartic discussion about the every day frustrations we face as "software devs" or "code monkeys". It is time for us, to put the professionalism and pride of craftsmanship back in Software Engineering. And as many things in life, it starts with changing our own attitude.
Felt like reading a personal blogpost of a senior engineer. This is an essential pep-talk which every new software developer fresh out of college needs to hear before they waddle out into the open seas. For engineers who are a few years in, this book provides many vital, actionable ideas on how we can start changing the things that we complain to our peers about, in private.
Felt like reading a personal blogpost of a senior engineer. This is an essential pep-talk which every new software developer fresh out of college needs to hear before they waddle out into the open seas. For engineers who are a few years in, this book provides many vital, actionable ideas on how we can start changing the things that we complain to our peers about, in private.
November 2, 2020
Forget “The complete software developers’s career guide”, “Soft skills”, “The clean coder” and “Developer hegemony”. Although each very powerful in their own purpose, they are nowhere nearly as good as this book when it comes to software craftsmanship.
Finally I find an author who recognises software development as a lifestyle and passion and realises what true professionalism means.
“The day we convince ourselves that there is just one way of delivering software [...] is the day that we stop evolving”
- Sandro Mancuso
Finally I find an author who recognises software development as a lifestyle and passion and realises what true professionalism means.
“The day we convince ourselves that there is just one way of delivering software [...] is the day that we stop evolving”
- Sandro Mancuso
April 5, 2014
Excellent, compact and has many things you want to know. Besides the community was involved whilst it was written hence lots of good feedback went into it as well.
Its also a good reference book if you are new in the area.
I read some parts of the book multiple-times.
Its also a good reference book if you are new in the area.
I read some parts of the book multiple-times.
Read
March 19, 2016Thank you
Great book, Sandro share is experience in his book. This is an inspiring book, I would recommend to who seek to be a professional developers. I would even recommend to read to everyone out there thinking their are senior, master developers !!!
Great book, Sandro share is experience in his book. This is an inspiring book, I would recommend to who seek to be a professional developers. I would even recommend to read to everyone out there thinking their are senior, master developers !!!
August 27, 2018
Found the time to read this book, after reading, long time ago, Clean coders.
I must say I liked it a lot. This book is a “must” for every software developer.
I liked a lot the stories from past jobs, especially when Sandro was in Brazil and he was starting his career.
I must say I liked it a lot. This book is a “must” for every software developer.
I liked a lot the stories from past jobs, especially when Sandro was in Brazil and he was starting his career.
June 13, 2016
Passion. That summarizes it all. Software craftsmen are passionate about software development and their profession.
==========
Being a craftsman doesn’t mean you are superior or better than any other developer. When a developer calls herself a craftsman, she is just stating the values and professional attitude she has. But that doesn’t mean that developers who don’t call themselves craftsmen don’t have the same values or attitude.
==========
Being a software craftsman is about more than just waking up in the morning, going to work, and getting paid to do some stuff. Software craftsmen wake up in the morning to make things better and to change the world we live in. Being a software craftsman is far more than writing well-crafted code or being a software developer. It’s a lifestyle—a commitment to excellence. Embrace it. Be proud of the role you play in the evolution of our society.
==========
Software craftsmen are humble, always ready to learn from more-experienced developers, and eager to help the less experienced.
==========
Craftsmanship is an ideology. XP is a methodology. An ideology is about values, attitude, and behavior. A methodology is about practices that solve specific problems.
==========
“Making things work is the minimum I expect from someone who is paid for it,” he calmly said.
==========
Back in the 1990s, a developer would be considered a senior developer if she could write code that no one else could understand.
==========
“How it is done is as important as getting it done.”
==========
And writing code that no one else could understand would make you a senior developer straightaway.
==========
Software developers are normally considered senior according to the number of years they have worked in the industry and not according to their knowledge.
==========
Seniority is not a badge we can wear for the rest of our lives after completing five years in the industry.
==========
Modern developers need to know how to speak to customers, automate tests and deployment, make technological choices that may affect the entire business, work in distributed teams, help clients to define and prioritize requirements, report progress, manage changes and expectations, present products to potential clients or partners, help with pre-sales activities, estimate time and costs, interview new team members, design and evolve the software architecture, deal with nonfunctional requirements and service level agreements (SLAs), understand business goals, make decisions based on trade-offs, keep an eye on new technologies and better ways to do things, worry about the value delivered to their customers, and many other things.
==========
We don’t do Agile. Either we are Agile or we are not.
==========
To fit this way of working, software professionals had to evolve. Instead of just being specialists, like in the past, companies started to look for generalizing specialists. Being good at writing code is the minimum skill expected from software professionals. Testing, analysis, ability to understand the business, good communication, and a more extroverted personality became part of the skill set that software professionals need today.
==========
Many Agile projects are now, steadily and iteratively, producing crap code.
==========
I have seen many companies state strongly that they wanted to adopt Agile but not make much effort to actually be agile.
==========
Agile transformations were focused on process but not on technical disciplines, which means that they did very little to make developers better.
==========
Many people in the Agile and Lean communities love to talk about Toyota and how successful they became changing their process, reducing waste (or inventory), limiting work in progress (WIP), and all the great things they have done.
==========
Every software process, including Agile processes, will assume technical excellence. Without technical excellence, every software project will be a painful, frustrating, and expensive experience.
==========
Agile methodologies help companies to do the right thing. Software Craftsmanship is about professionalism in software development. Software Craftsmanship is an ideology, which many developers decided to adopt in order to get better at what they do.
==========
Software craftsmanship is a long journey to mastery. It’s a mindset where software developers choose to be responsible for their own careers, constantly learning new tools and techniques and constantly bettering themselves. Software Craftsmanship is all about putting responsibility, professionalism, pragmatism, and pride back into software development.
==========
Software Craftsmanship is about professionalism in software development.
==========
For some, it is a trade. For others, it is engineering. Very few would say that software development is a science.
==========
When we talk about steadily adding value, we are not just talking about adding new features and fixing bugs. This is also about constantly improving the structure of the code, keeping it clean, extendable, testable, and easy to maintain.
==========
A paraphrase of a Boy Scout rule (first applied to software by Uncle Bob) states that we should always leave the code cleaner than we found it.
==========
Learning from each other is by far the best way for us to become better. Writing blogs, contributing to open source projects, making our code publicly available, becoming part of our local communities, and pairing with other developers are some of the ways we can contribute to the greater good of our industry.
==========
Sharing our knowledge with less-experienced software craftsmen is our moral obligation.
==========
Clients don’t pay professionals to learn. Clients pay professionals for their knowledge and skills.
==========
If developers want to be treated as professionals, they should start acting as professionals. A software professional must, among other things, get involved and contribute to the business, provide options and solutions, and offer the best service when it comes to the implementation, technologies, and quality of what we produce.
==========
A few examples would be The Pragmatic Programmer, The Mythical Man-Month, Design Patterns (GoF), Test-Driven Development: By Example, Extreme Programming Explained: Embrace Change, The Clean Coder, Software Craftsmanship, and Refactoring. It may take many years to master the content in the books in this category.
==========
All software developers should have their own blogs, regardless of how much experience they have. We should all share our experiences and findings and help to create a great community of professionals.
==========
A common problem that developers have with pet projects is finding a good idea. The good news is that you do not need one. You are not starting a new business. I always advise developers to choose a subject that they are very passionate about.
==========
Many of us get very attached to our own applications and code base, which can blind us to what the market really wants.
==========
Usually, we think of ourselves as very good developers, and we like to think that all the other developers are bad. Other developers write crap code, not us.
==========
Not knowing what we don’t know is also called second-level ignorance.
==========
If you are the type of person that says, “I don’t want to touch a computer outside work,” you probably should think again about your career choice; maybe software development is not for you.
==========
We were not acting professionally because we never said NO.
==========
We spent a few weeks working long hours and weekends. Of course when I say we, I am talking about the developers. The manager and the business analyst were nowhere to be seen after six o’clock and almost never available on the phone on weekends.
==========
saying yes to avoid disappointment is just lying.
==========
Professionalism means being honest with ourselves, with our teammates, and with our managers and customers.
==========
Raising the red flag as early as possible, indicating that something is wrong, allows the team and all people involved to be pragmatic and come up with alternative solutions.
==========
Rather than construction, programming is more like gardening.
==========
Our industry is finally learning that quality code may not guarantee the success of a project, but it can definitely be the main cause of its failure.
==========
It is easy to say that a piece of code is badly written. It is easy to complain or even laugh. But the question is: are you good enough to make it better?
==========
Although there are overlaps between Agile and Software Craftsmanship, Software Craftsmanship complements Agile by focusing on technical practices and providing a quick and short feedback loop on the quality of our code.
==========
In 1996, Kent Beck introduced and combined a set of practices that originated XP. Kent became the project leader on the Chrysler Comprehensive Compensation (C3) payroll system, and he proposed and implemented some changes in their practices—some of them based on his work with Ward Cunningham in the mid-1980s.
==========
The Boy Scout rule says: “Always leave the campground cleaner than you found it.”
==========
This is known as the “broken windows theory.”
==========
We, software craftsmen, value and control our careers.
==========
autonomy, mastery, and purpose.
==========
Our careers will always be more important than any specific job or company.
==========
More bluntly, only incompetent people are scared to lose their jobs.
==========
Your problem is that your selection process and whoever is responsible for it sucks. The selection process must be changed and whoever is behind it should be fired.”
==========
Good developers want to work with good developers and for them that is the only thing that matters.
==========
When a software craftsman makes a recommendation, it is implied that the recommended developer is also a software craftsman, and that he or she shares the same passion, values, principles, and dedication.
==========
As a company, don’t think you are the only one applying filters and looking for the best people. Good developers are also filtering bad companies out and looking for the best ones.
==========
During an interview, it is important to understand that we are not begging for a job. We are doing a business negotiation.
==========
The only thing I regret about that interview is that we were not fast enough to get back to him and he got a job somewhere else.
==========
Dealing with the client’s bureaucracy, business pressure, production issues, and stakeholders’ management are things that cannot be learned while coding a pet project or in our spare time. These are things that we just learn when we are actively involved in delivering software for real customers.
==========
Good developers don’t hire bad developers. They will try to find developers who are even better than they are; they know how important it is to have a great team—not just for the benefit of the company but for their own benefit as well.
==========
The ability to answer these stupid brainteasers has nothing to do with writing well-crafted code, being a good team player, or having a professional attitude. Brainteasers are a total waste of time, as Google interviewers finally realized after using them for a long time. At least for them, better later than never.
==========
Good developers are also interviewing companies and they will exercise their option to reject the bad ones.
==========
In projects like that, it is almost impossible for a single developer to change the world. Certain projects need a bigger intervention, where external experts need to be brought in and take control of the project for a period of time.
==========
Embracing Agile processes and ideology is essential for providing the right environment for improving morale, but when it comes to developers, we need more than that.
==========
community, internal or external. That’s exactly how LSCC, the largest Software Craftsmanship community in the world, started. Internal communities also start like that.
==========
It is not difficult to bring a culture of learning into an organization. The only thing needed is a passionate developer willing to start it. Stop finding excuses and be this developer.
==========
Many developers suffer from what Kent Beck calls adolescent surety.
==========
Developers in this group believe that looking smart is more important than being smart.
==========
Very few technical managers were actually great developers in the past, and even fewer were actually promoted because of their software development skills; they would disagree with this statement, of course. If they still write code, they may sometimes be perceived as Time Crunched.
==========
Don’t try to talk about details of your code or frameworks with managers or product owners. Instead, tell them about the benefits that your proposal has for the project: reducing maintenance costs, more reliable and frequent releases, and so on.
==========
You need to expose yourself. You need to be visible. You need to demonstrate how passionate you are and how much you care about the project and about what you are proposing.
==========
“If I make my boss happy, I’ll get promoted. I don’t care about the company, I care about my bonus.” This is selfish, unprofessional, and immoral.
==========
Developers are creatures of habit and are generally very opinionated. You cannot just go there and tell them what to do. The most efficient way to introduce a technical practice is to lead by example. Ask them to pair with you and show them how you do it.
==========
Real software professionals understand that responsibility should always come with accountability.
==========
Any stupid developer can make things work. What distinguishes great and mediocre developers is how they make things work.
==========
“Four Rules of Simple Design,” as defined by Kent Beck: 1. Pass all tests 2. Clear, expressive, and consistent 3. Duplicates no behavior or configuration 4. Minimal methods, classes, and modules Over the years, many people reworded these four rules (or elements). I personally prefer J. B. Rainsberger’s version: 1. Passes all tests 2. Minimizes duplication 3. Maximizes clarity 4. Has fewer elements
==========
The pragmatic approach would be to only introduce abstractions when they are really needed.
==========
Craftsmanship without pragmatism is not craftsmanship. A craftsman’s primary focus is customer satisfaction. Besides quality, time and cost are part of this satisfaction. Code cannot be considered well-crafted code if it doesn’t provide value.
==========
Quality is not expensive. The lack of skills is what makes well-crafted software expensive.
==========
code—code that is testable, easy to understand, and easy to maintain.
==========
Software craftsmen are on a mission. They focus on bettering themselves, constantly investing in their own careers, and learning, teaching, sharing, and delivering value to every single client.
==========
==========
Being a craftsman doesn’t mean you are superior or better than any other developer. When a developer calls herself a craftsman, she is just stating the values and professional attitude she has. But that doesn’t mean that developers who don’t call themselves craftsmen don’t have the same values or attitude.
==========
Being a software craftsman is about more than just waking up in the morning, going to work, and getting paid to do some stuff. Software craftsmen wake up in the morning to make things better and to change the world we live in. Being a software craftsman is far more than writing well-crafted code or being a software developer. It’s a lifestyle—a commitment to excellence. Embrace it. Be proud of the role you play in the evolution of our society.
==========
Software craftsmen are humble, always ready to learn from more-experienced developers, and eager to help the less experienced.
==========
Craftsmanship is an ideology. XP is a methodology. An ideology is about values, attitude, and behavior. A methodology is about practices that solve specific problems.
==========
“Making things work is the minimum I expect from someone who is paid for it,” he calmly said.
==========
Back in the 1990s, a developer would be considered a senior developer if she could write code that no one else could understand.
==========
“How it is done is as important as getting it done.”
==========
And writing code that no one else could understand would make you a senior developer straightaway.
==========
Software developers are normally considered senior according to the number of years they have worked in the industry and not according to their knowledge.
==========
Seniority is not a badge we can wear for the rest of our lives after completing five years in the industry.
==========
Modern developers need to know how to speak to customers, automate tests and deployment, make technological choices that may affect the entire business, work in distributed teams, help clients to define and prioritize requirements, report progress, manage changes and expectations, present products to potential clients or partners, help with pre-sales activities, estimate time and costs, interview new team members, design and evolve the software architecture, deal with nonfunctional requirements and service level agreements (SLAs), understand business goals, make decisions based on trade-offs, keep an eye on new technologies and better ways to do things, worry about the value delivered to their customers, and many other things.
==========
We don’t do Agile. Either we are Agile or we are not.
==========
To fit this way of working, software professionals had to evolve. Instead of just being specialists, like in the past, companies started to look for generalizing specialists. Being good at writing code is the minimum skill expected from software professionals. Testing, analysis, ability to understand the business, good communication, and a more extroverted personality became part of the skill set that software professionals need today.
==========
Many Agile projects are now, steadily and iteratively, producing crap code.
==========
I have seen many companies state strongly that they wanted to adopt Agile but not make much effort to actually be agile.
==========
Agile transformations were focused on process but not on technical disciplines, which means that they did very little to make developers better.
==========
Many people in the Agile and Lean communities love to talk about Toyota and how successful they became changing their process, reducing waste (or inventory), limiting work in progress (WIP), and all the great things they have done.
==========
Every software process, including Agile processes, will assume technical excellence. Without technical excellence, every software project will be a painful, frustrating, and expensive experience.
==========
Agile methodologies help companies to do the right thing. Software Craftsmanship is about professionalism in software development. Software Craftsmanship is an ideology, which many developers decided to adopt in order to get better at what they do.
==========
Software craftsmanship is a long journey to mastery. It’s a mindset where software developers choose to be responsible for their own careers, constantly learning new tools and techniques and constantly bettering themselves. Software Craftsmanship is all about putting responsibility, professionalism, pragmatism, and pride back into software development.
==========
Software Craftsmanship is about professionalism in software development.
==========
For some, it is a trade. For others, it is engineering. Very few would say that software development is a science.
==========
When we talk about steadily adding value, we are not just talking about adding new features and fixing bugs. This is also about constantly improving the structure of the code, keeping it clean, extendable, testable, and easy to maintain.
==========
A paraphrase of a Boy Scout rule (first applied to software by Uncle Bob) states that we should always leave the code cleaner than we found it.
==========
Learning from each other is by far the best way for us to become better. Writing blogs, contributing to open source projects, making our code publicly available, becoming part of our local communities, and pairing with other developers are some of the ways we can contribute to the greater good of our industry.
==========
Sharing our knowledge with less-experienced software craftsmen is our moral obligation.
==========
Clients don’t pay professionals to learn. Clients pay professionals for their knowledge and skills.
==========
If developers want to be treated as professionals, they should start acting as professionals. A software professional must, among other things, get involved and contribute to the business, provide options and solutions, and offer the best service when it comes to the implementation, technologies, and quality of what we produce.
==========
A few examples would be The Pragmatic Programmer, The Mythical Man-Month, Design Patterns (GoF), Test-Driven Development: By Example, Extreme Programming Explained: Embrace Change, The Clean Coder, Software Craftsmanship, and Refactoring. It may take many years to master the content in the books in this category.
==========
All software developers should have their own blogs, regardless of how much experience they have. We should all share our experiences and findings and help to create a great community of professionals.
==========
A common problem that developers have with pet projects is finding a good idea. The good news is that you do not need one. You are not starting a new business. I always advise developers to choose a subject that they are very passionate about.
==========
Many of us get very attached to our own applications and code base, which can blind us to what the market really wants.
==========
Usually, we think of ourselves as very good developers, and we like to think that all the other developers are bad. Other developers write crap code, not us.
==========
Not knowing what we don’t know is also called second-level ignorance.
==========
If you are the type of person that says, “I don’t want to touch a computer outside work,” you probably should think again about your career choice; maybe software development is not for you.
==========
We were not acting professionally because we never said NO.
==========
We spent a few weeks working long hours and weekends. Of course when I say we, I am talking about the developers. The manager and the business analyst were nowhere to be seen after six o’clock and almost never available on the phone on weekends.
==========
saying yes to avoid disappointment is just lying.
==========
Professionalism means being honest with ourselves, with our teammates, and with our managers and customers.
==========
Raising the red flag as early as possible, indicating that something is wrong, allows the team and all people involved to be pragmatic and come up with alternative solutions.
==========
Rather than construction, programming is more like gardening.
==========
Our industry is finally learning that quality code may not guarantee the success of a project, but it can definitely be the main cause of its failure.
==========
It is easy to say that a piece of code is badly written. It is easy to complain or even laugh. But the question is: are you good enough to make it better?
==========
Although there are overlaps between Agile and Software Craftsmanship, Software Craftsmanship complements Agile by focusing on technical practices and providing a quick and short feedback loop on the quality of our code.
==========
In 1996, Kent Beck introduced and combined a set of practices that originated XP. Kent became the project leader on the Chrysler Comprehensive Compensation (C3) payroll system, and he proposed and implemented some changes in their practices—some of them based on his work with Ward Cunningham in the mid-1980s.
==========
The Boy Scout rule says: “Always leave the campground cleaner than you found it.”
==========
This is known as the “broken windows theory.”
==========
We, software craftsmen, value and control our careers.
==========
autonomy, mastery, and purpose.
==========
Our careers will always be more important than any specific job or company.
==========
More bluntly, only incompetent people are scared to lose their jobs.
==========
Your problem is that your selection process and whoever is responsible for it sucks. The selection process must be changed and whoever is behind it should be fired.”
==========
Good developers want to work with good developers and for them that is the only thing that matters.
==========
When a software craftsman makes a recommendation, it is implied that the recommended developer is also a software craftsman, and that he or she shares the same passion, values, principles, and dedication.
==========
As a company, don’t think you are the only one applying filters and looking for the best people. Good developers are also filtering bad companies out and looking for the best ones.
==========
During an interview, it is important to understand that we are not begging for a job. We are doing a business negotiation.
==========
The only thing I regret about that interview is that we were not fast enough to get back to him and he got a job somewhere else.
==========
Dealing with the client’s bureaucracy, business pressure, production issues, and stakeholders’ management are things that cannot be learned while coding a pet project or in our spare time. These are things that we just learn when we are actively involved in delivering software for real customers.
==========
Good developers don’t hire bad developers. They will try to find developers who are even better than they are; they know how important it is to have a great team—not just for the benefit of the company but for their own benefit as well.
==========
The ability to answer these stupid brainteasers has nothing to do with writing well-crafted code, being a good team player, or having a professional attitude. Brainteasers are a total waste of time, as Google interviewers finally realized after using them for a long time. At least for them, better later than never.
==========
Good developers are also interviewing companies and they will exercise their option to reject the bad ones.
==========
In projects like that, it is almost impossible for a single developer to change the world. Certain projects need a bigger intervention, where external experts need to be brought in and take control of the project for a period of time.
==========
Embracing Agile processes and ideology is essential for providing the right environment for improving morale, but when it comes to developers, we need more than that.
==========
community, internal or external. That’s exactly how LSCC, the largest Software Craftsmanship community in the world, started. Internal communities also start like that.
==========
It is not difficult to bring a culture of learning into an organization. The only thing needed is a passionate developer willing to start it. Stop finding excuses and be this developer.
==========
Many developers suffer from what Kent Beck calls adolescent surety.
==========
Developers in this group believe that looking smart is more important than being smart.
==========
Very few technical managers were actually great developers in the past, and even fewer were actually promoted because of their software development skills; they would disagree with this statement, of course. If they still write code, they may sometimes be perceived as Time Crunched.
==========
Don’t try to talk about details of your code or frameworks with managers or product owners. Instead, tell them about the benefits that your proposal has for the project: reducing maintenance costs, more reliable and frequent releases, and so on.
==========
You need to expose yourself. You need to be visible. You need to demonstrate how passionate you are and how much you care about the project and about what you are proposing.
==========
“If I make my boss happy, I’ll get promoted. I don’t care about the company, I care about my bonus.” This is selfish, unprofessional, and immoral.
==========
Developers are creatures of habit and are generally very opinionated. You cannot just go there and tell them what to do. The most efficient way to introduce a technical practice is to lead by example. Ask them to pair with you and show them how you do it.
==========
Real software professionals understand that responsibility should always come with accountability.
==========
Any stupid developer can make things work. What distinguishes great and mediocre developers is how they make things work.
==========
“Four Rules of Simple Design,” as defined by Kent Beck: 1. Pass all tests 2. Clear, expressive, and consistent 3. Duplicates no behavior or configuration 4. Minimal methods, classes, and modules Over the years, many people reworded these four rules (or elements). I personally prefer J. B. Rainsberger’s version: 1. Passes all tests 2. Minimizes duplication 3. Maximizes clarity 4. Has fewer elements
==========
The pragmatic approach would be to only introduce abstractions when they are really needed.
==========
Craftsmanship without pragmatism is not craftsmanship. A craftsman’s primary focus is customer satisfaction. Besides quality, time and cost are part of this satisfaction. Code cannot be considered well-crafted code if it doesn’t provide value.
==========
Quality is not expensive. The lack of skills is what makes well-crafted software expensive.
==========
code—code that is testable, easy to understand, and easy to maintain.
==========
Software craftsmen are on a mission. They focus on bettering themselves, constantly investing in their own careers, and learning, teaching, sharing, and delivering value to every single client.
==========
July 1, 2022
Disappointing book, I honestly expected more from the respected Addison-Wesley Robert C. Martin series.
My main complaints are twofold:
First of all, the book does not tell you anything new or shocking. Software Craftmanship is (amongst other things) about professionalism; this will only be new for you if you’ve been doing software amateurism so far. So I strongly doubt that this will excite a large crowd of readers.
The software craftsmanship manifest is also full of cliches that no one will object to (as the author himself admits).
So was this new and shocking 10 years ago? Mmm, I strongly doubt it….
My second objection against this book is that every statement is distilled from anecdotal evidence of the author…. A bit of anecdotal evidence might spice up a chapter or presentation but here it’s about the only trick in the book….
Ergo, not recommended….
My main complaints are twofold:
First of all, the book does not tell you anything new or shocking. Software Craftmanship is (amongst other things) about professionalism; this will only be new for you if you’ve been doing software amateurism so far. So I strongly doubt that this will excite a large crowd of readers.
The software craftsmanship manifest is also full of cliches that no one will object to (as the author himself admits).
So was this new and shocking 10 years ago? Mmm, I strongly doubt it….
My second objection against this book is that every statement is distilled from anecdotal evidence of the author…. A bit of anecdotal evidence might spice up a chapter or presentation but here it’s about the only trick in the book….
Ergo, not recommended….
July 11, 2020
Sandro explains his own professional story, sharing some war stories easy to identify with, and shares his view of the Software Craftsmanship movement. Well written, entertaining, and easy to read, and also full of recommendations. The target audience is software developers curious about Software Craftsmanship and people who already call themselves Software Craftsmen, but it is very far from being the book that brings this ideology and lifestyle (in the words of the author) to wider audiences, as he paints a terrible picture of managers, agile coaches, architects, and developers who don't have coding as their hobby.
February 4, 2021
A great book, but I feel like the most of the values are more less the same like in The Pragmatic Programmer.
June 8, 2017
This is one of my favourite reads when it comes to working in software development. Disclaimer: I am a Business Analyst, not developer. So I look at it purely from the side of working in 'IT' and the value of crafted software to other team members and the 'business'.
Nevertheless, I feel this is an excellent read for ANY (especially junior) IT worker, and find that especially the anecdotal examples are very helpful.
Let me give you two examples: Last week a friend (a strategy consultant) complained that she was working late and all her colleagues and line managers had fucked off and dropped completion of a presentation on her. She's been working long hours for ages, believing she needed to prove that she was good and could not say 'no'. I remembered Sandro's example of working insane hours in Sao Paolo and sleeping in his car. And his advise to not let yourself be exploited, and suggested she read at list some parts of this book....
Reading Sandro's thoughts and examples on good rather than complex code and that senior does not mean making it complicated, made me reflect on my work as a BA. And though I could not have articulated it that well, I realised that I have been guilty (as a junior back then) to create complicated models for the sake of it, basically to show off. These days I do the opposite: models and stories I keep as simplistic and lean as possible. And you know what: my stakeholders are much more engaged and outcome is much better....
So I can not recommend this book highly enough
(as I mentioned above, I cannot fully comment on some of the more controversial aspects of code quality he discusses, and while it sounds reasonable to me, there might be valid discussions to be had. nevertheless, that does not reduce the value of the book imo)
Nevertheless, I feel this is an excellent read for ANY (especially junior) IT worker, and find that especially the anecdotal examples are very helpful.
Let me give you two examples: Last week a friend (a strategy consultant) complained that she was working late and all her colleagues and line managers had fucked off and dropped completion of a presentation on her. She's been working long hours for ages, believing she needed to prove that she was good and could not say 'no'. I remembered Sandro's example of working insane hours in Sao Paolo and sleeping in his car. And his advise to not let yourself be exploited, and suggested she read at list some parts of this book....
Reading Sandro's thoughts and examples on good rather than complex code and that senior does not mean making it complicated, made me reflect on my work as a BA. And though I could not have articulated it that well, I realised that I have been guilty (as a junior back then) to create complicated models for the sake of it, basically to show off. These days I do the opposite: models and stories I keep as simplistic and lean as possible. And you know what: my stakeholders are much more engaged and outcome is much better....
So I can not recommend this book highly enough
(as I mentioned above, I cannot fully comment on some of the more controversial aspects of code quality he discusses, and while it sounds reasonable to me, there might be valid discussions to be had. nevertheless, that does not reduce the value of the book imo)
September 8, 2017
Recently we undertook an agile transformation and changed around our job descriptions at work, and the term "software craftsmanship" was added to all the software engineer job descriptions - this book written by the founder of the London Software Craftsmanship Community, someone whose whole company is based around software craftsmanship.
First off, this is very clearly a manifesto, almost evangelical in places. Agile Coaches and Managers come in for some criticism, along with a number of parts of the software industry. This book really does make you think about really fundamental questions such as if you are a software developer are you a factory worker on a production line, on an empowered and skilled professional?
The book is not particularly long, but crammed with good advice on both how to become a software craftsman yourself, and to bring them into and grow them within your organisation. You may not agree with everything the book says, but even if you disagree it will make you think.
First off, this is very clearly a manifesto, almost evangelical in places. Agile Coaches and Managers come in for some criticism, along with a number of parts of the software industry. This book really does make you think about really fundamental questions such as if you are a software developer are you a factory worker on a production line, on an empowered and skilled professional?
The book is not particularly long, but crammed with good advice on both how to become a software craftsman yourself, and to bring them into and grow them within your organisation. You may not agree with everything the book says, but even if you disagree it will make you think.
May 26, 2014
I’m not that happy with the term „Software Craftsmanship”. That said, the book by Sandro Mancuso is great. I can’t remember that I ever marked so many parts of a book as I did with this one. Sandro explains what a professional developer should care about in a way everyone can understand. Not with fancy words but in a way you can adapt on a daily basis.
I like his points on that we have to do more than write software that just works. It has to fit in the big picture of the company and when it is only clean but doesn’t add value one can’t be satisfied. His points on how to sell the ideas will help with your own adaption and can save you from big disappointments and wasting your time.
If you are passionate about your work as a software developer you should read this book. It’s a great book to push your career forward.
I like his points on that we have to do more than write software that just works. It has to fit in the big picture of the company and when it is only clean but doesn’t add value one can’t be satisfied. His points on how to sell the ideas will help with your own adaption and can save you from big disappointments and wasting your time.
If you are passionate about your work as a software developer you should read this book. It’s a great book to push your career forward.
December 12, 2017
This is a great book not only for developers but also for managers. We may have been developers once, and we could recognize most of the problems that Sandro experienced (BDUF, use of GoF design patterns just because why not, intentionally obfuscated code etc) and now we suddenly see a new trend among our best developers. This trend is craftsmanship and it's a good one. We will learn how to work with them, how to guide aspiring craftsmen and how to guide our entire teams, introducing the craftsmen ideology into our one to one discussions. I repeat, all the book can be read by managers, not only some chapters.
September 20, 2018
I would recommend this book to any junior developer. Hell, I'm thinking this is a good read for everyone new to a job, as some of the underlying principles really apply to any industry. Having said the latter, it is developer centric, so may confuse the non initiated.
I am a Product Owner / Business Analyst and have been in the industry for over a decade, but still found it an interesting, at worst confirming, at best inspiring and thought provoking read.
Yes, at times it can come across a bit preachy, but hey, that's ok...
I am a Product Owner / Business Analyst and have been in the industry for over a decade, but still found it an interesting, at worst confirming, at best inspiring and thought provoking read.
Yes, at times it can come across a bit preachy, but hey, that's ok...
December 28, 2013
Great book about professionalism and how some people understands the profession of software development. A really inspiring read.
September 26, 2018
Magnífico. Yo creo que es uno de esos libros que van a marcar un antes y un después en la profesión.
January 11, 2020
This book has inspired me BIG! I feel lucky to be in this industry, I will never give this profession for granted and will always aim for bettering myself every single day. Thank you, Sandro.
Displaying 1 - 30 of 117 reviews