This video appeared in my feed and I'm so glad it did. Great video and great channel!

00:52 Most important concepr in computer science 02:01 Problem decomposition 04:28 Everyone can do it 08:18 How we teach it? 11:15 Secrets to be a great Programmer (sumary od the philosopy) 14:53 Clases should be deep 17:04 Example what not to do 18:49 Java's illlnes classitis 23:57 Unix File I/O as good example 25:45 How to design a new Class ? 27:30 Why general porpouse ? 28:05 An example 30:34 General porpouse Aproach 33:53 Tactical vs Stategic mindset 36:55 Why strategic is best ? 40:56 How much to invest 45:00 Small investments 49:17 Is the course working 52:00 Phylosophy of software - Harvard CS190 Boock 53:15 Conclusion 55:30 Question 1 57:09 Answer 1 1:00:40 Question 2 1:01:10 Answer 2 1:01:40 End and farewell

I think the idea of changing the student's project and add new to it is an amazing idea. Like it or not, this is what we software engineer do most of the time. We either create the mess or clean the mess of others. I think this kind of exercise will help the student to be more aware the next time they create shitty code.

Wow im so happy this popped up in my feed.

I clicked this in anticipation to disagree with pretty much everything. To my surprise, John's observations and recommendations were on point and seem to be based on actual, hands-on experience. Wonderful talk, bravo!

The really beautiful code is like an elegant mathematical proof - all polished and universal when you look at it top-down and gracefully collapsing to all edge cases when you analyse it in detail. Like a perfect clockwork ! 🤩😅

35:00 - One shortcut here, one shortcut there and soon enough your codebase is a mess and you're screwed 53:00 - when you can't scale, write books, create courses, etc.

So, if composition is the most important thing, then why is there no discussion of category theory? I feel like there's a serious disconnect between the aphoristic introduction and the entire rest of the talk; there was an abrupt switch from computer science to software engineering. This is especially surprising because I would have said that the most important concept is functorality, which is not something easily recognizable without an introduction to categories.

22:55 This supposedly being an example of "too many, too tiny classes adding complexity" is a fallacy. The fact that nowadays one CAN create a BufferedInputStream directly in one call is exactly what resolves the issue. Many thin classes is not the problem. The problem was a lack of "glue code" to glue it together. It is a perfectly valid, fantastic even, approach to keep responsibilities small, to have classes that make up the external API of a library use more and more classes internally. It is good for maintainability, extensibility, testability and ease of understanding each part individually. The solution was precisely NOT to just cram everything into 1 "deep" class. I suspect the root cause of this fallacious belief is that 99% of programmers still think in terms of how computers operate, procedurally. Not in terms of composable objects. Even if they write Java, C++ etc. Real OOP is very declarative and hardly distinguishable from FP.

Amazing talk

Hi! Really enjoying the video and the approach! Thank you for sharing your experiences and insights. One thing about the size of the classes for me thinking and that's considering each class as separate, while sometimes the value of all all small pieces combined may be bigger than a simple sum. What do I mean by that? I have a large C struct and created a getter and setter function for each variable in the struct. While sometimes it is more easy to simply get the current state of a variable by not using the getter function, in other cases it adds a lot of value due to the complexity hidden behind the getter function. Now, the user doesn't need to think about this important detail anymore. Anytime you want a value you just get_struct_variable(struct) and it always works. I hope a similar explanation is not coming later in the video while I am still watching.

@13:00 : I think the benefit of this method is you can quickly search for all places where you are doing this logic without having to write a regex . Typically something like this should be a macro , but this looks like Java or C# which does not have macros .

great talk. ty.

This is a really good video

What he’s advocating for cannot be done optimally at universities. Universities are not vocational schools. Universities do not and should not teach you to become a practitioner, they should teach the fundamentals the practice is built upon. They should not, because they cannot, thus should not teach how to do code reviews. They teach you how to debate, elucidate, disambiguate - communicate. But since Stanford was founded originally as a vocational school serving the industry du jour of Palo Alto and thereabouts, the history keeps rhyming. Everything that makes a good programmer can only be properly taught in situ, in a master/apprentice relationship. Any other alternative is doomed to fail. However, programming, as it is currently practiced, happens to be an endeavour that does not value wisdom and has a raging problem of ageism. This is not conducive for an apprenticeship culture to take hold, and the whole practice of programming suffers as a result.

The topic covers some interesting topics, mainly about the bad things that come with defensive programming, but sadly this course is only as good as the vision of the author. If we talk about removing complexity from the design, what can be simpler than having pure functions, data structures and managed side effects? People use the OOP as a silver bullet to throw at their problems, praying that it will work, making all these theories (classes should be deep) not based on any practical facts and fighting with each other when someone doesn't agree. I watched a few videos of Uncle Bob and he is not a experienced developer but a cult leader. The key to simplicity is actually limiting the tools the designer has access to, and make the ones left very good. I have at least 3 years in both writing in OOP languages and functional languages and I can tell you that designing, managing and reading a codebase written in a functional language is 100 times eaiser, because these languages actually constrain you very hard on what you can do: no mutations, functions without side-effects, no classes and the other abomination following this such as inheritance. You can open a file randomly and read a function and understand what it does, it receives data, transforms it and returns new data, good luck doing that with classes, especially if they do side effects too, and don't start me on concurrency and how bad it is implemented in OOP languages.

