Looking for books & other references mentioned in this video? Check out the video description for all the links! Want early access to videos & exclusive perks? Join our channel membership today: ua-cam.com/channels/s_tLP3AiwYKwdUHpltJPuA.htmljoin Question for you: What’s your biggest takeaway from this video? Let us know in the comments! ⬇
Uncle Bob, if you ever meander through these comments, know that there are developers in their twenties that are reading your work, Design Patterns, DDD, Fowler's Refactoring, etc. We are few and far between, but we do exist, and we appreciate you old cooks for doing the hard work for us!
Two complete masters of software. I think they don't or can't really dimension the contribution they did to the world of programming and computer systems. What a pride to hear this two.
I'm still a student learning java, and doesn't understand most of the topics but I love how passionate they are talking about the deep concepts of what I'm currently learning. This is surprisingly motivating 💖
The problem with software development is that you find out that your rookie developers good idea turned out a year or more later to trap you with a product that is in not maintainable. Oops.
yes and no, there is the counter force that things that are healthy take more effort than other options with initially seemingly equal benefits and that tends to dissuade people. Especially when they have strict deadlines.
as a guy in his 20th who develops software in both C# and C++ on a daily basis, I have to say: The biggest challenge for me when designing code is knowing what architecture will yield best result, but also future proof in some extent. This is something that comes with experience, but I try to think in modules. That every function if possible should do one thing, and be reusable. But at the same time, I'm held back by legacy code which has a big as smell to it. Something that forces me to adopt to the senior guys convention, even tho they agree with me on refactoring things and making things cleaner. We're restricted by time and resources.
I'm 42 years old and I read a ton of these books. And While I joined the developers a bit later and don't have 20 years of experience on my belt yet, I can honestly say... yes... most teams out there suffer from Junior overload. Even the architects and lead designers have absolutely no clue what they're doing. I've seen so much messy code it's incredible. Agile usually means daily standups and then do everything like you did before, including having zero customer feedback. Three companies I worked for openly told me they have zero idea how their software is even being used or who is using it. It's a hot mess out there and most interview questions ask about some of these book titles but when you enter the company you realize nobody in the company ever read them, because you can see every principle of every single book being violated in the codebase, and half the time most developers don't even have a grasp of the language they're using.
Haha yup. When i joined my current company a senior developer got me to study the SOLID principles. So i did that, then soon realised neither he nor anyone else in the team actually followed them 😳😂😂
@@manishm9478 When someone writes "SOLID Principles" as nice to have in the job description, I turn around and walk away. You can pretty much bet on the fact that everything they write in the job description is stuff nobody in team knows how to do. And if it's basic stuff, the team is horrible. A competent team doesn't look for a guy that knows the solid principles, because they know this is the most basic stuff. That's like a hospital looking for a surgeon and writing "nice to have: basic understanding of anatomy"
Marquet’s latest book (Leadership is language) is equally fascinating as Turn the ship around. Highly recommended if you want people to collaborate effectively as well as feel empowered
The trick is to turn these books, these ancient tomes, into TikTok or UA-cam shorts or FB reels or whatever they are. That's how the "youth culture" would consume them.
This video was great to watch. Thanks to the organisers for organising it and thanks to Allen and Bob for talking so well and intelligently about these topics.
One hack for managers who oppose mob programming: call it a meeting (or even something like an "active meeting"). That'll either help reduce their opposition to it, or will help build their opposition to all meetings.
Similar observation. Alan is a pile of strong opinions, I don't understand why he acts like being on the proficiency level of Bob. He criticizes the ideas in his books implying that they are not important and presents his "superior" viewpoints. This guy is quite balooned
Holy shit it's finally here. And it's only 30 minutes long lol Edit: they're in disagreement enough to make this quite productive IMO, thank you very much to all involved.
11:34 is truth - I spent 2 months building a feature that was already done on Excel just because people wanted to have it in the web application... It is supposed to be used 2 times a year, approximately 1 hour each time...
I actually bought his book after watching this video a few months ago. Came back to say I was NOT disappointed. On the contrary. I wish I had read this 10 years ago. This is a mandatory read for EVERY professional programmer. Period.
As someone with 8 years professional experience (20+ years programming), this video talk comes off as a "get off my lawn you young whippersnappers!" attitude, especially from Bob. An example is he laughs off the "legitimate" criticism that a code architecture that's over-engineered with design patterns INCREASES complexity and code count, not reduces it. But Bob laughs it off as "kids tearing through the place". In fact through most of the talk Bob seems more interested in laughing at his own one-liners than having an actual meaningful conversation.
Here are the notes I took for myself from this video: it takes more than 10 years to really understand what is going on under the hood devs are limiting themselves with the given tasks, not considering whole picture mob(pair) programming is best for learning and getting things done at the same time remote working is killing collaborativity and doesn't let mob programming
It's all BS. Most of Martin revelations is his personal struggle with his own personal issues. He takes it and tries imposing it on every developer as a universal moral imperative. Find the actual code that Martin created and check that it sucks.
Agree, too much sell pitch from Martin, although thanks to Holub very interesting discussions, think mob-programming and pair-programming is good ideas for increased learning and productivity.
"Are any of the young kids out there reading Design Patterns?" - I normally recommend Head First Design Patterns over the GoF book as a better learning opportunity. GoF is a great reference manual for after that.
young kids should not be reading design patterns. You'll never appreciate it unless you have perspective. it would be like like teaching integration before they learn algebra.
@@devenpatel2 Agreed for the design patterns book itself. But people do come onto grad schemes wanting to learn about 'best practice' - the trick is to teach alongside the context. GoF expects you to have the context, which you absolutely would have if you were coding when the book came out. It was essentially describing and putting names to things you were doing *anyway*. Head First Design Patterns is a really nice introductory text that takes a working example and describes where design patterns are useful, in the right context. Definitely worth a read even if you know these like the back of your hand.
I would argue DDD became popular as we got more developed frameworks, such as Spring for Java, that help you remove boiler plate and isolate business logic. DDD can be difficult to manage when you're elbow deep in boiler plate. It's also difficult to visualize DDD when you're having to keep all your business logic in a tight realm.
I tasked myself to keep watching Bob Martin videos until at least I found one that explains why he is called Uncle... I would like him and his track to disciplining the coding world to meet / talk seriously with Paul Hudson.
These two look like sales guys. 16 min. in just book suggestions and vagueness. Not one specific example like: recently I've been working on this and used this and this helped me achieved this. Sounds like: what I'm saying is so good and it works, you can read all about it in my books.
Hi mate, After I had watched this video, I went to search for more materials authored by Allen, since I had already been acquainted with Bob. So far I feel that I am learning new things that will actually make my life at work better.
When I hear "Test driven development" I'm thinking, "I do that. Every time I make a change I test it to see if it works". Then I realize pretty much everyone tests their code to see if it works after every change.
The submarine has about 110 people staff, not 50 or 60 as stated by Allen at 18:20. And there is considerable hierarchy, which makes captain's achievement even more impressive. Anyway, I read the book, too (twice).
Yup, and David Marquet found a bunch of other little innovations that played a role in making the system work. Thinks like raising the crew's competence as he delegated authority, instead of dropping it on them all at once. Or handling failures in a no-blame way - looking at the system causes, not the people. Or encouraging frequent communication - talking out loud about your intentions, so others can overhear and understand your intent.
What's been overlooked by many regarding working remote: "It works" is not the same as "it works as well", or "it works better". Most have simply reverted to virtual cubes.
Too many frameworks are blinding the new programmer of today to understand the basic building blocks of their programs and the necessity of having a good architecture . A large number of frameworks give the promise of out of the box clean architecture and agile features and all these buzz words when in reality most aren't and so trying to tell a programmer that is dependent on these about design patterns and so on is just a futile mission.
It seems to me, from what I've seen of junior developers, that schools are teaching people (or they're learning on their own) how to CODE (i.e. syntax) but not how to PROGRAM (i.e. clean code), and they just have no concept that architecturally their code is a mess, and that's why things take so long to roll out (even in a greenfield project), are so buggy (because it's really hard to test large convoluted functions), and is just generally a chore to deal with. In my opinion schools should just assign Clean Code/Architecture and Refactoring as the main textbooks every single year, and then tangentially learn some programming languages. At my school, CS101 started with C++ datatypes, recursion, etc, etc, but never once was testing, TDD, refactoring, or clean code brought up, let alone taught.
We have one such subject, it's called software systems, and the professor gives Kent Beck vibes. But I struggle to make things work at all, I can't focus on principles. Plus the rest of the team doesn't care, and we also struggle to collaborate with the team at all. I'm not sure it'd be better even if we learned principles from earlier, because we just have to learn them later.
welcome to 2023, new watcher, when the book featuring Clojure is about to be released on Halloween's day: "Functional Design: Principles, Patterns, and Practices"
"How does a military captain pull that off? " easy. His team is not agile, they have clear chain of command and instructions. While self-organized agile developers tend to have their own opinions and beliefs 😌
While this was very informative, it felt like most of the talk was about good ideas and thoughts but the final part was just complaining specially as the focus on it was mainly in terms of an organizational POV rather than an employee at least for most of it. It was still a good video nonetheless. The key points I got out of this is that just because a book is old, doesn't mean it has less values, that people should seek human to human connection tho you don't need to do that by going into an office every day and a change in the way to work/think about coding, architecture and the way to work itself can be helpful yet may be met with a difficult audience.
Let's be honest about it, they are crooks in the business of selling hours. It looks like they are creating the illusion of smaller cost of change by significantly increasing the cost of initial development. What precise metric would you employ to have this in perspective? For reference, my metrics are volume of codebase (loc, number of classes, number of methods, anything is fine with me here). and cyclomatic complexity. Both these metrics correlate naturally with cognitive load. If i measure the codebase of a project implemented with economy in mind (using any of my metrics) and then measure the codebase of the same project made with Clean Architecture. In this project the codebase is orders of magnitude bigger!!! The change always looks the same!
Maybe this is a dumb place for such a question, but as an undergraduate, is there hope I'll avoid the miserable stories people tell from working in companies? At least, what's the shortest path out of them?
The sad part is this cognitive dissonance about improvement gets worse with matters of infrastructure. Code is something you can refactor with more or less autonomy, even behind the scenes, even under bad architecture. But try to turn around a ship based on hardware dependencies that could harm the service lifecycle in the long term. Some managers often put their crews to swim along with sharks because their teeth seem familiar and expect the crew to deal with bitings by themselves without complaining. In such circumstances, ITSM is less of a sitcom and more of a doomsday movie. And it happens more often than people think.
Honestly I am seeing this in my workplace as well. there are many people who simply write code w/o understanding design principles. I am seeing if block within if block within...5 levels deep. It is so annoying. What about code review? do not even ask for this. there are many people who take things personally.
I always say there is no agility in developing good and reliable software. It will always take time whatever methodolgy you use. I hope senior dev tell new dev that developing IT solution is long and tedious process with no viable shortcuts. Delivering solution is more about commitment than technical knowledge. If you are committed you can find ways to learn what is needed.
Sorry but that was a really really bad intro. Because I thought that is the video, just fast cuts.. Brrr I wanted to turn it off and than I realized that was only the intro
at around 17:55 Alas in the military its a dictatorship no room for democracy. Bootcamp used to insert a subtle case of stalkholm syndrome into the recruits before letting them go on in the Navy. I hear that is changing but I know that was the way a couple decades ago.
at around 25:09 modular programming might help that situation. Kind of like how parts of a smart phone are made in completely different parts of the world and somehow they all come together in the end.
Looking for books & other references mentioned in this video?
Check out the video description for all the links!
Want early access to videos & exclusive perks?
Join our channel membership today: ua-cam.com/channels/s_tLP3AiwYKwdUHpltJPuA.htmljoin
Question for you: What’s your biggest takeaway from this video? Let us know in the comments! ⬇
Uncle Bob, if you ever meander through these comments, know that there are developers in their twenties that are reading your work, Design Patterns, DDD, Fowler's Refactoring, etc. We are few and far between, but we do exist, and we appreciate you old cooks for doing the hard work for us!
Two complete masters of software. I think they don't or can't really dimension the contribution they did to the world of programming and computer systems. What a pride to hear this two.
I'm still a student learning java, and doesn't understand most of the topics but I love how passionate they are talking about the deep concepts of what I'm currently learning. This is surprisingly motivating 💖
get back to them after 2-3 years and you will understand
University Computer Science is now considered harmful
"If it's a good idea, the good idea tends to spread, unless there's somebody at the management level working hard to make it not spread"
- Allen Holub
exactly. this is why I left my previous job. Management worked hard to repress good ideas.
@@theawt! 8😭l
The problem with software development is that you find out that your rookie developers good idea turned out a year or more later to trap you with a product that is in not maintainable. Oops.
yes and no, there is the counter force that things that are healthy take more effort than other options with initially seemingly equal benefits and that tends to dissuade people. Especially when they have strict deadlines.
I'd listen either of them for more than an hour
Very disappointed this isn't at least that long TBH.
as a guy in his 20th who develops software in both C# and C++ on a daily basis, I have to say: The biggest challenge for me when designing code is knowing what architecture will yield best result, but also future proof in some extent. This is something that comes with experience, but I try to think in modules. That every function if possible should do one thing, and be reusable. But at the same time, I'm held back by legacy code which has a big as smell to it. Something that forces me to adopt to the senior guys convention, even tho they agree with me on refactoring things and making things cleaner. We're restricted by time and resources.
I'm 42 years old and I read a ton of these books. And While I joined the developers a bit later and don't have 20 years of experience on my belt yet, I can honestly say... yes... most teams out there suffer from Junior overload. Even the architects and lead designers have absolutely no clue what they're doing. I've seen so much messy code it's incredible. Agile usually means daily standups and then do everything like you did before, including having zero customer feedback. Three companies I worked for openly told me they have zero idea how their software is even being used or who is using it. It's a hot mess out there and most interview questions ask about some of these book titles but when you enter the company you realize nobody in the company ever read them, because you can see every principle of every single book being violated in the codebase, and half the time most developers don't even have a grasp of the language they're using.
Well said
Haha yup. When i joined my current company a senior developer got me to study the SOLID principles. So i did that, then soon realised neither he nor anyone else in the team actually followed them 😳😂😂
@@manishm9478 When someone writes "SOLID Principles" as nice to have in the job description, I turn around and walk away. You can pretty much bet on the fact that everything they write in the job description is stuff nobody in team knows how to do. And if it's basic stuff, the team is horrible. A competent team doesn't look for a guy that knows the solid principles, because they know this is the most basic stuff. That's like a hospital looking for a surgeon and writing "nice to have: basic understanding of anatomy"
@@LeutnantJoker that's an interesting heuristic. So the teams you work in both understand and apply SOLID?
@@manishm9478 some do. It's rare. But if they write it into their job description then I KNOW they dont
There is so much maturity in this talk
Marquet’s latest book (Leadership is language) is equally fascinating as Turn the ship around. Highly recommended if you want people to collaborate effectively as well as feel empowered
Thanks, Ozgen, will check it out!
Thanks for recommendation bro ✊
The trick is to turn these books, these ancient tomes, into TikTok or UA-cam shorts or FB reels or whatever they are. That's how the "youth culture" would consume them.
This video was great to watch. Thanks to the organisers for organising it and thanks to Allen and Bob for talking so well and intelligently about these topics.
One hack for managers who oppose mob programming: call it a meeting (or even something like an "active meeting"). That'll either help reduce their opposition to it, or will help build their opposition to all meetings.
If it weren't for Allen's propensity to block anyone who disagrees with him he'd be worth listening to.
Similar observation. Alan is a pile of strong opinions, I don't understand why he acts like being on the proficiency level of Bob. He criticizes the ideas in his books implying that they are not important and presents his "superior" viewpoints. This guy is quite balooned
Holy shit it's finally here.
And it's only 30 minutes long lol
Edit: they're in disagreement enough to make this quite productive IMO, thank you very much to all involved.
This talk is GOLD! Watch and learn.
Beem waiting for this ever since I saw the announcement!
There's always room for improvement in one's coding practices. ☺️♥️
Coding practice or software development practice?
@@dsmyify Pretty much both, but don't they mean the same thing?
@@FloatingSunfish Software development encompasses things like user research and design and product management and all that jazz, so not really.
@@ottorask7676 Ah, true. It's a much bigger scope.
Thank you all for this conversation. :)
11:34 is truth - I spent 2 months building a feature that was already done on Excel just because people wanted to have it in the web application... It is supposed to be used 2 times a year, approximately 1 hour each time...
Two of my favorite speakers/teachers in the same conversation. Incredible:)
Wonderful discussion, wonderful people! I'd like to see more videos like this one.
Excited for the new book, will be looking out for it!
Its so lovely when They both laughting :D
I hope he does write that book on Clojure. Make it spiral bound, please.
Yeah, I'm not sure why most books are not spiral bound.
I miss Uncle Bob! This is awesome.
Many thanks for your talk!
Time and money spent on commuting is also a cost which developers can avoid if they don't go to the office. Consider this as well.
I actually bought his book after watching this video a few months ago. Came back to say I was NOT disappointed. On the contrary. I wish I had read this 10 years ago. This is a mandatory read for EVERY professional programmer. Period.
which book are you referring to? there are MANY recommended :P
@@CameronOlivier Clean Code. But Clean Architecture is great too. As a sequel ;)
@@willemvdk4886 Clean code is great! still need to read Clean Architecture :D it's on the (very long) list....
Best video ever. Love u uncle bob!
I would request people to go to cleancoder podcast and listen to “Greatest programming books you might have ever heard of” by Uncle Bob.
As someone with 8 years professional experience (20+ years programming), this video talk comes off as a "get off my lawn you young whippersnappers!" attitude, especially from Bob. An example is he laughs off the "legitimate" criticism that a code architecture that's over-engineered with design patterns INCREASES complexity and code count, not reduces it. But Bob laughs it off as "kids tearing through the place".
In fact through most of the talk Bob seems more interested in laughing at his own one-liners than having an actual meaningful conversation.
I love it. I love all boomer rants for some reason. But you call yourself "Chad".
Here are the notes I took for myself from this video:
it takes more than 10 years to really understand what is going on under the hood
devs are limiting themselves with the given tasks, not considering whole picture
mob(pair) programming is best for learning and getting things done at the same time
remote working is killing collaborativity and doesn't let mob programming
It's all BS. Most of Martin revelations is his personal struggle with his own personal issues. He takes it and tries imposing it on every developer as a universal moral imperative. Find the actual code that Martin created and check that it sucks.
Agree, too much sell pitch from Martin, although thanks to Holub very interesting discussions, think mob-programming and pair-programming is good ideas for increased learning and productivity.
"Are any of the young kids out there reading Design Patterns?" - I normally recommend Head First Design Patterns over the GoF book as a better learning opportunity. GoF is a great reference manual for after that.
young kids should not be reading design patterns. You'll never appreciate it unless you have perspective. it would be like like teaching integration before they learn algebra.
@@devenpatel2 Agreed for the design patterns book itself. But people do come onto grad schemes wanting to learn about 'best practice' - the trick is to teach alongside the context. GoF expects you to have the context, which you absolutely would have if you were coding when the book came out. It was essentially describing and putting names to things you were doing *anyway*.
Head First Design Patterns is a really nice introductory text that takes a working example and describes where design patterns are useful, in the right context. Definitely worth a read even if you know these like the back of your hand.
I often ask the same questions, but shorter: "Are any of the young kids out there reading?"
What’s the issue with GoF?
The Introduction from there is great and fruitful of thoughts, but other parts is very bounded to Java and C++ from the era of 90s
Clean Code book is the greatest book i ever read.
I would be excited to read a book on Clojure by Uncle Bob!
I'm a simple man, I see Uncle Bob in the title, I watch the video.
Amazing talk!! 😃 Thanks for the great content 💪🏻
Hoping for a Jordan Peterson collaboration: Clean Room.
I read most of them Uncle Bob. Thanks for all you done for our sector and make our life easier !!
Can you help with a list of these books
@@oluwaseunsorinola7039 Clean Code, Clean Architecture - that's the ones I read
I would argue DDD became popular as we got more developed frameworks, such as Spring for Java, that help you remove boiler plate and isolate business logic.
DDD can be difficult to manage when you're elbow deep in boiler plate. It's also difficult to visualize DDD when you're having to keep all your business logic in a tight realm.
Back then, I wrote my own frameworks to hide the boiler plate.
This talk was educative and fun to watch.
@Jonas Jonaitis Alright, grumpy grandpa. You can have fun talking about serious topics. The speakers were doing it.
great video educative as well as funny at the same time..
I tasked myself to keep watching Bob Martin videos until at least I found one that explains why he is called Uncle... I would like him and his track to disciplining the coding world to meet / talk seriously with Paul Hudson.
Uncle bob has his own airplane? Good for him!
@@lgylym rich rich
These two look like sales guys. 16 min. in just book suggestions and vagueness. Not one specific example like: recently I've been working on this and used this and this helped me achieved this. Sounds like: what I'm saying is so good and it works, you can read all about it in my books.
Hi mate,
After I had watched this video, I went to search for more materials authored by Allen, since I had already been acquainted with Bob. So far I feel that I am learning new things that will actually make my life at work better.
When I hear "Test driven development" I'm thinking, "I do that. Every time I make a change I test it to see if it works". Then I realize pretty much everyone tests their code to see if it works after every change.
Well, yeah. But you got it backwards - _test driven_ development. In TDD, the tests come before the production code.
The submarine has about 110 people staff, not 50 or 60 as stated by Allen at 18:20. And there is considerable hierarchy, which makes captain's achievement even more impressive. Anyway, I read the book, too (twice).
Yup, and David Marquet found a bunch of other little innovations that played a role in making the system work. Thinks like raising the crew's competence as he delegated authority, instead of dropping it on them all at once. Or handling failures in a no-blame way - looking at the system causes, not the people. Or encouraging frequent communication - talking out loud about your intentions, so others can overhear and understand your intent.
Clean Clojure as the last book for clean closure would earn some style points for sure
Uncle Bob! Yay, the John Connor of programmers!
What's been overlooked by many regarding working remote: "It works" is not the same as "it works as well", or "it works better". Most have simply reverted to virtual cubes.
Too many frameworks are blinding the new programmer of today to understand the basic building blocks of their programs and the necessity of having a good architecture . A large number of frameworks give the promise of out of the box clean architecture and agile features and all these buzz words when in reality most aren't and so trying to tell a programmer that is dependent on these about design patterns and so on is just a futile mission.
The fear of control-inversion is on many levels.
It seems to me, from what I've seen of junior developers, that schools are teaching people (or they're learning on their own) how to CODE (i.e. syntax) but not how to PROGRAM (i.e. clean code), and they just have no concept that architecturally their code is a mess, and that's why things take so long to roll out (even in a greenfield project), are so buggy (because it's really hard to test large convoluted functions), and is just generally a chore to deal with. In my opinion schools should just assign Clean Code/Architecture and Refactoring as the main textbooks every single year, and then tangentially learn some programming languages. At my school, CS101 started with C++ datatypes, recursion, etc, etc, but never once was testing, TDD, refactoring, or clean code brought up, let alone taught.
We have one such subject, it's called software systems, and the professor gives Kent Beck vibes. But I struggle to make things work at all, I can't focus on principles. Plus the rest of the team doesn't care, and we also struggle to collaborate with the team at all. I'm not sure it'd be better even if we learned principles from earlier, because we just have to learn them later.
I find it amusing that uncle bob is in a channel called goto; as someone who advocates against using gotos
Uncle Bob, I do read Design Patterns
I love you Bob. Your my hero! I do programming every working day and that is my favourite thing to do since young age.
This could easily be 2.5h long and I'm disappointed it isn't
welcome to 2023, new watcher, when the book featuring Clojure is about to be released on Halloween's day: "Functional Design: Principles, Patterns, and Practices"
Golden :)
I love the way these guys showed me how ignorant I am, I need to go book shopping ASAP.
"How does a military captain pull that off? " easy. His team is not agile, they have clear chain of command and instructions. While self-organized agile developers tend to have their own opinions and beliefs 😌
While this was very informative, it felt like most of the talk was about good ideas and thoughts but the final part was just complaining specially as the focus on it was mainly in terms of an organizational POV rather than an employee at least for most of it.
It was still a good video nonetheless.
The key points I got out of this is that just because a book is old, doesn't mean it has less values, that people should seek human to human connection tho you don't need to do that by going into an office every day and a change in the way to work/think about coding, architecture and the way to work itself can be helpful yet may be met with a difficult audience.
The bottle neck IMHO is not zoom vs in person, it is sync vs async.
I read Design Patterns. Pat, pat
Structured Analysis and System Specification - No one reads it as it's $55 dollars with no ebok version.
Uncle bob needs a better mic setup.
Let's be honest about it, they are crooks in the business of selling hours. It looks like they are creating the illusion of smaller cost of change by significantly increasing the cost of initial development. What precise metric would you employ to have this in perspective?
For reference, my metrics are volume of codebase (loc, number of classes, number of methods, anything is fine with me here). and cyclomatic complexity. Both these metrics correlate naturally with cognitive load.
If i measure the codebase of a project implemented with economy in mind (using any of my metrics) and then measure the codebase of the same project made with Clean Architecture. In this project the codebase is orders of magnitude bigger!!!
The change always looks the same!
Remote is meh now because the software environment for it hasn't been developed yet. The world has evolved since unix days.
Maybe this is a dumb place for such a question, but as an undergraduate, is there hope I'll avoid the miserable stories people tell from working in companies? At least, what's the shortest path out of them?
Can you add subtitles, please? I can hardly follow Allen's rant... He must be the fastest speaker in the world...
Im confused because I thought Allen was really not a fan of Bob on a personal level
Professionalism 🤷
Not being a fan does not mean there can't be constructive discussion about things.
Totally agree. You saving money by loosing discipline and productivity.
Was this video about the path to programming or a whole bunch of old guys that don’t like change?
Those old farts are a treasure!
The sad part is this cognitive dissonance about improvement gets worse with matters of infrastructure. Code is something you can refactor with more or less autonomy, even behind the scenes, even under bad architecture. But try to turn around a ship based on hardware dependencies that could harm the service lifecycle in the long term. Some managers often put their crews to swim along with sharks because their teeth seem familiar and expect the crew to deal with bitings by themselves without complaining. In such circumstances, ITSM is less of a sitcom and more of a doomsday movie. And it happens more often than people think.
Evil laughter at 25:01 👍
Im dealing with EJB right now.
love uncle bob
Honestly I am seeing this in my workplace as well. there are many people who simply write code w/o understanding design principles. I am seeing if block within if block within...5 levels deep. It is so annoying. What about code review? do not even ask for this. there are many people who take things personally.
Geez these guys are very bitter and jaded
This chat is way too short.
"Thank God we don't have to deal with EJBs anymore". Amen
I always say there is no agility in developing good and reliable software. It will always take time whatever methodolgy you use. I hope senior dev tell new dev that developing IT solution is long and tedious process with no viable shortcuts. Delivering solution is more about commitment than technical knowledge. If you are committed you can find ways to learn what is needed.
Its not tedious, all this designing process is incredibly fun
@@matheusmurray2425 I am lost at your comment, so you mean software development is fun, fast and agile?
I agree with the point, but I believe agile means maneuverable, not fast. "Manifesto for agile software development"
Sorry but that was a really really bad intro. Because I thought that is the video, just fast cuts..
Brrr I wanted to turn it off and than I realized that was only the intro
Holub means Pigeon in Ukrainian
Maybe that's why he craps on so much stuff :-).
🥰
Pick Kotlin :P
Just use functional design patterns :P
@@mskiptr of course. But Bob was wondering which language he would pick for his book...
Anything that doesn’t use the JVM would be fine. Thanks
@@xtinctspecies the jvm isn't really relevant when it is about the functionality of a language
Allen seems to be in a studio. Uncle Bob is in a tin can.
This is fun to watch and all, but I can't help but see the irony in two people talking remotely about how remote doesn't work. 😕
cok bir sey konusmamislar da abartmayi seven nerd tayfa abartir simdi oo super muhabbet falan
Programmers should have the same martial artists karate 🥋 and chief🧑🏽🍳 mindset
SOLVE A PROBLEM, STOP INVENTING NEW WAYS TO SOLVE A PROBLEM, JUST SOLVE A FUCKING PROBLEM!
DO NOT CREATE PROBLEMS SOLVE THEM!
If you want people to come back to the offices to "smell each other" then perhaps President Biden might be interested in facilitating that!
I wish I could listen to this, but there's too much laughter and nothing funny.
at around 17:11 - inserting a seed of cognitive dissonance.
at around 17:55 Alas in the military its a dictatorship no room for democracy. Bootcamp used to insert a subtle case of stalkholm syndrome into the recruits before letting them go on in the Navy. I hear that is changing but I know that was the way a couple decades ago.
at around 25:09 modular programming might help that situation. Kind of like how parts of a smart phone are made in completely different parts of the world and somehow they all come together in the end.
It's a bit hard to get past the "boomers are great" narrative. Interesting but so much ego.
Clean Architecture is a scam
why?
[citation needed]
translation: "I don't understand the Dunning-Kruger effect"
Yep. The other books too.