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

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

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.

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.

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).

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.

Whoever did the screen switching needs to reconsider their profession.

Someone used too much of the budget on intros

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

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

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.

This lecture is filled with pure knowledge of software engineering.

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.

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.

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

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.

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!

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!

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

Grandee Tio Bob!! Te queremos papá!

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

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

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.

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.

Uncle Bob: I'm putting some code on the screen, read it now. Camera operator: lol. no

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 !

Uncle Bob intro be like A WWE Wrestler Entry

And just like that, Bob's your uncle.

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

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

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

This man changed my life, forever!!

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

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

I don't think his advice applies to math based functions. When I have an equation which uses 4 variables, I don't see how I can reduce that to 3 arguments. For embedded systems, I dont even use OOP because it's more complicated than functional programming in that context. This talk is corporate coding advice where everything is written for the lowest common denominator. Everything is driven down to a bazillion very short functions.

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

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

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....

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 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 !

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.

Bob`s a legend!!! Whoever was in charge of the screen switching needs to be punished...

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

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

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*

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.

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'm actually taking notes like I'm back in college. Very educational.

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

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. :)

I have never been so humbled and enlightened

”The majority of the world’s software infrastructure is held together by the equivalent of paperclips, duct tape and chewing gum” -Random guy on reddit

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

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.

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.

"lol people are cutting away too fast!" It's called the pause button, press the period key to go back by a frame, mash it to get to where you need to, the Question Mark key brings you forward one frame. Easy. Also this is some good stuff honestly, Learning programming and this stuff is still opening my eyes.

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

I love the hype intro for a coding presentation.

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

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 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!"

My main thought about the first 19 minutes of this is "With great power comes great responsibility"

tough crowd - his jokes were A+

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

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

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.

Who else is thinking about their code while watching this ? And virtually applying the the fixes you are gonna do 😅

28 minutes in quote of the day... you add new people to the team, and they suck the life out of the existing ones, so true---

Sometimes, the 1.25 KZfaq speed is a godsend.

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

We never learned if the water was working :(

As a "straight out of university" to "Senior Architect Wizard Lord & Software Engineer" @ flashy SF hardware startup called "SoftwareIsn'tRealEngineering.com" this talk is Extremely Fucking Useful. Thank you Tio Bob!

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.

As a CIO for decades if I ever saw a programmer working on code, I will call walk over to him and ask to see the design/flowchart. If he cant produce one, he is shown the door. Ask yourself this: can a contractor build a good high rise building w/o blueprints or a design? Answer: NO! so why are you coding w/o a good design? A good design is where it ALL begins. Dont even think about coding w/o a design. I have begun my career in the 70s on mainframes as an assembly programmer, since then I learned 13 different languages. At one point I was a systems programmer for the nations largest Bank. I interfaced with the Application manager for the Credit card business in the bank. This comprised of thousands of COBOL systems. I asked to see some documentation, and it was not available. I was stunned. I set out to flowchart the entire credit care processing system, both manual and automated systems. I placed it on a huge wall in a conference area. I called it the "wailing wall". Various programmers would come in and look and it was the FIRST time they understood how THIER application fit into the entire processing system. I asked the programming manager to come in and study the wall. He never realized what a mess it was! We both set down to redesign the entire process. We analyzed bottlenecks (both manual and automated) and set out to re-code. I stopped him ion his tracks and said "No way you are doing this w/o a good design and flowchart of each system. We spend months developing proper documentation (design docs/flowcharts etc.) We then assigned programmers to different tasks. they found coding MUCH easier because of the documentation. We (application manager and I) setup a code review board where nothing bad got thru. The review board would DEMAND that ALL function have self documenting comments, and code have comment blocks describing exactly what is going on. We had hired a programmer who had a doctorate in mathematics to develop a date calculator module in COBOL. he was brilliant at math, but a BAD COBOL programmer, he wrote VERY complex code that was VERY difficult to read. This module was going to be used by HUNDREDS of COBOL programs and any bug in it would create havok in many programs if it went wrong. This module was hardlinked to each application. I looked at it and thought "I want ANY application that depends on another module MUST be dynamically linked" IBM said "You cant call COBOL modules dynamically from another COBOL program. As an assembler programmer I thought "the O/S and CPU could care less WHAT language the source is" so I set out to design applications written in COBOL to dynamically link other COBOL programs, and it WORKED flawlessly. this was in 1974, and its still running to this day. all because of a GOOD design

Great job of the camera guy switching __out__ of the code when we are supposed to read the code.

started watching this speech thinking it was going to be a self-righteous blabber about how everyone does this or that wrong. But my goodness, he really did a fantastic job explaining the what, why and the hows, I will be ging back to refactor a bunch of my team's code. Thanks Uncle Bob

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.

With recent software update issue, flights were grounded, some hospitals stopped working, some retail systems stopped working... All because of a single software update issue. World already recognized the importance of software

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

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

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.

it is more important that your peer understand your code than computer, you talk to your peer in computer language...golden words said💯

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

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

This camera work is killing my vibe man

There are some things I disagree with Output arguments - it can be very useful to send a buffer in to be filled. To make this work nicely, you merely need to have consistent calling conventions. Most C library functions that do operations on buffers will take the destination first, and then the source. When a buffer needs a size, the size is always paired with it. This is important in C because the less you have to allocate memory from the heap, the better. If the program owns all of the memory it uses, then bottlenecks from system calls are less likely to occur. Plus, in C, you should be marking every input buffer as const so that it can't be modified in the function. That way when you have a naked `char *`, it's more apparent that it's an output argument. size_t read_line(char *buffer, size_t bufsz); If I see a function like this, I will expect it to populate buffer with user input up to a max number of bytes bufsz, and then return the number of bytes written to the buffer. Boolean arguments - sort of. If I have several similar functions that handle logging for example, I might want to combine them and factor out their differences into a single argument to keep the implementation in one place. Rather than a boolean argument, I'll actually have it take a number named flags, and then write several macros that call the complex function with different combinations of the flags. This achieves a nice interface with function-like macros that have obvious names while the implementation doesn't have to repeat several identical steps across a litany of similar functions. I mainly use this for debug/logging functions, but hey, delete_employee("Bob", DEFLAG_KEEP_SSN | DEFLAG_FIRED) is easier to read than delete_employee("Bob", false, true). void log(FILE *file, char *message, int flags); define log_error(msg) log(stderr, (msg), LOGFLAG_ERROR) define log_info(msg) log(stdout, (msg), LOGFLAG_INFO) define f_log_error(file, msg) log((file), (msg), LOGFLAG_ERROR | LOGFLAG_NO_FFLUSH) (etc) This is heavily simplified but you get the picture. Returning error codes, or a function with side effects returning a value - this is obvious to a C programmer. There is quite a bit of utility to being able to evoke side effects and return information about those side effects, like populating a buffer and returning the amount of characters that were written. Yes, the caller has to deal with returned error codes immediately, but I don't see a problem with this. Goto considered harmful - If you use gotos correctly, they are not harmful. I use gotos as exit points for a function, as part of my error handling process. The corresponding label is tucked neatly at the bottom of the function and where it begins and ends is clearly delineated. They are well-named and not allowed to jump to other labels. Because of this, gotos ONLY jump forward, and you don't have to follow them to know what they do, as they are named like functions. if (something_went_wrong) goto exit_something_went_wrong. Oh, if something goes wrong it'll exit the function for that reason. Seems good! Like every language feature, there is a right way and a wrong way to use it. It shouldn't be demonized just because the wrong way makes spaghetti code possible. Don't remove features, discipline programmers to use them correctly. Granted a lot of this is C philosophy. We're talking about a language that has undefined behavior. It demands that its users know what they're doing and promises unparalleled performance in return. C may not be easy to get along with, but if you take the time to learn the discipline, it will treat you well. That discipline can come from hard-won experience or it can come from a set of guidelines like MISRA or BARR. I love C because it is minimalistic and simple. Unlike The Right Thing™, C follows the philosophy of Worse Is Better. it's intentionally suboptimal, leaving the users to pick up the pieces and beware the pitfalls of doing things wrong. It doesn't hold your hand, but in return, the users create tools to deal with those pitfalls. The technology improves. The Right Thing™ is alluring and sexy, but it takes a long time to develop and requires more resources. Worse Is Better is worse, but it works and requires little resources. Like a virus, it spreads and spreads, and as people adopt it, the technology improves. C may be a dangerous language in the wrong hands, but look at a modern C compiler. They have so many useful warnings and optimizations that blow everything else out of the water. Your Java compiler may be able to prevent basic mistakes by enforcing strong typing and including run-time sanity checks, but a C compiler can warn about those things and optimize it to be hundreds of times faster. Undefined Behavior is seen by many as a flaw in the language, but in reality, it gives the compiler freedom to make insane optimizations. All you have to do is beware of those pitfalls. And compilers are getting better and better at pointing them out.

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

The priority is always: - Make it work (or fail as fast as possible) - Make it fast (perf optimization) - Make it nice (clean code) So clean is at the bottom of the list for any coder/manager, it doesn't provide value right away or show up on any spreadsheet, so nobody cares :))) ...until the senior dev leaves ;)

Such a great talk to review a couple of times.

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

Very nice video. Except for the fact that you are filming him when he is drawing, instead of the screen.

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.

The intro wasn't long enough lol.

30 minutes in and I have to pause the video just to give it a thumbs up and to write this comment. This is so beautiful, and is exactly what I need.