Can Great Programmers Be Taught? - John Ousterhout - Agile LnL

People have been programming computers for more than 80 years, but there is little agreement on how to design software or even what a good design looks like. As a community, we talk a lot about tools and processes, but hardly at all about design. In this talk I will describe my recent work to identify and communicate a set of software design principles, including a new software design course at Stanford that is taught more like an English writing seminar than a traditional programming class, and a book on software design, which is based on the concepts from the class. I will also present a few of the design principles, such as "classes should be deep" and "define errors out of existence."

[@CuriousCyclist]

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

[@ArielLorusso]

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

[@chieeyeoh6204]

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.

[@ansidhe]

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

[@lycantropos]

on the contrary, truly beautiful code is not universal but specialized & concise: it does only things that are truly necessary, as it was put by Antoine de Saint-Exupery: "Perfection is not achieved when there is nothing left to add, but when there is nothing left to take away" generalization only brings complexity which in most cases is not needed and harmful for readability & maintenance

[@Honken]

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!

[@handsanitizer2457]

Wow im so happy this popped up in my feed.

[@TreeLuvBurdpu]

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.

[@teeletsetse445]

Perhaps they don't like the message: the student can learn and if they are not learning then there's something wrong with your teaching. To be fair, every profession tries to avoid liability to some extent.

[@TreeLuvBurdpu]

@@teeletsetse445 it's like avoiding liability by totally invalidating your whole profession

[@teeletsetse445]

@@TreeLuvBurdpu Yes.😂

[@cyrusol]

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.

[@Appleslaryer]

When reaching for a tool if there are 5-10 other tools in front of you it's difficult to choose. Something like buffered I/O in my opinion is beyond the comprehension of newer developers especially. Not because they are dumb but because it's mostly unrelated to what they are actually trying to do. There might be a correct way to do it in one call but if there are 5 options the chances that people pick the right one could be limited to as high as 1/5, experience well help them pick with higher accuracy but newer programmers don't have that skill. I think the Unix API is a great example to there is one additional method ioctl which is not shared. It's the worse call name ever and can be extraordinary confusing to use but it allows every bit of customization out of the 95% common cases. I get your point that the glue code was lacking but the OP is saying the glue or interface is what was lacking i.e you are saying the same thing

[@bjornnordquist1616]

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.

[@orterves]

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.

[@AgileLnL]

So avoiding special cases by making the happy case the only case?

[@8Trails50]

@@AgileLnL dont think they meant avoid special cases, but rather early return on special cases with if conditions, flags etc But the function should mostly be designed around the happy path

[@CorbinSimpson]

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.

[@D4no00]

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.

[@egemensentin]

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.

[@hoots187]

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.

[@johndoe9608]

maybe that's exactly why you never heard of a company failing that didn't scale fast enough. when they failed it didn't make any noise?

[@ForgottenKnight1]

I don't think this is the correct usage of XP. You might want to review your hiring practices because pair programming is done for other objectives.

[@grokitall]

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

[@TheDmviper]

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

[@undergroundbodega9766]

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

[@grokitall]

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.

[@megetmorsomt]

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

[@KANJICODER]

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

[@TheDmviper]

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

[@ChrisAthanas]

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

[@aslkdjfzxcv9779]

great talk. ty.

[@Funzelwicht]

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.

[@ValentineOficial]

I think the word you might be looking for is "complication"

[@varshneydevansh]

Amazing talk

[@nitsanbh]

This is a really good video

[@ryan_roga]

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.

[@ForgottenKnight1]

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.

[@principleshipcoleoid8095]

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

[@merlingrim2843]

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

[@clumsyjester459]

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.

[@AgileLnL]

I think you are right. We can have an ideal state, but if the chances are high that in trying to hit the ideal state we make something that is worse than a slightly less than ideal state we might sometimes be better with the safer less ideal approach.

[@merlingrim2843]

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.

[@fennecbesixdouze1794]

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

[@kasozivincent8685]

I think the most important concept in CS is abstractions

[@jma42]

CS is about solving problems, not hiding complexity

[@kasozivincent8685]

@@jma42 how do you solve complex problems without creating layers of simplifications? My POV is that you are being fooled by front end frameworks like React, Vue and Angular. Most of the youth like you think CS is web development.

[@remcogreve7982]

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.

[@llothar68]

Just that Turing completeness doesn't mean anything in real life. No computer is Turing complete because it always has finite memory. It's just as nice as the big bang theory and Stephen Hawkins ideas of black holes and maybe as false.

[@remcogreve7982]

@@llothar68 For example any time you want to do something with your code like optimize it or check if it is correct you have to consider it. You can never think of an algorithm that takes you to the optimal result it is always going to be an approximation whatever the computer power you have.

[@user1739-y5c]

⁠@@remcogreve7982perhaps you’re responding to the term ‘computer science’ when the speaker should have used ‘software engineering’. Llothar is just responding to the spirit of the talk.

[@deluksic]

Debug the system into existence 😂 40:32

[@justinstorm]

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.

[@WayOfTheCode]

I keep finding KZbin gold

[@DanielJoyce]

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.

[@microcolonel]

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

[@dragonmax2000]

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.

[@grokitall]

you have missed the point. he is not saying that you should not learn good design, he is saying that the big upfront design model might work well when operating in well trodden paths, but in software that is not where we live, and every big software failure tried it and did not abandon it quickly enough. data from successful projects shows that between 40 and 60 percent of the specifications are not only unknown at the start, but are usually unknowable at the start, hence the move to incremental evolutionary design instead.

[@dragonmax2000]

@@grokitall Sure, evolutionary design is the way to go and, in fact, the only viable way to go. I still think paper design is foundational to any good project, before you write a single line of code. It has proven to be the case for me and my teams. So many times I've stopped bad ideas and $$$$ from even taking place by simply asking to at least document it or talk it through.

[@grokitall]

@@dragonmax2000 sure you need to document your design decisions, and referring back to them is a necessary part of good design, but how do you take into account the unknowable stuff to create the upfront design in the first place that you seem to be advocating?

[@idesel]

​@@grokitallI really don't think he means he will only start coding whem he is 100% sure he has 100% of the system on paper. I really don't understand what's the confusion you having with the op saying it's good to have a design on paper first or conceptualized it on your head before rushing to write code.

[@TaiChor5Gates]

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