0:00 Event Presentation 2:03 Presenter Introduces Uncle Bob 3:41 Uncle Bob Introduction / My Tribe 4:49 How Far is the Sun? 10:52 Introduction to Clean Code 12:21 The current Society works with Software 19:47 Volkswagen case / Introduction to the Ethics of Software Development 24:28 Why are Programmers so slow? 32:13 What is a Clean Code? 40:09 Analyzing some lines of code 43:43 Long code is not Good Code 49:25 Good Code / Refactored Function 52:40 Polite Code / Rules for writing a news paper article 55:25 Shrunk Code / The Rules of Functions 1:00:23 Shrunk Code / Drawing a Function 1:05:36 When and why was Java invented? 1:08:52 Prose Code / Arguments 1:16:13 Avoid Switch Statements / Problems and Evolution of some programming languages 1:26:15 The Uncle Bob's wife message (funny moment) 1:27:22 Output Arguments No Side Effects / Garbage Collection 1:32:21 No Side Effects / Using Lambda 1:34:26 No Side Effects / Command and Query Separation 1:35:30 No Side Effects / Prefer Exceptions to returning error codes 1:37:05 DRI Principle (Don't Repeat Yourself) 1:39:21 Structured Programming / Edsger Dijkstra Vision vs Actual Vision of the programming

Major thanks to the director who knows exactly what we want to see. Not the slide that has the code, rather the speaker drinking a glass of water

"You are not done when it works, you are done when it's right." Uncle bob

30:25 - After finally getting some piece of code to work, you're only done with half the job; you should spend roughly the same amount of time cleaning it. No one writes clean code first because it's just too hard to get code to work. 46:12 - Every line of a function should be on the same level of abstraction, and that level should be one below the name of the function. 52:22 - Polite code allows the reader to exit (=stop reading) early. 58:45 - A function does one thing if you cannot meaningfully extract another function from it. 1:32:22 - To make a method pair safe (remove side effect), use a lambda that does all the processing. 1:34:34 - A function that returns void must have a side effect, otherwise there would be no point in calling it. A function that returns a value should have no side effects. 1:36:00 - A function that has a try/catch block should have no other content beside that block. Within the try block, there should only be a single function call (the actual function that throws the exception).

Whoever did the screen switching needs to reconsider their profession.

After 40 years of programming, I experienced all the cases described. I just want to say how great you describe the feeling when reading code. At this level, clean code becomes poetry.

37:00 It is more important to make your code understandable by your peers rather than by the computer.

Someone used too much of the budget on intros

I have been a programmer in the 80s. In between I worked with databases a big chunk, took on the IoT, Gui, and now getting back to basics again. It was interesting how things changed over time when in the past, we knew there are better ways but there was just not enough 'time' and not enough powerful hardware. Thank you for making this lecture public. I utterly enjoyed it and the nearly 2 hours flew by. I also sent the link to my daughter who is studying computer engineering at the moment. Thanks a million!

I love how he always adds some completely unrelated, but super interesting things from other areas of expertise at the beginning of his presentations.

So it's been a few years now since I returned to Uncle Bob, and wow... I must say. He inspired me way back when I was no longer a Junior and hoping to ascend into a more senior position. And now I'm finding myself equally nodding and shaking my head at several points he's mentioning. Predicting them or criticising them. He was not the only influence, but he was a pivotal person in putting me down the path of better code, to try things for myself and form my own opinions. And above all else, I noted just how well he delivered his sessions. He speaks about code, and there's definitely competency there that he builds upon. But his ability to teach, and capture attention, to narrate and inspire or motivate is impeccable. That's the next big challenge - present what you know to juniors and seniors, and do it in a way that leaves them wanting more, not nursing a headache!

Thankfully this is on youtube with the ability to pause, if you feel the need to! But most important is what he says about it. This is not a test, but fantastic inspiration with super helpful observations. Enjoyed it tremendously!

Unexpectedly this presentation just went all over a bunch of wisdoms my very first tutor told me at university in 2014. Nice.

I see developers are complaining about the presentation length but as an engineer, I really loved the way he framed the talk from the solar system to a java function. of course, what better example than a man who calculated the sun's distance at 250 bc without any modern tools to understand our lack of creativity and patience for shitty code.

loved 31:54 .. " You are not done when it works , you are done when it's right" . I must say he really makes you look at programming with a different lens . Thanks for sharing this

Having some beer and watching Uncle Bob videos this evening. Better than anything on Netflix.

"You'll have one minute to read this slide" - camera person cuts away immediately and focuses on the audience OH C'MON!

I'm just 1 point in the lecture and i'm already learning loads. Thanks for the upload!

