CUPID - For Joyful Coding • Daniel Terhorst-North • YOW! 2022

[@vichoohciv9443]

I think people at the comments are missing the point. At the start he changed principles for properties, but that doesn't necesarily stop there. The idea behind that change is exactly that these concepts are a suggestion. I don't think a set of suggestions can be adopted as a standard by developers, mostly because there is a LOT of us. I think a good amount of the points he did in this talk are fairly reasonable, so I may try to put them on practice. But that is the thing, is to our choice what to take.

[@yauriattamimi4435]

IMHO.., "CUPID" is not something used to superseed "SOLID". I believe both "CUPID" and "SOLID" are complementing each other. They have some interconnection in between.

[@allanwind295]

Daniel is fun to listen to and I enjoyed the anecdotes. CUPID, I am afraid, is DOA. Not because the ideas are bad, they are not, but... why are those the most important principles? Why isn't CUPID just another cliche fad term like the ones you dunk on? What is new here?

[@tomadam1465]

Just start coding, try to get better every day, and with time experience will come to understand what good code is, and how to write it. SOLID, CUPID, whatever we call it, these are all kind of guidlines, and deep understanding of these guidelines come only with time and hands on experience. Another takeaway is that everything in coding is a tradeoff. We always make a deal, the most important is that this deal is a good one on the long run for both the codebase and the team/future maintainers of the code. I do not feel like CUPID is againat SOLID. Rather feel like a good marketing tool to say that SOLID is bad to sell another set of approach to coding.

[@joshgraham4711]

A noble but futile attempt to bridge a chasm that cannot be spanned, my dear friend. This is something that needs to be experienced to be intrinsically understood, yet sadly close to 100% of software developers will never be in a context to do so. But thanks for trying.

[@Venthe]

So, let me get this straight: Solid is bad, because it can be replaced with "write simple code". But when I would ask how to write simple code, Dan explains "properties" that are satisfiable by... solid. Not every single one, but then again - solid works with code, not with domain, and that's certainly a valid addition. And no, saying "it's not X" doesn't make it so. One thing to note of value is the "missionary" example of center/edge principles. If only there were heuristics that satisfy "joyful" code. You know, there are one - it's called clean code, a book that teaches you about the mindset and heuristics. And this dismissing nature of craftsmanship? So when we ratchet the hard aspects, it's called DevOps and it's good, but when we wish to ratchet the "soft" parts line readability, then it's suddenly bad?:) I can understand that this opinion might come from a person who has seen a lot of confusion and cargo culting; but I'll give a prediction - let's imagine a world where CUPID won. Can anyone swear by these properties, that they would not be misunderstood and misapplied?

[@Venthe]

And now the part about "aging like..." is really disappointing. Scrum changed a lot. You can only release as fast as people are able to prepare a feature, devise how it should work and how the impact will be measured. Scrum does not tell you "release every two weeks", it says "ensure demo, retro every two weeks". As for the clean code, I'd love to see his notes. I can agree with the enterprise angle; and with the confrontational tone. That being said, clean code is one of the best books detailing heuristics, just as pragmatic programmer and refactoring is on their own fields. The sheer amount of times I've seen developers disregarding clean code and writing obvious garbage, excuse me - unjoyful - is stunning. I've got as much knowledge from continuous delivery, as from the clean code. It's a different knowledge, but knowledge nevertheless. Are they perfect? Not really. But I'm getting the vibe that someone is hopping on a bandwagon.

[@Venthe]

And the last one, idiomatic code. Quite good spot. So to sum things up: Dan is just adding things on top of what is already defined. Picked up elements from SOLID (but interestingly, fights tooth and nail to not admit that), DDD, clean code and "good practices" and selling this as something "better". It is not. It's different, valuable, but does not encompass solid, nor clean code, nor DDD. So overall, even if I took something from this talk, I'm quite disappointed.

[@terry-]

Great!

[@RoamingAdhocrat]

My first assumption was that a misiologist would be someone who studies pain :D