@jpettys
You take issue with the quote @6:50, "It is our job to say no to our clients when they ask us for something we know is not going to work or that is not going to be done by a certain deadline." Would you proceed with a plan that you know wouldn't work, or that has an impossible deadline? I presume not. Would you just phrase the position differently than Sandro did in this particular sentence of the book? You seem to see the quote as anti-collaborative; I don't interpret it that way. This seems like a classic straw man. :(
@stevecarter8810
Starts to get to the point around 8:40
@urisimchoni3936
The "medieval guild as substitute for actual education" is exactly what the Software Craftsmanship movement is about. There are intangibles that cannot be taught in class because just lecturing about cohesion and coupling for example, won't let the concepts sink into one's head. The "Guild method" is not a substitute for education, education teaches you (well, supposed to...) how to think for yourself. But education is no substitute for being supervised by an experienced professional either.
@GavinCawley
An apprenticeship is an education. We still have them - a PhD is essentially an apprenticeship in research in some field. For some subjects an apprenticeship is likely to be a better education than going to lectures, seminars and labs.
@ManuelBasiri
I have a feeling this channel starting to lose its value for my time.
@miraculixxs
I was hoping we are over the language of things and we can finally focus on stuff that matters. Apparently not
@7th_CAV_Trooper
Medieval guildsmanship is a better idea than modern education. Also, my friends who natively speak gendered languages are very amused by leftist English speakers trying to remove gender from what were effectively genderneutral terms. Craftsman doesn't mean a man who crafts. Let's get over ourselves and get back to building systems.
@alekseykostyuk3806
This video's approach is quite disappointing, especially for an audience that values depth in software development. The way the term "craftsman" is critiqued as "outdated and gendered" feels like an attack on form over substance. While language evolves, focusing so heavily on a single term to undermine an entire movement's core ideas is a classic straw man fallacy and distracts from the genuine principles of Software Craftsmanship. It comes across as a cheap shot, rather than a constructive critique. Furthermore, framing developers' desire to reject harmful requirements as "selfish" or "egoism" is a clear attack on motives. This unfairly dismisses a nuanced professional stance by attributing negative intent, rather than discussing the valid reasons why developers might advocate for better solutions that ultimately benefit the business. Lastly, the assertion that "quality code" is the "only good idea" from Software Craftsmanship is a gross oversimplification and a false dilemma. This movement encompasses professionalism, continuous learning, robust engineering practices like TDD, and a commitment to excellence – all of which are incredibly valuable and shouldn't be dismissed so casually. Overall, this video uses manipulative rhetorical techniques to devalue a significant movement in software development. For an audience of programmers who genuinely care about the craft and the quality of their work, this kind of reductive and dismissive content is frankly insulting and inappropriate. It appears this video might be attempting to frame a "marketing war" between Continuous Delivery (CD) and Software Craftsmanship (SC). Let's be clear: these are not opposing forces. High-quality code, a cornerstone of SC, directly enables efficient and reliable CD. Trying to elevate one by tearing down the other is a disservice to both concepts and to the audience. If the channel aims to promote CD, focusing on its merits rather than undermining other valuable methodologies would be far more productive. If there's no intention to provide a balanced discussion of Software Craftsmanship, it would be better not to mention it at all, rather than presenting such a biased and incomplete perspective. Finally, the perceived personal animosity or attempt to devalue figures like Robert C. Martin (a pivotal figure in both Agile and Software Craftsmanship) through such critiques is particularly unacceptable. Professional discourse requires respect for significant contributions, even when critically analyzing ideas. This approach does not foster a healthy discussion within the developer community.
@JorgSesterhenn
I enjoy the videos on your own channel. I'd love to see you bring some of your own style and coaching ideas to this audience. What should I take away from this video? Please, drop the hate and the special effects - I would like that. I feel like there is at least one more aspect of craftsmanship that aligns very well with your content: The neglect of technical coaching and practicing in groups in current IT education. I think this was at the heart of the apprenticeship idea favored by the craftsmanship movement and I liked that.
@AndrewHarmelLaw
Disappointing to see the number of commenters here plainly ignoring 2/3 of the channel guidelines. Posting them again just in case y’all just had a temporary memory blip: 1) be civil and respectful 3) challenge the argument not the person. (I also notice no one’s calling out the fact Dan has said similar things. Do better folks. You’re making Emily’s arguments for her.)
@AK-vx4dy
I'm not from this language but I'm pretty sure than "man" postfix doesn't mean male but just simply human/person having some occupation, there is no need to force ideology
@jasondbaker
I use the term "sustainability" to describe good software craftsmanship. Our goal should be to change software in sustainable ways rather than constantly applying patches to solve defects temporarily. I've worked with several companies where engineers spent nearly all of their time applying temporary patches to keep systems running. They were never given the time to really dig into the root cause of issues and fix problems in a more permanent, sustainable way. I see this often in Scrum shops where dev teams are told they must complete a certain number of points each sprint.
@peterismartinsons4855
'Men' or 'women' in this regard is offtopic. Every sensible person is well aware that calling someone in a name that does not correspond to his biological gender does not change anything. Results is what matters.
@AxWarhawk
As a non-native speaker, I am wondering: do the -man suffixes originate really from the word "man", indicating gender, or is it actually from the word "human"? Or is "human" actually a gendered word?
@stevecarter8810
Ngl a real apprenticeship and journeyman progression would beat the crap out of amping up graduates on a bunch of frameworks then throwing them into a work-from-home desert with nobody to overhear or learn from.
@RetroFab
Are you serious? This is where you took it? I suppose the term HUMAN is archaic for you then... Is it HUPERSON? Please don't let this channel get mixed up with ideology, it was so good!
@hunahpuyamamoto3964
Ugh. Of all the problems in software development you’re worried about the syllable “man” in “craftsman”?! The undermines everything you said after that. You should have kept that card hidden.
@sozinsky-o9y
The issue isn't clean code or unclean code. Better code doesn't mean faster feature delivery. It's about _clean design_. If you have a nice design that your messy code is leaning on, its easy to throw away that messy code, rewrite it, whatever you want. But if you have a messy design that your clean code is leaning on, your clean code will be tortured/hard to test/hard to rewrite. Clean design >> clean code.
@gruttewibe76
I wholeheartedly agree with the code quality importance. If the code base is a mine field that's hard to navigate, you're not going to be agile, and that's a situation that is really easy to get into, but very hard to get out of. One thing I'd like to add is that not just the code should be high quality, but also the architecture (the roles of services and components, how they interact). With the adoption of microservices, or just in general distributed software, the architecture is possibly even more important than the code quality. Code is 'easy' to refactor, but architecture much less so.
@GuillemLlompartPiza