Management is the final decision makers. Delivery is the focus in corporates. No sayer's are thrown out. It's ok I was thrown out. But i am glad to learn the standards and follow the practices. I am learning and practicing the clean code very late at my age of 38, but i am glad I could see the big difference while coding. Thanks uncle bob.

The presentation is structured in the same way he described from abstract to detailed, lovely.

This was not only precious but very helpful to me. I though that breaking long functions would lead to more complicated code. However, having the mindset portrayed in this video, I managed to break my functions into its "do one thing" components, and even managed to eliminate redundant variables. And, not as I initially thought, my code is far more readable and maintainable. If there is a bug, you can quickly go to the function you think it is responsible for it, instead of zooming in into long functions and loose yourself. Props to this man! He enlightened me, made me see my own mistakes, and substancially made my life easier as a programmer.

Wow, thanks a lot, I'm following all article on Medium about Clean Code, and this talks is the true source of all clean code. Thanks for Sharing

Entertaining talk, but you should show the slides he is presenting while he talks instead of showing him or the audience or the presentation from so far away that you can't read it.

"It is more important your peers know how your code works, not the computer."

Such a great talk to review a couple of times.

well said, experienced the same thing on my last job. where I was required to integrate new features for a app that was developed by a team who were no longer part of the company anymore. worst thing is, it was not build according according standard. it took me ages to build a payment gateway

great lecture. watched it more than 18 months ago and going back to it every while.

I was trying hard to convince my ex boss to use some good tools and practices in our project, and moving slowly toward using a unified framework, because the current system was nothing but a mess, and he was laughing at me whenever I say that... I left the company after 3 years, now, he can’t hire anyone, because the system became over-complicated and no one can understand what the hell is going on.

Uncle Bob is great. I have seen other videos on Clean Coders channel. That's the way to go. This presentation has an exceedingly protracted intro that maybe was supposed to engender excitement, but, as I was anxious to get to the talk, I felt impatient through the entire first 4:49.

This is genius. I laughed so hard because i can realte soooo much to this. Im new to my company and spend like 6 months here and experienced all of it already. Sucking out the energy of my team by being new and unexperienced, experiencing the mess of fixing exisiting code vs the speed of building a green field project etc.

After his talk I understood that I have to refresh my knowledge and approach

This lecture is filled with pure knowledge of software engineering.

Fun to see different "authorities" in this anarchic profession stand on a stage and expunge, in total confidence, diametrically opposite advice. Uncle Bob is clearly a big OOP fan. As a programmer in my mid-fourties, I tend to agree with most of the do-s and don't-s he presents here. But it is pretty easy to find functional programming gurus, or even just plain old structural programming proponents, offering the opposite advice in almost every respect. Neither side is very good at explaining why their approach is supposedly better, and both sides manage to produce a few plausible code examples that make it seem they're onto something. I think this was a good presentation, Bob is doing a good job. Even so, I honestly don't think he is very convincing. He's really just telling us his opinions. A big exception is the part in the beginning where he points out the *need* for software development to grow up and become more responsible and accountable, but that doesn't mean his ideas for _how_ to accomplish this are any better than competing ideas. And, given how many devs really like this whole idea of us being some kind of rebels, I think there is just about zero hope this will happen. The industry will have to become regulated, and it won't be fun....

I love this man: so wise. The dark side is to consider things work but the force needs to clean this mess before reaching the next stage = When is right !

this is awesome. I Know everything he talks about, but my current job leaded me quickly to forget everything about it. I have to work hard on my motivation, to stay somewhere to not drown in my bad gooey code -.- Thank you for uploading this !

41:12 ahh yes. Let’s just keep randomly switching the camera around during this slideshow which means now you have to pause and skip around!

I have never been so humbled and enlightened

A function should do one thing, 'like creating a tree', and other great pointers. Love the perspectives! Thank you!

This man changed my life, forever!!

This man is genius and incredible, I barely watch 1+ h videos on youtube except for this one, it was joyful watching it.

I am glad that they made chapters and put them in here.

Thanks a ton for this

Code snapshots 41:15 page 1 wiki code 42:27 page 2 wiki code 44:04 page 3 wiki code 50:11 Refactored wiki code

Great storyteller! Though I initially thought he was just long winded it turns out he really gets the point across in a memorable way.

This was the best introduction to something I've ever seen in my whole life

Oooh I see multiple parts to this talk. Ahh I'm so grateful uncle Bob will be accompanying me to work tomorrow; courtesy of earbuds and discretion.

And just like that, Bob's your uncle.

Uncle Bob intro be like A WWE Wrestler Entry

Thank Uncle, I learn one more key point, that is about estimation on a `done task`. Thats great!