i have seen your graph before with data to back it up. in the state of devops report by jez humble and others they look at what makes teams move fast. they found that writing code with lots of test in small chunks makes the biggest difference. this is basically continuous integration. more importantly, when they looked at the worst performing teams, they discovered that the code chunks were bigger, harder to understand, buggier due to the relatively fewer tests, and individual changes took longer due to high levels of technical debt. they do this report annually, and wrote about it in the book accelerate. ,

Like everyone else on KZfaq, this guy rambles about himself and I swear to God for 15 minutes then he finally start this time

Most important concept in computer science: naming phenomena...

I've read "Talent is Overrated" and "The Talent Code" and "Peak: The New science of expertise" and i think they're all great books with entirely novel ideas. I'm surprised particularly about how many TEACHERS, who entire profession is dedicated to overcoming the concept of "natural talent" oppose the ideas in those groundbreaking and optimistic new sciences of instruction.

This is a great adjunct to the work in OOP by Yegor Bugayenko He has a YT channel

the issue pointed out about communicating how to be good at what you do has a two part answer. when you go to college your goal is to communicate to the tutor that you have understood as much of the information presented to you to someone who already understands it. this only gets worse when you make academia your career. this is a completely different skill from communicating one or two points clearly someone who does not know it. bad as this is, it pales in comparison to the problem that knowing how to do a job is a completely different skill to knowing how to teach someone else how to do the job. that is why apprentiships came into being in the first place, because then you only have to deal with one of these hard problems at once.

The most important part of CS is correctness and performance (speed). If it doesn't work it's useless. And if it doesn't work until everyone is dead it's also useless. Abstraction, Problem Decomposition, etc... are all (at best) second order goals

Teams of two is exactly how we hire: both people are responsible to each other. Its much harder for someone not to be pulling their weight when paired with someone they recommend to work with. Yes this hiring practice does not scale, but I have never heard of a company failing because they didnt scale fast enough.

29:40 I think what you're describing is something akin to cleaning up expressions in algebra where you combine like terms and factor out pieces so you can turn something like "3x -x^2 +5 +2x^2 -x -4" into "(x+1)^2". It's still "specialized", you aren't talking about some general polynomial a_0*x^0 + a_1*x^1 + ... and the added complexity of handling the general case, you've just simplified what the specific thing you had. You could even make an aesthetic decision as to whether x^2 + 2x + 1 or (x+1)^2 was better. This would be like deciding whether insert/delete is a better basis for text editing than replace(start, end, text). In that sense, the goal is actually to start with the specialized case, and rather than generalize you "simplify".

The amount of code expected in 3 weeks seems very, very low. Am I just a good programmer if I can put together 3-5x more than that in 3 weeks? Assuming what I'm writing is readable, logical, practical, etc., of course.

I think I read somewhere that Linux embraces the "avoid special cases" approach to design, such that algorithms should operate cleanly over all cases rather than handling the 'happy case' primarily and adding checks and special code for the others. I think there's also a hint of the single responsibility principle here, and that classes should be designed to exist within their own very well defined interface and data structure boundary.

Not only are low skill developers less productive, they create code which requires skilled developers to refactor or completely redo.

@2:50 I think the SICP book teaches this.

35:33 well doing a quick tactical prototype to figure out a better strategic plan can be a useful approach

Great one! I only find it confusing that in english "complex" and "conplicated" have as noun "complexity" although there are not the same. And here, the difference is crucial.

So for what it’s worth, I require my engineers apply S.O.L.I.D. design principles as part of development and code reviews.

I think the most important concept in CS is abstractions

I think that "deep classes" are good in principle, but they can really hurt you if the abstraction of their API fails in one edge case and you suddenly have to start debugging them. All this complexity that you have been shielded from will suddenly become a nightmare. Just being "deep" alone is not enough. The implementation of all this functionality also has to be solid. Yes, it's just the ugly wiring behind your shiny facade, but someday somebody will have to untangle that and understand it, because your facade was only 99% perfect.

Debug the system into existence 😂 40:32

Ready with the video right after the start. The most important concept in computer science is computability you know what Allan Turing was all about. If they get that so wrong why bother with the video for the rest.

I keep finding KZfaq gold

I'm on the edge with this video. You must learn how to write a design on paper before you write a single line of code. UML is a great tool for such. I think professor needs to learn a bit of "paper" design. Abstraction and composition. Go through design patterns and then compose software in your head. Good thoughts but not confident that I would take his course. Though it would likely be a good learning exercise.

The answer is no, in case anyone was wondering. Thanks Betteridge.

The posix I/O system is a terrible design. I know he celebrates it, but it literally is a shallow interface. Sure tou have read and write, open and close. But those methods giarantee the bare minimum and to get anytjjg done robustly you need to rewd theouhh tons of documents snd figure out which other ioctls/syscalls/fns you should call to do things robustly or with timeouts, etc. Its like 13 layers of cruft.

Don't think it's wise to isolate 'tactical programmers' as bad. If 10% is a wake of destruction what's the 90% they got right. The solution can always be refactored, at least you'd have one.

his uncle Bob's reference is misleading at best at worst deliberately misrepresented.... In no shape or form Uncle Bob's advice on smaller method has any bearing on creation of classes... Uncle Bob doesn't advice creating new classes due to method sizes... he advocates creating new classes when your class is doing too many things, and it has NOTHING to do with method sizes...