If you want to write good software (not scripts and macros), then it is easiest to use a language that detects errors when the code is written, not when it is running. Nothing beats Rust from that perspective.
@@CalifornianViking I am so so, so god damn tired of hearing the same BS from people who haven't even written a medium sized Rust project. Stop. Rust is no magic bullet. It DOES NOT PREVENT BUGS AT COMPILE-TIME. It might make it slightly harder compared to certain languages, but that's it. And the hell r you smoking to even say nothing beats Rust WHEN there are languages like Idris with totality checking and proof checkers.
One the best interviews because it is from someone who does not like clean code and tdd, so we have a lot of good questions!! Thanks Prime, now we are waiting by Martin Fowler
Bob is very reasonable and I respect his efforts trying to "model" good practices into what he calls "clean code". I don't necessarily agree with all of it, but nevertheless, I think there is value in organizing these ideas into a book back in the day. One should remember that "Clean Code" and "Design Patterns" were written many years ago with many points that don't exactly translate to languages/practices we have now-a-days. I feel that people who "hate" his ideas are too dogmatic in the sense that you either agree with something 100% or you have to disagree 100% and hate it. Most things in life are not as black and white. Even Agile, if you are old enough to have experience with a "waterfall-like" process, you know how the agile manifesto had a positive impact. Of course, like most things, people try to make it into a business (scrum) and the whole thing gets distorted. I think Scrum sucks, (and I prefer to stick to the manifesto principles) but it's much better than the old waterfall approach.
My gut feel it that whatever version of CC that Prime hates would probably be equally as hated by the progenitor of the concept. Case in point to the fact that the moment words leave your mouth you lose any and all control of them...
I've read/watched Uncle Bob for well over 10 years I think, his ideas about Clean Code, TDD etc, are more about being 'professional' than a set of rigid rules you must use to do proper programming. He genuinely wants the programming workforce to be Professional and his ideas are like SOP's that any real profession would have and use. Great talk! Looking forward to the next Uncle Bob installment :)
his "The Clean Coder" book was more about being professional. that's different from his "Clean Code" book, which is more about the code itself, as opposed to the act of coding
Well said. I like that Uncle Bob gives a type of direction to aim in. Other people boo him, but they often don't offer a better thing to aim at. Some say he's too rigid, but if you really listen, he's not rigid about things, he just has goals and standards. He admits no one meets them 100% including himself, and he's ok with that. The value you gain is in aiming and trying. To be more polite, to be less rude with our code. To respect each other, to publish good code often, to adapt well to changing requirments. He makes me proud to be a programmer.
Dude, he literally illustrated his ideas with code in the book. It's not ambiguous what he deemed desirable code to be. It's a program that consists in large part of layers of made up abstractions you have to delve through to try to see the actual code that does something. A code so abstract it may not do anything and you can still delve into it. This interview shows that he's still on that exact same path. Dude just loves abstractions and constructs
No, he has a lot of engineering practices suggestions and that's the main part of his work. Being professional is also a part of his framework, but it's not the main part. Between those 2, the more important part is engineering practices that he professes: Clean Code and Clean Architecture.
@@symix. That's not just any opinion. So yes; I would hope the large majority of software engineers would have that kind of critical thinking & backbone.
@@Wyvernnnn when did Uncle Bob say that either is better? Why would you even bring this kind of shit into the conversation? Are you crazy? Also there is difference between men and women. One of the two on average is better. And it's true at any thing we can take and compare the two.
@@KulaGGin He said that in his "Thought Police" blog post published in 2017 in the context of the Google engineer who got fired for saying that men make better software engineers than women If you think he's correct we have nothing to say to each other
We need a 2nd part, this one was amazing, the two of you guys made huges changes in my life, YOU BOTH, it was amazing to see you talking each other. OMG. What a nice video! I really like it
I like this format.. I like how you actually having a conversation not just one person talking about their ideas, but you challenge the ideas with your own. This was so interesting to watch, I did not realize that I was watching one hour long video.
Listened to this live on the way to work, was so invested, i just sat in the car once i got there until it ended. Top tier content better than any conference or seminar.
Bro, the problem is, people like primeagen claim authority in a field, they still have to learn in. Sometimes its shocking to me, how easily some followers of primeagean are swearing on basic principles and the foundation of successful everyday projects.
Honestly, this was a great interview because it highlights the one thing that many people in this industry no longer do, have conversations about different ideas. Based on the views expressed by Bob Martin, it becomes very apparent that the books and processes he has expressed are discoveries that his has made about his time in software development. They are purely ways that he has found to do what he does in a way that makes him feel like he has done a good job. They are not industry standards. They are insight into how one might approach solving a problem. They (his views and opinions) should be the starting point for meaningful conversations that make us think about things from a different perspective. I have noticed a decline in abstract thinking in the software industry and everything has become concrete. I miss the abstract thinking because some of the most beautiful solutions (and simplest) have come from discussions that started as abstract ideas. I cannot express how much I enjoyed this conversation and the way it was conducted in a manner that seemed to be about learning as opposed to dictating what is right and what is wrong. Thank you @ThePrimeTime. Something we also need to remember is that people that challenge our thinking are not to be dismissed. Have the hard conversations in a constructive fashion and everyone wins.
Most of all, he did not create many of these ideas. He just groups them together and re-explains what he learned from others. To talk to one another is to discover how little you know. It's a thoughtful direction for Prime to go into to bring such a guest on and dedicate an entire hour to. I truly think that his separation from the business world, like Netflix, has given him a clearer viewpoint on many matters as of late.
It is was my point of view comment before😊 Maybe it is because lot of people starting programming as the first subject. I starting coding to automate electronic process. So, programming to my understand doesnt has standard and focus on my business model and try apply the best pratices.
I'm really glad this interview happened. I think a lot of people that don't like uncle Bob miss a lot of nuance he talks about, brought in from decades of experience. Its also cool to go back and see his old stuff and see the evolution of his process. The 'functions do one thing' for example, he used to teach a completely different lesson.
People don't like Bob because most of his "nuance" is him squirming when people have objections to his dogma which somehow isn't dogma but at the same time kinda is, unless he's in a "conversation".
@@y00t00b3r I did not see that at all in the interview. Prime clearly had disagreements and things he agreed with, but asked him some clear explicit questions and received clear responses. I found the discussion about testing to be insightful and will be using Bob's philosophy going forward.
@@y00t00b3r what I got from this interview is, this isn't dogma. It's his personal preference. Clean Code is his daydreaming in the sense of him thinking about things that satisfy him which is why he comes off as dogmatic and simplistic. There is no real discussion or nuance in describing your favorite taste, you just say it to be that way. But when faced with reality he changes, as everyone does when they snap out of those daydreams. Doesn't mean those daydreams are somehow changed by reality, or that he's lying. It''s just reality is one thing, and our fantasies about simple joyful scenarios where we slay dragons in just the right way with our favorite power move and everyone claps is a different thing
0:00 - 0:59: Introductions 1:00 - 7:44: Why choose Clojure? 7:45 - 9:24: How do you reconcile Clean Code with a language like Clojure or Lisp? 9:25 - 11:12: How does Clean Code intersect with Go and Rust? 11:13 - 11:53: Goal of the interview 11:54 - 14:10: In the last 15 years, what has caused the shift away from design patterns? 14:11 - 16:05: Do you think modern software would benefit from a return to design patterns? 16:06 - 22:21: Reaching for abstractions before the problem is solved 22:22 - 25:11: Are you big on UML? 25:12 - 26:24: How do you feel about the current Agile movement? 26:25 - 27:57: What made Agile fall apart? 27:58 - 33:40: What is the correct way to Agile? 33:41 - 41:41: How did you arrive that a function should be less than 6 lines? 41:42 - 42:19: Accidental vs Essential Complexity 42:20 - 46:00: TDD 46:01 - 50:03: Why not start with the basic implementation? 50:04 - 52:00: Why test every line? 52:01 - 56:42: Module barriers 56:43 - 58:42: Is all code worth testing? 58:43 - 1:00:55: Errors as values vs Exceptions 1:00:56 - 1:06:20: What type of tests do you write? 1:06:21 - 1:11:07: Wrapping up
Takes a great man to invite a person who clearly has opposite views on some of the most important issues for both of them. Takes another great man to accept that invitation. And loved the open discussion. Is true that some of the more detailed topics were avoided but still... gg guys.
This is the type of interview I have been waiting for many years. First of all, thank you, Robert Martin, for your contribution to the IT industry, bringing new concepts around the development of software. However, I would like to say that, in my understanding, most people in the IT industry seem like they never ask themselves questions about why Clean Code, Clean Architecture, Scrum, Agile, Design Patterns, TDD, and other concepts. Nowadays, people just assume that these concepts are some type of standard. This interview was good because, in my understanding, Uncle Bob defined these concepts based on his own experience as a software developer and not as the result of scientific research.
my understanding of the history of clean code, design patterns, agile, etc. is this: 1. a bunch of dudes wrote a lot of code 2. they had problems 3. they did their best to understand the problems 4. they did their best to come up with solutions and find patterns 5. they did their best to document it all it's not magic that's gonna make our lives easy. programming is still hard but now we at least have some tools to approach problems and communicate with other developers. that's it!
I like how they somehow came upon an obscure architecture book that very few people ever read, and took the idea of design patterns from it. I don't think Alexander had any significant impact on architecture or aesthetics, while you see how much he (indirectly) had in programming.
6. A bunch of kids learn JavaScript on youtube. 7. They are introduced to all these patterns but aren't told why they matter 8. They ignore all this prior knowledge as pointless dogma that limits their productivity 9. They make all the same mistakes that people in the 60s made. 10. Go back to no. 1 ....
Your understanding is unfortunately not correct, and reflective of the shockingly bad state of the industry culture. First of all, "design patterns" came out a decade before Agile and Clean Code, they're not related in any way. Second, people did not set out to find design patterns - look up the GoF book and you will see exactly how they emerged. Third, Agile was introduced by a particular subset of programmers, and it ONLY applied to that type of programmer (it's probably not you); exercise to the reader: what did the signatories of the Agile manifesto have in common that makes Agile useless to a lot of programmers? I could go on.
@@frechjo "they somehow came upon an obscure architecture book that very few people ever read, and took the idea of design patterns from it". What book did you have in mind? Care to share more about what you mean? Which Alexander?
@@T0m1s A Pattern Language, Christopher Alexander. It was talked about a lot in Ward Cunningham's first original Wiki. And there was probably formed also the link between the pattern people, the xp people and the agile people. Not all the same, but all connected groups.
47:00 For library developers, TDD is amazing in a sense that you not only verifying lib's correctness, you also provide usage examples for your lib users. Rust's documentation testing is amazing, you can write tests right in function's doc and it will be asserted by the test runner.
Wow, I was blown away. Not only by Uncle Bob, who shared his experiences so generously and entertainingly, but also by Prime who handled the interview in a masterful and humble manner. It was jaw dropping to observe how a bridge between generations was being built by their interactions. It was also fun to make a connection between Prime's mantra about code rewriting - when one decides to do better and comes up with the same decisions - and Uncle Bob's retrospective on Agile and Clean Code. What can I say? "If I have seen further than others, it is by standing on the shoulders of giants". Can't wait for the book - a great choice of topic!
Primagen: "I don't get that last part, that sounds very difficult…" Looking back, Uncle Bob's newspaper metaphor had the most profound impact on the readability of my code. Uncle Bob: "Think of a well-written newspaper article. You read it vertically. At the top you expect a headline that tells you what the story is about and allows you to decide whether it is something you want to read. The first paragraph gives you a synopsis of the whole story, hiding all the details while giving you the broad-brush concepts. As you continue downward, the details increase until you have all the dates, names, quotes, claims, and other minutia. We would like a source file to be like a newspaper article. The name should be simple but explanatory. The name, by itself, should be sufficient to tell us whether we are in the right module or not. The topmost parts of the source file should provide the high-level concepts and algorithms. Detail should increase as we move downward, until at the end we find the lowest level functions and details in the source file. A newspaper is composed of many articles; most are very small. Some are a bit larger. Very few contain as much text as a page can hold. This makes the newspaper usable. If the newspaper were just one long story containing a disorganized agglomeration of facts, dates, and names, then we simply would not read it." Source: "Clean Code, Chapter 5: Formatting" If/when it clicks, it's hard to go back. 🤷♂
I agree. I had the same experience. Can't go back. But it asks you to refrain from trying to understand everything. Only delve into the details of what you need to modify. The rest is noise, you just need to have a vague idea of what the noise does (read the name and move on). I think that's the main blocker that prime has.
I expect writing a book is similar, based on what I've seen from some authors that livestream their book writing. Now, reading a book is much different. It is an experience, one meant to immerse and obscure the structure in order to make it least predictable. But, to write a book, I feel that some authors wrangle their own complex structure for writing by managing it in these sections/modules.
Instructions unclear: I now have clickbait function names, nsfw-image art in the comments and after actually having read the function, you will realize it did more or less nothing at all.
Something I like to try is to write functions that show from a high level where some data is used and when it's not used. So I may chuck off part of a class so it's passed as an argument to some functions, which makes it clear that these are the only functions that use it. It's like an overview of how some data flew.
His point about design patterns being used to communicate is really good. I see so many people complain about professionals using jargon to "sound smart", or school just teaching "how to use complex words to describe simple things". But when talking to other professionals, jargon is so useful, because you can express complex ideas in one or two words instead of pulling out a whiteboard.
Yep, that's how the likes of AbstractSingletonObserverFactoryInterface are born. You just think in patterns and communicate with them. As opposed to thinking in problems and communicating in how your code actually solves the problem. Using patterns to communicate happens rarely unless people actually think in patterns, if their thinking is to a large extent replaced by simplistic stereotyping. You don't see Torvalds or Carmack constantly talk in patterns because they solve actual problems they have at hand instead of combining these Lego bricks Or you know, it's kinda like how some people love talking in quotes by famous people, and others just express the actual thing they personally want to say
@@laden6675 no, he did a good job. he led bob to build his own arguments even when he disagrees with them. this comes from a person who is highly critical of prime in many instances.
i don't work in software, just a hobbyist programmer trying to learn and make cool things, and still this interview was captivating and motivating. thanks for bringing uncle bob in!
First time I see someone actually challenging Uncle Bob's views, and he is giving really good answers. But the questions help to look at it from a different perspective
Great questions and answers from Uncle Bob. The issue of doubling the number of programmers every 5 years is an interesting answer. Having Uncle Bob on your channel is Golden! Great video! Love this!
Uncle Bob, The Laughing Programmer, super interesting discussion with the young buck vs the older guru, I thought Prime was very respectful and Uncle Bob was very generous with his knowledge and skills gained by hard experience. Kudos to both gentlemen
I think most people don't even understand the design patters. And i don't mean on a technical level. I mean, i don't think they understand that they are naturally occurring patterns.
It's like difference between saying "I have a Honda" vs "I have a SUV" - some cars are just SUVs and if you use that that term for your car you avoid much confusion and you also introduce a lot less noise to your message.
@@prooseeIt's actually a funny example since Honda is more specific than SUV regarding a subset of car properties, but less specific regarding the diff between SUVs and other cars. It depends on the context which one is more useful and if you can just use both in different contexts, really shows the power of proper design.
@@Asto508 that's what I was aiming for: in programming the most specific thing is the code itself, but if you can communicate the general structure of your code just by saying a name of design pattern then sometimes it is specific enough your colleague doesn't need to dive into code.
people often don't have to understand them because many of them are just language features these days. the GOF didn't build the book to be a perfect crystal to last for eternity. they said "this is what we've got so far. now it's your turn. show me what you got". and the cults built fake airstrips and fake airplanes out of wood because they hoped more planes would come.
Definitely a smell if you are jumping all around to understand what the code is doing. A smell that the functions you wrote are not partitioning the code as well as you could and the names along with the parameters are not descriptive enough to tell you what that function is doing. Super insightful conversation! Loved it Prime Boi :)
this happens all the time with OOP where people add a lot of state to the class, they have these "small functions" but the "small functions" are actually mutating any of the 10 properties in the class (you don't know until you read them, also you have to memorize what each small function is doing to get an understanding of their effect when called sequentially)
@@josevargas686 Yeh, I think this is where programming languages themselves fall short. The function signature becomes obsolete when you start changing state within the class containing that function. As a personal preference, I try to minimize mutability, employ the single responsibility principle, and have clear names that indicate what state is changing and how it is changing. By doing so, I can minimize the number of tests I run against my own short term memory (which is bad) 🤣
Excellent video. Two men who I highly respect, with very different viewpoints, having a respectful, informed discussion about their differing opinions. Thank you very much for this extremely high quality content.
PLEASE, these talk is GOLD! We need this to happen a lot more! I'm just at the starting of my career and I BEG: PLEASE, MAKE THIS INTO A FIXED SHOW! Doesn't matter the frequency, once a moth, once every few months, once every few days, once a year, make this into an event, but keep it up! That will really help people, I've come from selling all sorts of things on the streets here in Brazil, to where I am now, at home, making step by step, changes in the life of my daughter and my mom and that just brought to me a lot of value that complimented all the books and the ridiculous amount of hours learning behind that.
I was thinking basically what uncle bob said while watching your previous video on small functions. Ideally, you don’t need to drill down. The point of abstraction is to trust the abstraction does what it says it does and you can easily read what something does without knowing exactly how it does it. This is true at any level. If I use Python’s built-in open function, I don’t need to know exactly how it’s doing it, I just go, “ok, it’s opening a file.”
@@xthebumpx yes, you will need to drill down at this point, but usually only a small part is broken, so you don’t have the huge tree explosion Primeagen is talking about. If you have half decent debugging, you should be able to pinpoint the source pretty quickly. The issue here is was talking about was more trying to understand a new piece of code. I think the breaking it down can make that easier, of course, only if it’s done well.
Exactly. You put a comment on every third line, then turn the comments into function splits. And add a function that's the table of contents, calling them.
Thanks, I really enjoyed this live, was great to listen and understand better the position of the Uncle Bob. I might not agree with a lot of conclusions but I respect his point of view.
Productivity in programming field is magical under a certain corporate governance. A little sketch by lone engineer and a magnificent drawing by 10 engineers can do the same thing. I could see Martin was working in the environment the latter thrives. His endeavor must be lonely and tough. I still thank him that he definitely taught me how thin and elegant programming can be at the same time without experiencing disasters.
Trying to auto-generate code from just UML is a failure. Though, knowing how to draw a UML diagram, how to read one, and how to think about different aspects of a software system with UML diagrams - seem like good skills. Are you using those skills 100% of the time - no. Though, if your reaction to any UML diagram is: "I have never seen this before in my life."..
UML wastes your time. You would better use your time by going directly from story point to code, as code is the best diagram. It would be like drawing a pixel perfect mock up in figma, then converting it to Next.js, then oh no you have to change something, then you change it in code but it isn't up to date in UML. So you literally just did double work for no benefit. UML is garbage, just like OOP itself.
I really like TDD, and I also really like practicality. An argument I think it's easier to get behind for TDD in web/backend development is like ... If you don't write tests EARLY (not necessarily first) you are going to be clicking buttons in your web app to test that stuff works. If you write a test, you hit *magic finger incantation* and your IDE runs the test in 4-10 seconds and you can get into a rhythm. I use rspec or pytest instead of the rails console or a custom script that hits the DB to test that I got the answer correct. I watch other devs struggle with this and get confused why I didn't load the UI to see if the thing works.
I really appreciate this interview. I consider uncle bob my first real mentor and I went to college 😅. His clean architecture book and his lectures were giant stepping stones for me. It has become popular to misscharacterize and pick on him, most don't even really know what he is saying. Perhaps its a symptom of being the loudest advocate for change😂
I'm so glad I read and listened to him when I was getting started. I was sitting here listening to his answers thinking 'thats funny I work the same way' until I remembered I spent countless hours listening to recordings of him something like a long fucking time ago
Love this video!!!! This is about creating code that is low prone to error. e.g. Low prone to error > low cost. It's not just about writing code, it's about writing easy to change code. Why low prone to error is important..... more robust code, save cost, allow for change.
"We Really Don't Know How to Compute!" - Gerald Sussman (2011) "Stop Writing Dead Programs" by Jack Rusher (Strange Loop 2022) For anyone interested, these two talks provide good insight into the philosophy of computation of Lisp. Professor Sussman is also the author of "Structure and Interpretation of Computer Programs" which is the book Uncle Bob recommended in this video. "Simple Made Easy" - Rich Hickey (2011) "Are We There Yet?" (w/ slides) - Rich Hickey (2009) "The Language of the System" - Rich Hickey (2012) or these talks by Rich Hickey, creator of Clojure, for a brilliant breakdown of general/fundamental problems in programming & software engineering, which functional programming attempts to solve.
6:45 "affordances", term coined by engineer Don Norman in hid book "The Design of Everyday Things" to deecribe the actions that are possible on an object. For example, you can sit, stand, etc on chairs, thus they afford support.
This interviews are amazing, you're doing an excellent job. I really like the path this channel took, this type of content is super interesting, entertaining and educational. I hope the best for you and your future projects! 🙌
well, when everyone always points at 3 massively authoritarian and capital driven countries as "communism", it does get pretty grating. the joke is funny tho.
I don't know Bob's viewpoint on communism, but I certainly can see it as an insult to compare the work of engineers to what many Americans (especially older Americans) consider a failed ideology. A bit tasteless even in jest.
Coming from an American-based commentator (Prime) this is rather sad TBH, since most people in the USA have been so politically-abused by rhetoric they have little to no clue about the history and variation in this family of ideas.
@@hemmper IIRC the "manifesto" in early programming culture was an explicit reference to/joke about the communist manifesto, in the sense of "hey, don't take this *that* seriously", but of course people did. I can't speak to how serious the agile manifesto was about the usage, though!
I wonder if the "Clean" in "Clean Code" is an adjective any more, or it has morphed to be a noun. I also wonder if we have all done to Clean Code as we did to Agile: completely missed the point, and have been doing a bastardised version of it ever since. Now we complain about it not working - but we were never really doing it properly.
Yes, I commonly hear the mis-categorization of agile to be a "noun," a thing to sell to project managers, rather than simply to be "clean" or "agile." It depends on how people interpret and sell it. Look at writing of the original authors and you will see it has soft points, few or no hard limits. It is meant to be vague. You could say it all equates to having "good manners", but that's not as catchy and sounds more parental. "Professional" sounds too corporate. It's hard to express things in English in a singular way to everybody.
I watched him speak a decade ago, and his messaging was the same. Just like with Agile, so many people take his ideas and make them so dogmatic that they lose their original meaning.
@@SGIMartin Then why did you never listen to any of his many presentations before?! I don't get it. If somebody like Prime tries to sell you an opinion about XY, then I fell like I should look into what XY really says.
This was a fantastic interview. thank you so much! It opened my eyes to a lot and I learned so much that I will take into my day to day with programming
I'll give him this, as far as rhetorics go Uncle Bob was the heavy weight in this discussion. He's really good at explaining concepts and can always go more into detail when prompted. Prime's criticism usually clicks with me but it was less convincing now that Uncle Bob had a chance to explain himself.
@@eduantech It's not like Prime's point diverges too heavily away from Uncle Bob's. I would say he only lacks the compatible experience of writing TDD code or test cases in a way that he might find it hard to empathize or imagine certain "feelings" or judging things based on "smell/feel" as Bob describes. But the principles are quite close, especially with the thoughts on Agile. Though Prime has had a viewpoint against TDD and can't empathize with it much, I don't think it weighed down the discussion. Bob was well-spoken even when Prime was confused and did a good job of translating to topics/scenarios Prime could grasp and even agree with. I would argue that both Prime and Bob would arrive at a similar end point (if he isn't convinced already), just as Bob and his peers did in 2001. It is rooted in wisdom more than experience in a corporate/business world. I primarily think the direction that Prime's life has mostly influenced his little exposure and insight into TDD. If you give him years of the same kind of exposure I feel that the world would steer him towards TDD anyway. For the purposes of being a streamer full time I will contrastingly say that TDD is probably the LEAST entertaining topic, except for those who are truly passionate about writing test cases and working in such a way outside of a professional context. It doesn't make money, TDD has never been the thing that makes money on its own.
That's because Prime is a great interviewer. A great interviewer is there to bring the information from the interviewee, not to create debate, as Prime mentioned at the start. He is a communicator and he knows how to do it well.
Prime's arguments are typically based on all-or-nothing fundamental reasoning. If that kind of reasoning is strictly applied, we wouldn't have integration (math-calculus integration), since _technically_ limits aren't actually ever reached... Uncle-Bob's methodologies are asymptotic in nature; they aren't based on hard-guarantees for _every_ situation, they are based on average dift effects, especially for larger projects with a decently-long lifetime.
I think the underlying truth that this great conversation brings out is that for the most part, we have a huge population of programmers who simply aren't up to the task of doing their job well. It's true that we go to war with the army (of programmers) that we have and not the army we wish we had. The current state of things seems to suggest that maybe there should be fewer wars until the programming troops get up to snuff.
I really do think we don't need that many image viewers, messaging apps, complexity in the browsers if virtual machines took off, we could really make do with less software.
99% of code on GitHub is, as Bob calls it, rude. Programmers don't like being called out for indiscipline. I used to think clean and TDD were stupid at one time, then I grew up.
@@drcl7429 This is not true, per elementary mathematics. A function that takes a string, for example, has a countably infinite domain. In reality you can rarely, extremely rarely, "just test the domain and range".
My first programming class in uni used scheme and SICP which I liked. The class only go through the first half part of the book, now I want to read the remining part after a decade.
7 หลายเดือนก่อน +2
I just randomly searched for Uncle Bob and this randomly shown in the tesults. Thank you!
Would be good to see these guys pair program. Alot of the takes really comes down to 'it depends' and it would be interesting to see their thinking in a more concrete scenario
Top tier content Prime! A lot more insightful than some of the article reads or video reactions that seem to milk the youtube watch time a little bit ;) Perhaps an increase in quality since you left Netflix? Hype!
I atcually introduced the REAL agile into my company. It was a very difficult process, but we ended the scrum poison and all teams have freedom to determine their own work process. It takes trust and transparency from all sides, but it can be done.
This chemistry is so precious. Isn't it very rare to find a programming related video that feels like this? I just want to imagine what it would be like if Bob programmed with Prime for 20 minutes. Jump into one of Prime's projects and pair program.
I would definitely like to see Prime pair up with Bob. It would set aside many differences and focus on the real meat of what it means to discuss software development
Really appreciate Primeagen opening the conversation towards learning. As Uncle Bob said, there has been over the years a lot of divergence with respect to Agile and so many other things, i.e. TDD, at a point where all those values, principles and practices were somewhat distorted, and kept people from being successful. I think we should see more of these exchanges and more often. Once thing I wanted to personally add to the TDD topic, when I don't know how to start designing a solution or the solution is very complex then TDD actually helps me a lot, because I can basically focus on one small goal/behaviour at a time, while my production code evolves over time in complexity without me specifically tackling all of that at once; Incremental and emergent design is something that can be very useful, and since you will end up with a bunch of test you can trust you will be able to re-design the whole implementation if you want, like Uncle Bob said. On the other hand, if you don't know enough about the problem, then it doesn't matter if you use TDD or not, because it's not the right time to start building a solution, instead spend time uncovering the unknowns and seek an understanding of the problem.
Couldn't agree more. I believe in pseudo TDD. It is my approach to rapidly developing closed utility functions. Yet best lightly applied when free-form carving things out, where it might instigate diminishing returns when it forces you to refactor the tests as you go or worse influences the subject code itself. I think the sentiment he expresses holds true: use the principles to help drive pragmatism.
Great interview mate! I've followed many of Uncle Bob's philosophies for years and they have been an instrumental help me land jobs (not from buzz words) and solving software problems. He's very invested in passionately teaching great programming principles. Love the light-hearted discourse, where creativity flourishes. So true but unsurprising how the core principles of the Agile manifesto have been lost in many cases. However understandably, because project management = asking for money to do a thing. There are no blank cheques in corporate. The real challenge is interfacing funding and engineering harmoniously. PS the many Star Trek and Minecraft references in Bob's Clean Code vid series are hilarious!
I honestly think this is one of Prime's best videos. I like hearing an honest discussion (not a "debate" to win crowd praise) between two people who disagree. If anything, this was too short.
I've been in projects where the test suite is so good, that I can easily update my vendor dependencies or do huge refactors without ever breaking everything. But getting there and staying there is really hard. :)
I once had a Twitter chat with Uncle Bob about Harlan Mills and TDD. The ideas that Mills used and taught are similar to the ones Kent Beck based TDD upon. The set of ordered pairs have become specific Unit tests and generalized code.
I'd like to see an editor where you're not seeing files, but nodes. Each node is a function and has nodes which traverse to calling/tobecalled nodes. Cluster groups of nodes by name (namespace/file). Working in graphs instead of plaintext. BUT: We kind of do this right now - just now visually. Maybe it would be easier for beginners to grasp the concepts (and see complexity) as soon as we see the corresponding graph. Even sideeffects and inpurisms would be more visible
Wow, I had the exact some thoughts a week or two ago. I work in a really large codebase, and its horrible too, so I found it really helpful to just screenshot functions and create visual diagrams like that when I need to understand some overly-complicated data flow.
Uncle Bob: "I'm gonna teach the world how to do proper Java"
Also Uncle Bob: "I'm gonna switch to LISP"
Top 10 anime betrayals
LISP and FORTRAN are based
Uncle Bob is right, the first step on how to do proper Java is to ditch it and do Clojure.
If you want to write good software (not scripts and macros), then it is easiest to use a language that detects errors when the code is written, not when it is running.
Nothing beats Rust from that perspective.
@@CalifornianViking I am so so, so god damn tired of hearing the same BS from people who haven't even written a medium sized Rust project. Stop. Rust is no magic bullet. It DOES NOT PREVENT BUGS AT COMPILE-TIME. It might make it slightly harder compared to certain languages, but that's it.
And the hell r you smoking to even say nothing beats Rust WHEN there are languages like Idris with totality checking and proof checkers.
Before Java, he was a huge C++ advocate, and OOPs guy. People evolve. This is a good thing.
A programmer of 50 years with a full head of hair? Sorcery!
I’m surprised that the neck beard hasn’t taken over, it is the usual pattern of older programmers.
Yo, doesnt debug. TDD
the power of unit tests
His grooming routine is as clean as his code.
@@myhstic no, he's busy creating pattern for us
"Took a lot of therapy to get to Clojure"
It was so low-key he wasn't even expecting a laugh.
I was following UB when he jumped to clojure. I still don't get it.
And his therapist was SICP. Good choice.
@@ShadwTrooper jump or clojure? :P
I snickered on that
The most unexpected interview of the year.
Uncle Prime and the Bogagen, the crossover we really needed.
Yeah, especially after Prime admitted going from full on Clean Coder disciple to "this is bs, be pragmatic".
One the best interviews because it is from someone who does not like clean code and tdd, so we have a lot of good questions!! Thanks Prime, now we are waiting by Martin Fowler
Yesss, we need Martin F!
Absolutely not, too soon. I need at least a year to recover.
But I think Prime likes Fowler, he even applies Folwer's rule of three
Martin Fowler would NOT fuck around.
@@DudeWatIsThis then he would never find out
Damn, Uncle Bob really does act like an uncle lmao. Dude pops out a chuckle a minute, love it!
Including the random xeonophobia and racism like any old uncle, but luckily kept this out of this interview!
I love that a guy with as much clout as Uncle Bob can laugh about himself and joke around about his own philosophies. Great chat!
To me the laughing sounded kind of forced I think he knows that he's in a space which looks very critical about his books.
@@blubblurb He's just jolly! With so much experience he is just a little bit jaded and knows life isn't about being right. Gotta laugh too
@@blubblurb I've seen him give talks. That's just how he is.
@@memoryman51 Ok, good to know.
Bob is very reasonable and I respect his efforts trying to "model" good practices into what he calls "clean code". I don't necessarily agree with all of it, but nevertheless, I think there is value in organizing these ideas into a book back in the day. One should remember that "Clean Code" and "Design Patterns" were written many years ago with many points that don't exactly translate to languages/practices we have now-a-days.
I feel that people who "hate" his ideas are too dogmatic in the sense that you either agree with something 100% or you have to disagree 100% and hate it. Most things in life are not as black and white.
Even Agile, if you are old enough to have experience with a "waterfall-like" process, you know how the agile manifesto had a positive impact. Of course, like most things, people try to make it into a business (scrum) and the whole thing gets distorted. I think Scrum sucks, (and I prefer to stick to the manifesto principles) but it's much better than the old waterfall approach.
What a SOLID interview, such a clean coder
And inefficient coder. Over abstraction is also a sin.
Idk it seemed kinda DRY
So you're saying you wanna KISS them
oof.. this comment section smells
There seems to be a pattern in the comments.
Primagen: I hate clean code
Also, Primagen:
I was thinking that 😂
This!
Totally this
He has no enemies
My gut feel it that whatever version of CC that Prime hates would probably be equally as hated by the progenitor of the concept. Case in point to the fact that the moment words leave your mouth you lose any and all control of them...
I've read/watched Uncle Bob for well over 10 years I think, his ideas about Clean Code, TDD etc, are more about being 'professional' than a set of rigid rules you must use to do proper programming. He genuinely wants the programming workforce to be Professional and his ideas are like SOP's that any real profession would have and use.
Great talk! Looking forward to the next Uncle Bob installment :)
his "The Clean Coder" book was more about being professional.
that's different from his "Clean Code" book, which is more about the code itself, as opposed to the act of coding
Well said. I like that Uncle Bob gives a type of direction to aim in. Other people boo him, but they often don't offer a better thing to aim at. Some say he's too rigid, but if you really listen, he's not rigid about things, he just has goals and standards. He admits no one meets them 100% including himself, and he's ok with that. The value you gain is in aiming and trying. To be more polite, to be less rude with our code. To respect each other, to publish good code often, to adapt well to changing requirments. He makes me proud to be a programmer.
@@CTBell-uy7riI feel like he reminds people of triggering parents
Dude, he literally illustrated his ideas with code in the book. It's not ambiguous what he deemed desirable code to be. It's a program that consists in large part of layers of made up abstractions you have to delve through to try to see the actual code that does something. A code so abstract it may not do anything and you can still delve into it.
This interview shows that he's still on that exact same path. Dude just loves abstractions and constructs
No, he has a lot of engineering practices suggestions and that's the main part of his work. Being professional is also a part of his framework, but it's not the main part. Between those 2, the more important part is engineering practices that he professes: Clean Code and Clean Architecture.
I can't wait for the DHH episode.
I would pay to see that
This!!
A TYPE CHECKER JUST FLEW OVER MY HOUSE
😂😂@@sporefergieboy10
My favourite contrarian.
This is actually my favorite video so far on this channel. It was informative and easy to listen to.
Maybe because he didn't ask if he still thinks that women are supposedly less qualified to be software engineers than men
@@Wyvernnnn do you seriously think that everyone would take one difference of opinions that radically?
Defineatly no.
@@symix. That's not just any opinion. So yes; I would hope the large majority of software engineers would have that kind of critical thinking & backbone.
@@Wyvernnnn when did Uncle Bob say that either is better? Why would you even bring this kind of shit into the conversation? Are you crazy?
Also there is difference between men and women. One of the two on average is better. And it's true at any thing we can take and compare the two.
@@KulaGGin He said that in his "Thought Police" blog post published in 2017 in the context of the Google engineer who got fired for saying that men make better software engineers than women
If you think he's correct we have nothing to say to each other
We need a 2nd part, this one was amazing, the two of you guys made huges changes in my life, YOU BOTH, it was amazing to see you talking each other. OMG. What a nice video! I really like it
I like this format.. I like how you actually having a conversation not just one person talking about their ideas, but you challenge the ideas with your own. This was so interesting to watch, I did not realize that I was watching one hour long video.
Listened to this live on the way to work, was so invested, i just sat in the car once i got there until it ended. Top tier content better than any conference or seminar.
you have adhd sir
A great interview. Seems Uncle Bob is more fun and not as dogmatic as he is represented to be in some quarters...
could be a motte and bailey but I haven't read his books
Bro, the problem is, people like primeagen claim authority in a field, they still have to learn in. Sometimes its shocking to me, how easily some followers of primeagean are swearing on basic principles and the foundation of successful everyday projects.
@PrizrenaliZH Has anyone reached a point they don't have to learn anything in software development? I highly doubt it.
Honestly, this was a great interview because it highlights the one thing that many people in this industry no longer do, have conversations about different ideas. Based on the views expressed by Bob Martin, it becomes very apparent that the books and processes he has expressed are discoveries that his has made about his time in software development. They are purely ways that he has found to do what he does in a way that makes him feel like he has done a good job. They are not industry standards. They are insight into how one might approach solving a problem. They (his views and opinions) should be the starting point for meaningful conversations that make us think about things from a different perspective. I have noticed a decline in abstract thinking in the software industry and everything has become concrete. I miss the abstract thinking because some of the most beautiful solutions (and simplest) have come from discussions that started as abstract ideas. I cannot express how much I enjoyed this conversation and the way it was conducted in a manner that seemed to be about learning as opposed to dictating what is right and what is wrong. Thank you @ThePrimeTime. Something we also need to remember is that people that challenge our thinking are not to be dismissed. Have the hard conversations in a constructive fashion and everyone wins.
Most of all, he did not create many of these ideas. He just groups them together and re-explains what he learned from others. To talk to one another is to discover how little you know. It's a thoughtful direction for Prime to go into to bring such a guest on and dedicate an entire hour to. I truly think that his separation from the business world, like Netflix, has given him a clearer viewpoint on many matters as of late.
It is was my point of view comment before😊
Maybe it is because lot of people starting programming as the first subject. I starting coding to automate electronic process.
So, programming to my understand doesnt has standard and focus on my business model and try apply the best pratices.
I'm really glad this interview happened. I think a lot of people that don't like uncle Bob miss a lot of nuance he talks about, brought in from decades of experience. Its also cool to go back and see his old stuff and see the evolution of his process. The 'functions do one thing' for example, he used to teach a completely different lesson.
People don't like Bob because most of his "nuance" is him squirming when people have objections to his dogma which somehow isn't dogma but at the same time kinda is, unless he's in a "conversation".
@@y00t00b3r Omg mald harder
@@y00t00b3r I did not see that at all in the interview. Prime clearly had disagreements and things he agreed with, but asked him some clear explicit questions and received clear responses. I found the discussion about testing to be insightful and will be using Bob's philosophy going forward.
@@y00t00b3r Yes this must be it. I only realized it when I started reading his blog by the way
@@y00t00b3r what I got from this interview is, this isn't dogma. It's his personal preference. Clean Code is his daydreaming in the sense of him thinking about things that satisfy him which is why he comes off as dogmatic and simplistic. There is no real discussion or nuance in describing your favorite taste, you just say it to be that way.
But when faced with reality he changes, as everyone does when they snap out of those daydreams. Doesn't mean those daydreams are somehow changed by reality, or that he's lying. It''s just reality is one thing, and our fantasies about simple joyful scenarios where we slay dragons in just the right way with our favorite power move and everyone claps is a different thing
Imagine seeing the title without knowing who he is
It's his uncle, right?
🤣
Honestly good. They will learn quick why he is so influential or at least recognizable in the field.
Imagine being a software engineer and not knowing who he is.
Can't a guy interview his diddling uncle in peace?
0:00 - 0:59: Introductions
1:00 - 7:44: Why choose Clojure?
7:45 - 9:24: How do you reconcile Clean Code with a language like Clojure or Lisp?
9:25 - 11:12: How does Clean Code intersect with Go and Rust?
11:13 - 11:53: Goal of the interview
11:54 - 14:10: In the last 15 years, what has caused the shift away from design patterns?
14:11 - 16:05: Do you think modern software would benefit from a return to design patterns?
16:06 - 22:21: Reaching for abstractions before the problem is solved
22:22 - 25:11: Are you big on UML?
25:12 - 26:24: How do you feel about the current Agile movement?
26:25 - 27:57: What made Agile fall apart?
27:58 - 33:40: What is the correct way to Agile?
33:41 - 41:41: How did you arrive that a function should be less than 6 lines?
41:42 - 42:19: Accidental vs Essential Complexity
42:20 - 46:00: TDD
46:01 - 50:03: Why not start with the basic implementation?
50:04 - 52:00: Why test every line?
52:01 - 56:42: Module barriers
56:43 - 58:42: Is all code worth testing?
58:43 - 1:00:55: Errors as values vs Exceptions
1:00:56 - 1:06:20: What type of tests do you write?
1:06:21 - 1:11:07: Wrapping up
Thanks.
26:37
"I have to help my wife move in 26 minutes"
"This won't take that long"
😅
Wow, does this right in the middle of a divorce.
Takes a great man to invite a person who clearly has opposite views on some of the most important issues for both of them. Takes another great man to accept that invitation. And loved the open discussion. Is true that some of the more detailed topics were avoided but still... gg guys.
"how do you convince a company of that"
You can't.
You can: get rid of the higher management. Bob is just too polite to say it publicly.
This is the type of interview I have been waiting for many years.
First of all, thank you, Robert Martin, for your contribution to the IT industry, bringing new concepts around the development of software.
However, I would like to say that, in my understanding, most people in the IT industry seem like they never ask themselves questions about why Clean Code, Clean Architecture, Scrum, Agile, Design Patterns, TDD, and other concepts.
Nowadays, people just assume that these concepts are some type of standard. This interview was good because, in my understanding, Uncle Bob defined these concepts based on his own experience as a software developer and not as the result of scientific research.
This should be obvious at first for any intelligent reader that got one of his books....
my understanding of the history of clean code, design patterns, agile, etc. is this:
1. a bunch of dudes wrote a lot of code
2. they had problems
3. they did their best to understand the problems
4. they did their best to come up with solutions and find patterns
5. they did their best to document it all
it's not magic that's gonna make our lives easy. programming is still hard but now we at least have some tools to approach problems and communicate with other developers. that's it!
I like how they somehow came upon an obscure architecture book that very few people ever read, and took the idea of design patterns from it. I don't think Alexander had any significant impact on architecture or aesthetics, while you see how much he (indirectly) had in programming.
6. A bunch of kids learn JavaScript on youtube.
7. They are introduced to all these patterns but aren't told why they matter
8. They ignore all this prior knowledge as pointless dogma that limits their productivity
9. They make all the same mistakes that people in the 60s made.
10. Go back to no. 1 ....
Your understanding is unfortunately not correct, and reflective of the shockingly bad state of the industry culture. First of all, "design patterns" came out a decade before Agile and Clean Code, they're not related in any way. Second, people did not set out to find design patterns - look up the GoF book and you will see exactly how they emerged. Third, Agile was introduced by a particular subset of programmers, and it ONLY applied to that type of programmer (it's probably not you); exercise to the reader: what did the signatories of the Agile manifesto have in common that makes Agile useless to a lot of programmers?
I could go on.
@@frechjo "they somehow came upon an obscure architecture book that very few people ever read, and took the idea of design patterns from it". What book did you have in mind? Care to share more about what you mean? Which Alexander?
@@T0m1s A Pattern Language, Christopher Alexander. It was talked about a lot in Ward Cunningham's first original Wiki.
And there was probably formed also the link between the pattern people, the xp people and the agile people. Not all the same, but all connected groups.
uncle Bob has a great personality
GREAT INTERVIEW
Please do more of these! It is so interesting seeing you two with differing opinions unveil details for each argument that are commonly missed.
47:00 For library developers, TDD is amazing in a sense that you not only verifying lib's correctness, you also provide usage examples for your lib users. Rust's documentation testing is amazing, you can write tests right in function's doc and it will be asserted by the test runner.
Wow, I was blown away. Not only by Uncle Bob, who shared his experiences so generously and entertainingly, but also by Prime who handled the interview in a masterful and humble manner. It was jaw dropping to observe how a bridge between generations was being built by their interactions.
It was also fun to make a connection between Prime's mantra about code rewriting - when one decides to do better and comes up with the same decisions - and Uncle Bob's retrospective on Agile and Clean Code.
What can I say? "If I have seen further than others, it is by standing on the shoulders of giants".
Can't wait for the book - a great choice of topic!
Primagen: "I don't get that last part, that sounds very difficult…"
Looking back, Uncle Bob's newspaper metaphor had the most profound impact on the readability of my code.
Uncle Bob: "Think of a well-written newspaper article. You read it vertically. At the top you expect a headline that tells you what the story is about and allows you to decide whether it is something you want to read. The first paragraph gives you a synopsis of the whole story, hiding all the details while giving you the broad-brush concepts. As you continue downward, the details increase until you have all the dates, names, quotes, claims, and other minutia.
We would like a source file to be like a newspaper article. The name should be simple but explanatory. The name, by itself, should be sufficient to tell us whether we are in the right module or not. The topmost parts of the source file should provide the high-level concepts and algorithms. Detail should increase as we move downward, until at the end we find the lowest level functions and details in the source file.
A newspaper is composed of many articles; most are very small. Some are a bit larger. Very few contain as much text as a page can hold. This makes the newspaper usable. If the newspaper were just one long story containing a disorganized agglomeration of facts, dates, and names, then we simply would not read it."
Source: "Clean Code, Chapter 5: Formatting"
If/when it clicks, it's hard to go back.
🤷♂
I agree. I had the same experience. Can't go back.
But it asks you to refrain from trying to understand everything. Only delve into the details of what you need to modify. The rest is noise, you just need to have a vague idea of what the noise does (read the name and move on).
I think that's the main blocker that prime has.
I expect writing a book is similar, based on what I've seen from some authors that livestream their book writing. Now, reading a book is much different. It is an experience, one meant to immerse and obscure the structure in order to make it least predictable. But, to write a book, I feel that some authors wrangle their own complex structure for writing by managing it in these sections/modules.
Most of all, you don't have automated testing. But you still can structure and re-read a book/newspaper article.
Instructions unclear:
I now have clickbait function names, nsfw-image art in the comments and after actually having read the function, you will realize it did more or less nothing at all.
Something I like to try is to write functions that show from a high level where some data is used and when it's not used. So I may chuck off part of a class so it's passed as an argument to some functions, which makes it clear that these are the only functions that use it. It's like an overview of how some data flew.
His point about design patterns being used to communicate is really good. I see so many people complain about professionals using jargon to "sound smart", or school just teaching "how to use complex words to describe simple things". But when talking to other professionals, jargon is so useful, because you can express complex ideas in one or two words instead of pulling out a whiteboard.
Yep, that's how the likes of AbstractSingletonObserverFactoryInterface are born. You just think in patterns and communicate with them. As opposed to thinking in problems and communicating in how your code actually solves the problem.
Using patterns to communicate happens rarely unless people actually think in patterns, if their thinking is to a large extent replaced by simplistic stereotyping. You don't see Torvalds or Carmack constantly talk in patterns because they solve actual problems they have at hand instead of combining these Lego bricks
Or you know, it's kinda like how some people love talking in quotes by famous people, and others just express the actual thing they personally want to say
Great interview. Thanks for bringing uncle Bob on. Always pleasant to listen to what he has to say. He's kind of a philosopher of computer science.
Prime showing how to be a host. Many media people might learn something about their job with this interview.
lol that's cap
@@laden6675 no, he did a good job. he led bob to build his own arguments even when he disagrees with them. this comes from a person who is highly critical of prime in many instances.
i don't work in software, just a hobbyist programmer trying to learn and make cool things, and still this interview was captivating and motivating. thanks for bringing uncle bob in!
I may be 5 months late, but keep it up man! And I hope you have a lot of fun.
You gotta go through SICP, Prime. I promise just the first chapter alone will be mind expanding
Are we on a first name basis now? I don't want people to know my first name!
Ok boomer
I read it five years ago. Your comment makes me want to read it again
@@radicalchange9403 it's worth a read. just don't chug a 2L of coolaid after
I'll read it if they make a version in C++
First time I see someone actually challenging Uncle Bob's views, and he is giving really good answers. But the questions help to look at it from a different perspective
Great questions and answers from Uncle Bob. The issue of doubling the number of programmers every 5 years is an interesting answer. Having Uncle Bob on your channel is Golden! Great video! Love this!
Uncle Bob, The Laughing Programmer, super interesting discussion with the young buck vs the older guru, I thought Prime was very respectful and Uncle Bob was very generous with his knowledge and skills gained by hard experience. Kudos to both gentlemen
As a fan of Robert Martin's work I was stoked to see this 😊. Thank you for doing this! 😊🙏
I think most people don't even understand the design patters.
And i don't mean on a technical level.
I mean, i don't think they understand that they are naturally occurring patterns.
It's like difference between saying "I have a Honda" vs "I have a SUV" - some cars are just SUVs and if you use that that term for your car you avoid much confusion and you also introduce a lot less noise to your message.
@@prooseeIt's actually a funny example since Honda is more specific than SUV regarding a subset of car properties, but less specific regarding the diff between SUVs and other cars. It depends on the context which one is more useful and if you can just use both in different contexts, really shows the power of proper design.
@@Asto508 that's what I was aiming for: in programming the most specific thing is the code itself, but if you can communicate the general structure of your code just by saying a name of design pattern then sometimes it is specific enough your colleague doesn't need to dive into code.
Occuring patterns means skill issue, magic is out of our control and it tastes delicious
people often don't have to understand them because many of them are just language features these days.
the GOF didn't build the book to be a perfect crystal to last for eternity. they said "this is what we've got so far. now it's your turn. show me what you got".
and the cults built fake airstrips and fake airplanes out of wood because they hoped more planes would come.
I am SO excited that you interviewed Bob!!! Thank you so much Prime!!!!
That was a great interview. Sat through the entire thing. Thanks to both of you for taking the time to do this.
Definitely a smell if you are jumping all around to understand what the code is doing. A smell that the functions you wrote are not partitioning the code as well as you could and the names along with the parameters are not descriptive enough to tell you what that function is doing. Super insightful conversation! Loved it Prime Boi :)
or a smell that you're trying to understand the "how" where you need to know the "what" and move on
this happens all the time with OOP where people add a lot of state to the class, they have these "small functions" but the "small functions" are actually mutating any of the 10 properties in the class (you don't know until you read them, also you have to memorize what each small function is doing to get an understanding of their effect when called sequentially)
@@josevargas686 Yeh, I think this is where programming languages themselves fall short. The function signature becomes obsolete when you start changing state within the class containing that function. As a personal preference, I try to minimize mutability, employ the single responsibility principle, and have clear names that indicate what state is changing and how it is changing. By doing so, I can minimize the number of tests I run against my own short term memory (which is bad) 🤣
You can use tuples and either types to split up functions more easily btw...
Excellent video. Two men who I highly respect, with very different viewpoints, having a respectful, informed discussion about their differing opinions. Thank you very much for this extremely high quality content.
PLEASE, these talk is GOLD! We need this to happen a lot more! I'm just at the starting of my career and I BEG: PLEASE, MAKE THIS INTO A FIXED SHOW! Doesn't matter the frequency, once a moth, once every few months, once every few days, once a year, make this into an event, but keep it up! That will really help people, I've come from selling all sorts of things on the streets here in Brazil, to where I am now, at home, making step by step, changes in the life of my daughter and my mom and that just brought to me a lot of value that complimented all the books and the ridiculous amount of hours learning behind that.
I was thinking basically what uncle bob said while watching your previous video on small functions. Ideally, you don’t need to drill down. The point of abstraction is to trust the abstraction does what it says it does and you can easily read what something does without knowing exactly how it does it. This is true at any level. If I use Python’s built-in open function, I don’t need to know exactly how it’s doing it, I just go, “ok, it’s opening a file.”
Agreed.
So glad someone said this. Small functions don't lead to the problem people fear they will.
I think the problem comes in when for whatever reason you *can't* trust the abstractions and have to figure out what it's really doing.
@@xthebumpx yes, you will need to drill down at this point, but usually only a small part is broken, so you don’t have the huge tree explosion Primeagen is talking about. If you have half decent debugging, you should be able to pinpoint the source pretty quickly. The issue here is was talking about was more trying to understand a new piece of code. I think the breaking it down can make that easier, of course, only if it’s done well.
Exactly. You put a comment on every third line, then turn the comments into function splits. And add a function that's the table of contents, calling them.
55:36
Prime: And I have proved that I am a shitty future predictor.
Bob: and it is true
I love this interview. Two great software guys who diverge. Great conversation.
Thanks, I really enjoyed this live, was great to listen and understand better the position of the Uncle Bob. I might not agree with a lot of conclusions but I respect his point of view.
Productivity in programming field is magical under a certain corporate governance. A little sketch by lone engineer and a magnificent drawing by 10 engineers can do the same thing. I could see Martin was working in the environment the latter thrives. His endeavor must be lonely and tough. I still thank him that he definitely taught me how thin and elegant programming can be at the same time without experiencing disasters.
Even Uncle Bob says UML was a failure, yet college still teaches it and coerces you to use it.
He didn't say it was a failure. He said he occasionally uses it. My team uses UML occasionally but not for everything
Trying to auto-generate code from just UML is a failure. Though, knowing how to draw a UML diagram, how to read one, and how to think about different aspects of a software system with UML diagrams - seem like good skills. Are you using those skills 100% of the time - no. Though, if your reaction to any UML diagram is: "I have never seen this before in my life."..
UML wastes your time. You would better use your time by going directly from story point to code, as code is the best diagram.
It would be like drawing a pixel perfect mock up in figma, then converting it to Next.js, then oh no you have to change something, then you change it in code but it isn't up to date in UML.
So you literally just did double work for no benefit.
UML is garbage, just like OOP itself.
@@Nellak2011 respectfully, you just might have been presented with a challenging enough problem yet
When I was in school, they still taught us the Structured Program Theorem, though OO was starting to take hold and Lisp was still hovering around.
Thanks for setting this interview up. Been hoping for this to happen
I really like TDD, and I also really like practicality. An argument I think it's easier to get behind for TDD in web/backend development is like ... If you don't write tests EARLY (not necessarily first) you are going to be clicking buttons in your web app to test that stuff works.
If you write a test, you hit *magic finger incantation* and your IDE runs the test in 4-10 seconds and you can get into a rhythm.
I use rspec or pytest instead of the rails console or a custom script that hits the DB to test that I got the answer correct. I watch other devs struggle with this and get confused why I didn't load the UI to see if the thing works.
Appreciate how thought provoking this video is. Video of the year to me!
I really appreciate this interview. I consider uncle bob my first real mentor and I went to college 😅. His clean architecture book and his lectures were giant stepping stones for me. It has become popular to misscharacterize and pick on him, most don't even really know what he is saying. Perhaps its a symptom of being the loudest advocate for change😂
I feel like most people haven’t even read his books but will openly disagree with him lol
@@aaronvancuren7946 it's very clear once they start their arguments 😂.
Awesome interview!!! We need more interviews like this from industry specialist like Uncle Bob. Many Thanks for this
I'm so glad I read and listened to him when I was getting started. I was sitting here listening to his answers thinking 'thats funny I work the same way' until I remembered I spent countless hours listening to recordings of him something like a long fucking time ago
Love this video!!!! This is about creating code that is low prone to error. e.g. Low prone to error > low cost. It's not just about writing code, it's about writing easy to change code. Why low prone to error is important..... more robust code, save cost, allow for change.
"We Really Don't Know How to Compute!" - Gerald Sussman (2011)
"Stop Writing Dead Programs" by Jack Rusher (Strange Loop 2022)
For anyone interested, these two talks provide good insight into the philosophy of computation of Lisp.
Professor Sussman is also the author of "Structure and Interpretation of Computer Programs" which is the book Uncle Bob recommended in this video.
"Simple Made Easy" - Rich Hickey (2011)
"Are We There Yet?" (w/ slides) - Rich Hickey (2009)
"The Language of the System" - Rich Hickey (2012)
or these talks by Rich Hickey, creator of Clojure, for a brilliant breakdown of general/fundamental problems in programming & software engineering, which functional programming attempts to solve.
6:45 "affordances", term coined by engineer Don Norman in hid book "The Design of Everyday Things" to deecribe the actions that are possible on an object. For example, you can sit, stand, etc on chairs, thus they afford support.
"I understand your skill issue." -- Uncle Bob
This interviews are amazing, you're doing an excellent job. I really like the path this channel took, this type of content is super interesting, entertaining and educational. I hope the best for you and your future projects! 🙌
This is going to be a thoughtful discussion, I’ll enjoy it and that’s great. But the twitch brain desire is for just an hour of Prime memeing on him.
And it was an hour of uncle bob memeing on prime
What a legend, I learnt so much through Uncle Bob's messages and benefited a lot from it.
1:40 proof that buying technical books and not reading them for 10 years is not just a me problem. 😂
27:48 "... agile's a lot like communism you know people just keep not trying correctly" this joke never gets old 🤣🤣🤣
well, when everyone always points at 3 massively authoritarian and capital driven countries as "communism", it does get pretty grating.
the joke is funny tho.
I don't know Bob's viewpoint on communism, but I certainly can see it as an insult to compare the work of engineers to what many Americans (especially older Americans) consider a failed ideology. A bit tasteless even in jest.
Coming from an American-based commentator (Prime) this is rather sad TBH, since most people in the USA have been so politically-abused by rhetoric they have little to no clue about the history and variation in this family of ideas.
Always be suspicious of things with the word manifesto attached to it.
@@hemmper IIRC the "manifesto" in early programming culture was an explicit reference to/joke about the communist manifesto, in the sense of "hey, don't take this *that* seriously", but of course people did. I can't speak to how serious the agile manifesto was about the usage, though!
I wonder if the "Clean" in "Clean Code" is an adjective any more, or it has morphed to be a noun. I also wonder if we have all done to Clean Code as we did to Agile: completely missed the point, and have been doing a bastardised version of it ever since. Now we complain about it not working - but we were never really doing it properly.
Yes, I commonly hear the mis-categorization of agile to be a "noun," a thing to sell to project managers, rather than simply to be "clean" or "agile." It depends on how people interpret and sell it. Look at writing of the original authors and you will see it has soft points, few or no hard limits. It is meant to be vague.
You could say it all equates to having "good manners", but that's not as catchy and sounds more parental. "Professional" sounds too corporate. It's hard to express things in English in a singular way to everybody.
SICP is a certified hood classic.
Hood? You mean ivory tower. lol.
@@dabest9843 Maybe OP means "hood classic" in terms of being one of the classic CS books, an OG
@@HolidayInGuantanamotrust me there is no 'SICP' in the hood!😅
I'm distressed by how reasonable these opinions have been.
I watched him speak a decade ago, and his messaging was the same. Just like with Agile, so many people take his ideas and make them so dogmatic that they lose their original meaning.
Yeah, you finally heard FROM him instead of ABOUT him.
He seems so goddamn composed and thoughtful - and i understand and actually, for the first time, agree with many of his points.
Sounds like he's got it all figured out, a true legend that we can all learn from
@@SGIMartin Then why did you never listen to any of his many presentations before?! I don't get it. If somebody like Prime tries to sell you an opinion about XY, then I fell like I should look into what XY really says.
This was a fantastic interview. thank you so much! It opened my eyes to a lot and I learned so much that I will take into my day to day with programming
I'll give him this, as far as rhetorics go Uncle Bob was the heavy weight in this discussion.
He's really good at explaining concepts and can always go more into detail when prompted.
Prime's criticism usually clicks with me but it was less convincing now that Uncle Bob had a chance to explain himself.
Prime is not exactly really pushing his point heavily though, he's letting the guest give his ideas.
@@eduantech It's not like Prime's point diverges too heavily away from Uncle Bob's. I would say he only lacks the compatible experience of writing TDD code or test cases in a way that he might find it hard to empathize or imagine certain "feelings" or judging things based on "smell/feel" as Bob describes. But the principles are quite close, especially with the thoughts on Agile.
Though Prime has had a viewpoint against TDD and can't empathize with it much, I don't think it weighed down the discussion. Bob was well-spoken even when Prime was confused and did a good job of translating to topics/scenarios Prime could grasp and even agree with.
I would argue that both Prime and Bob would arrive at a similar end point (if he isn't convinced already), just as Bob and his peers did in 2001. It is rooted in wisdom more than experience in a corporate/business world.
I primarily think the direction that Prime's life has mostly influenced his little exposure and insight into TDD. If you give him years of the same kind of exposure I feel that the world would steer him towards TDD anyway. For the purposes of being a streamer full time I will contrastingly say that TDD is probably the LEAST entertaining topic, except for those who are truly passionate about writing test cases and working in such a way outside of a professional context. It doesn't make money, TDD has never been the thing that makes money on its own.
That's because Prime is a great interviewer. A great interviewer is there to bring the information from the interviewee, not to create debate, as Prime mentioned at the start. He is a communicator and he knows how to do it well.
Prime's arguments are typically based on all-or-nothing fundamental reasoning. If that kind of reasoning is strictly applied, we wouldn't have integration (math-calculus integration), since _technically_ limits aren't actually ever reached...
Uncle-Bob's methodologies are asymptotic in nature; they aren't based on hard-guarantees for _every_ situation, they are based on average dift effects, especially for larger projects with a decently-long lifetime.
@@warrenarthur5629 I agree that Prime's reasoning is often all-or-nothing. that's why I disagree very much with his take on test coverage.
I think the underlying truth that this great conversation brings out is that for the most part, we have a huge population of programmers who simply aren't up to the task of doing their job well. It's true that we go to war with the army (of programmers) that we have and not the army we wish we had. The current state of things seems to suggest that maybe there should be fewer wars until the programming troops get up to snuff.
I have a feeling that, when all programmers are finally up to snuff, there will be no wars anymore.
I really do think we don't need that many image viewers, messaging apps, complexity in the browsers if virtual machines took off, we could really make do with less software.
99% of code on GitHub is, as Bob calls it, rude. Programmers don't like being called out for indiscipline. I used to think clean and TDD were stupid at one time, then I grew up.
TDD is just testing function domain and range. What is so difficult?
@@drcl7429 This is not true, per elementary mathematics. A function that takes a string, for example, has a countably infinite domain. In reality you can rarely, extremely rarely, "just test the domain and range".
My first programming class in uni used scheme and SICP which I liked.
The class only go through the first half part of the book, now I want to read the remining part after a decade.
I just randomly searched for Uncle Bob and this randomly shown in the tesults. Thank you!
"I am your father, Prime." Uncle Bob
more like his uncle
@@IARRCSim I love the language precision of our tribe. Pro-grammarians, indeed. 🙌
Two perspective about software engineering which makes this interview incredible.
I could understand Uncle Bob thinking much better and that's great 👍
Would be good to see these guys pair program. Alot of the takes really comes down to 'it depends' and it would be interesting to see their thinking in a more concrete scenario
I would love to see that; and I think it could be really eye opening for Prime if Bob shows him TDD in a Pair-Programming setting.
Top tier content Prime! A lot more insightful than some of the article reads or video reactions that seem to milk the youtube watch time a little bit ;)
Perhaps an increase in quality since you left Netflix? Hype!
I atcually introduced the REAL agile into my company. It was a very difficult process, but we ended the scrum poison and all teams have freedom to determine their own work process. It takes trust and transparency from all sides, but it can be done.
This chemistry is so precious. Isn't it very rare to find a programming related video that feels like this?
I just want to imagine what it would be like if Bob programmed with Prime for 20 minutes. Jump into one of Prime's projects and pair program.
I think they will manage very well. their differences are sallow in my opinion.
I would definitely like to see Prime pair up with Bob. It would set aside many differences and focus on the real meat of what it means to discuss software development
Clojure is for the Brave and True
Really appreciate Primeagen opening the conversation towards learning. As Uncle Bob said, there has been over the years a lot of divergence with respect to Agile and so many other things, i.e. TDD, at a point where all those values, principles and practices were somewhat distorted, and kept people from being successful. I think we should see more of these exchanges and more often. Once thing I wanted to personally add to the TDD topic, when I don't know how to start designing a solution or the solution is very complex then TDD actually helps me a lot, because I can basically focus on one small goal/behaviour at a time, while my production code evolves over time in complexity without me specifically tackling all of that at once; Incremental and emergent design is something that can be very useful, and since you will end up with a bunch of test you can trust you will be able to re-design the whole implementation if you want, like Uncle Bob said. On the other hand, if you don't know enough about the problem, then it doesn't matter if you use TDD or not, because it's not the right time to start building a solution, instead spend time uncovering the unknowns and seek an understanding of the problem.
Couldn't agree more. I believe in pseudo TDD. It is my approach to rapidly developing closed utility functions. Yet best lightly applied when free-form carving things out, where it might instigate diminishing returns when it forces you to refactor the tests as you go or worse influences the subject code itself. I think the sentiment he expresses holds true: use the principles to help drive pragmatism.
"The interoperability between the Java stack and Closure is almost perfect."
wow, harsh words.
Great interview mate! I've followed many of Uncle Bob's philosophies for years and they have been an instrumental help me land jobs (not from buzz words) and solving software problems. He's very invested in passionately teaching great programming principles. Love the light-hearted discourse, where creativity flourishes. So true but unsurprising how the core principles of the Agile manifesto have been lost in many cases. However understandably, because project management = asking for money to do a thing. There are no blank cheques in corporate. The real challenge is interfacing funding and engineering harmoniously. PS the many Star Trek and Minecraft references in Bob's Clean Code vid series are hilarious!
This didn't help me Rage Against Bob as much as I expected.
That feel when you like a person whose work you hate
Just because he's "wrong," doesn't mean he's a bad person...
There are a LOT of things that he's right about, not necessarily clean code though...
Because he's right with most of it
I honestly think this is one of Prime's best videos. I like hearing an honest discussion (not a "debate" to win crowd praise) between two people who disagree. If anything, this was too short.
I've been in projects where the test suite is so good, that I can easily update my vendor dependencies or do huge refactors without ever breaking everything. But getting there and staying there is really hard. :)
This is great, I love uncle Bob. Thank you Prime!
Welcome to costco
I love you
❤️❤️❤️
HAHA! I love this comment!
costco?!
5 DOLLARS A MONTH!
I once had a Twitter chat with Uncle Bob about Harlan Mills and TDD. The ideas that Mills used and taught are similar to the ones Kent Beck based TDD upon. The set of ordered pairs have become specific Unit tests and generalized code.
I'd like to see an editor where you're not seeing files, but nodes. Each node is a function and has nodes which traverse to calling/tobecalled nodes. Cluster groups of nodes by name (namespace/file).
Working in graphs instead of plaintext. BUT: We kind of do this right now - just now visually. Maybe it would be easier for beginners to grasp the concepts (and see complexity) as soon as we see the corresponding graph.
Even sideeffects and inpurisms would be more visible
Wow, I had the exact some thoughts a week or two ago.
I work in a really large codebase, and its horrible too, so I found it really helpful to just screenshot functions and create visual diagrams like that when I need to understand some overly-complicated data flow.
This interview with uncle Bob should be a series. It's the best you did so far, Prime.
Holy shit the two funniest guys in programming team up
Prime is funny, the bob guy is just an idiot
This was very imformative...probably one of the best videos so far...
he sound smarts, he should write a book
😅
Pure gold! This interview was awesome.
It's already 4:30 am. I guess I will go to work without sleep
homie just listen to it at work
lmao im in the same spot right now. good morning to u and ur timezone mate
Pls have enough sleep! I usually listen to Prime in bathroom hour
Strange, for me it's mostly the opposite: I will to go sleep without work
@@ja1548 😂
Great interview and I like the conflict on both of you... expecting more interviews with uncle bob
This video is a real historical gem and should be shared. :)
Thank you for this conversation with Uncle Bob. I hope you do this again, it was great.