Nothing beats the pleasure of writing code for something you truly care for :)

Seriously whoever did the editing of this speach/video should rethink his life. When Uncle Bob shows you code read at ~42 mins in we don't care about looking at the audience/him/different cameras with not much quality. It's about the bloody code.

Great talk, I really enjoyed it. But I have to point out two things. First of all, he was a little dissmissive about the lambdas (1:32:00) which I think is a huge feature that Java lacked for a long time. Sure they can be thought of as being isomorphic to classes where captured enviroment maps to the fields and body maps to the body of the known method. But it is a huge ergonomics change, you don't need to write new Function() { Integer run(Integer i) { return i * 5 }, you can simply write i -> i * 5. This reduces clutter and enhances readability which should be the point of clean code, isn't it? Second point is, he claimed, at 1:33:38, that his open function is side-effect free, which is incorrect. It still does have a side effect (an effect that can be observed from outside, which in this case is whatever the proc does, like writing to that file). But he can claim that his function is rather resource-safe which is actually what he is talking about when he mentioned managed side effects (not leaking resources like open files, unreleased semaphores etc.). Also it would be better if he mentioned that he had to use try-finally to be absolutely sure that the resource is released no matter what. At this point he could mention non-compositional nature of try-catch as well and point us in the direction of functional effect systems like cats-effects, ZIO, etc. :)

Drawing a function part is gold. Even for Sr. developers

1:15:24 A double take is when you see something, and take it in as a normal perception; then an awareness of something in that perception causes you to look again (in surprise) to retake your perception. The idea is that there is a disparity between expected and actual perception.

Loved him in My Dinner With Andre. Had no idea he was a programmer.

30:42 this is SO true - and I'm guilty of it!

Very good talk, many thanks!

Also; Swift now has @unknown default for switch statements which will give you warnings when there are cases that you haven't accounted for and let the default only exist as a "this shouldn't happen" case.

Rest in peace Bram Moolenaar, author of Vim and hero of many developers The open source software legend left us on August 3 at age 62.

I wish the intro was juust a little longer. Like 30 mins.

It's incredible the way that my code has improved after dividing one function in many other functions.

I was tempted to add to my last comment, but I had second thoughts since I wanted to keep my comments short-- my second comment-- this is an excellent lecture.. Bob is well worth watching!!

The claim that software engineers rule the world because the software is everywhere is the same as saying that builders rule the world because there are buildings everywhere. The people who have the most influence on where to put buildings, when to write software etc. rule the world.

I'm actually taking notes like I'm back in college. Very educational.

I just love how Uncle Bob is always starting out with some science! 😁

In the future for anything substantial (e.g., life threatening or over a certain monetary threshold), there will be national software regulations and inspectors, just like with every other engineering field. How we've gotten this far without them is beyond me.

I think there must be a "Clean Directing" book too. In Clean Directing, camera looks at where you expect it to

OH MY GOD FINALLY someone is putting words to the anguish I've been feeling for years while my colleagues say things like "stop fixing things that aren't broke" or "80/20 rule" and other assorted bullshit. I knew intuitively this is bad, that code should not be done badly, and that there will be consequences. But also that the consequences are sufficiently far down the line that everyday shortsighted engineers won't recognize them. Because we got deadlines, bois! And that's all that matters! *insane traumatized cackling*

This is simply amazing. Thanks.

спасибо, очень умный мужик, было полезно!!

16:30 the pedal is mechanically connected to the hydraulics that power the brakes. The computer controls only the assisting elements, not the brakes themselves. The brakes themselves work even with the car turned off, albeit without hydraulic assistance after the first couple presses.

Aristarchus of Samos (Αρίσταρχος ο Σάμιος c.310 - c.230 BC) not only caclulated the sun-to-earth disance but, most importantly, was the first to formulate a sun-centered theory, not Copernicus.

at 11:22 "The only valid measurement of code quality is # of WTFs per minute coming out from behind the door of where a code review is taking place.." OMG !!! I will use this phrase going forward for all the code reviews I do! It sums it all up in a beautiful, humorous nugget. For the # of WTFs that have come out of my mouth (in full voice and without the use of an acronym) .... I wish I had come up with this.

Another Master piece ✌

amazing, eye-opening

This was SUPER-close to a working irony. Cue hard guitar... Now jeans. The presentation did not need the guitar intro... though it might be fun for something else.

He’s a great orator and easily understood even at 1.5x speed - ROOODE!

Just great talk! Thanks.

31:50 hmmm that makes me picture a kitchen where the chef thinks he's done when the meal is ready... he's done when he has cleaned up the mess he made while cooking it.

1:12:54 it’s not hard to see what a bool does as a function argument! Just peek at the function definition - if you have a proper name for the bool it should be clear as daylight! Having 2 separate functions instead of a bool can lead to convoluted naming as you need both DoStuffWithX and DoStuffWithoutX instead of just DoStuff(bool x). Also consider that you can use default parameters in many languages.

This talk is a treasure!

A year ago I'd agree with this presentation 99.9%, but after seen a series of videos "Clean Code - Bad Performance" view on the issue has changed drastically. I was shocked on how much slower even a simplest program can become, when we start to "clean" our code from switch-case statements, just because we afraid to forget about them and instead of coming up with utilities that can tell us that we forgot something during development stage, we make user's computer to work overtime, making it slower and getting people complain on: "Why my 16 core PC can't run Word smoothly"?!

"No modern language has a GOTO" - Uncle Bob Golang would like a word.

We don’t rule the world. We are creative people but we write the business told by business owners.

Great great lecturer, amazing didactic

this is very entertaining as well as reassuringly down to earth

1:07:12 " The best way to sell hardware was to win the hearts and minds of programmers first." That's true!

Is the water working, though? I need to know!

NOTES -- (What is clean code and how does it look like?) INTRODUCTION * Software is everywhere and so much of society depends on it. That's why it's important to have ethics and standards in software. Eventually our jobs would be regulated/legislated illogically if we make mistakes due to negligence, that's we should get ahead and decide, as software developers, what's the standard. Legislators and politicians would instead look at what we've already invented and turn that into law. It happened with doctors, with engineers, with lawyers, with architects, etc. * One thing we all value is clean code * Implementation Patterns by Kent Beck (Book) "Good code matters" * Look into who Kent Beck is * Why do programmers go so slow? Because we make a mess because we want to go fast because they expect us to meet a deadline * Usually our code isn't clean when building our app but when we get it working, we clean it up. The time it took to build it should be the time you spend to clean it up * "The only to go fast is to go well", "Twice as fast, twice as well" * "Clean code is simple and direct... clean code reads like well-written prose" - Grady Brooch * "Clean code looks like it was written by someone who cares" - Michael Feathers * The important part of your job is to write code that can be understood by others * "Clean code is when each routine is pretty much what you expected" - Ward Cunningham (No surprises, no wtfs lol) PRACTICES/CONCEPTS * Every line of a function should be the same level of abstraction (One below the name) (eg. derived object vs int) * Functions should hardly be 20 lines long, let alone 100 * Should read like an article. Start with a headline then an abstract/synopsis and get more specific with each paragraph (Be polite to the reader and allow them to exit early when they're no longer interested) * If you can meaningfully abstract one thing from a function, then your function does more than one thing * Soft rule: Keep function parameters to 2-3 * Almost never pass in booleans as an argument * Avoid switch statements. If you add another class, you'll have to go to every switch statement (Dependency magnet). Instead create base classes and derive it. Have all the relevant functions belong to that class * Open-close principle: Module should be open for extension but closed for modification * Side-effect: Causing a change to the system (eg. new keyword, leaving a file open). Side-effect functions come in pairs * Command & Query Separation: When a function is a command and returns nothings, it should have a side-effect. Queries return a value and should have no side-effects * Exceptions > error codes * Don't Repeat Yourself (DRY) * Treat software like mathematics not science. It can be proven

It would be really nice if the video showed the code the whole time Bob showed it to the audience to understand it. Much better than seeing the audience itself. Anyways, great material. Thank you

We never learned if the water was working :(

The specific advice he gives is very OOP-centric. For instance, in functional languages you have case expressions which don't have the same pitfalls of switch statements. And you wouldn't want to (or couldn't) make variables into globals, but you can easily return more than one value as a tuple or a record. Turning everything into classes seems to be encouraging functions to have side effects, but pure functions are always easier to reason about.

Very entertaining to watch, and I really agree on everything But it's probably just as effective as writing down an instruction for someone on how to ride a bike

In a collage exam where i was supposed to prove the existence of sequence of binary words suck that each neighboring elements differ in just one letter for every word size. I did so by writing a lisp program , in paper, that would generate the next sequence. Then I proved that it did that and used induction.

In my town people say: "dress me slowly I'm in a hurry"

When you read 2 years old code and you ask yourself "Who the fuck wrote this sh... uh that's me!!!"

I love the hype intro for a coding presentation.

Oh, I remember reading those examples in the book)

This video could've been perfect if the editor just showed the screen when uncle Rob was talking about code...

The mantra I've always followed when coding is "The person that follows you and will maintain your code is a homicidal axe murderer, and they know where you live!"