8 ms·
John Ousterhout: My favorite sayings
- tejinderss 8y agoHis book a philosophy of software design is an excellent read.
- tenaciousDaniel 8y agoMy co-worker recommended this book to me a few hours ago and I had never heard of the guy. I just listened to a talk of his at Google and he seems super smart.
- chubot 8y agoLink: https://www.amazon.com/Philosophy-Software-Design-John-Ousterhout/dp/1732102201 https://www.amazon.com/Philosophy-Software-Design-John-Ouste... Looks like it was just released!
- davidw 8y agoSalvatore 'antirez' seems to think pretty highly of the book too; got a copy on his recommendation and am just starting to read it.
- chubot 8y agoFor those who haven't seen it: http://antirez.com/articoli/tclmisunderstood.html http://antirez.com/articoli/tclmisunderstood.html (Ousterhout is the creator of Tcl and both antirez and Richard Hipp of sqlite are Tcl programmers)
- solidist 8y agoYes. So much so that I wrote a short on it stacking it up there with other timeless books. https://hackernoon.com/meta-skills-of-a-software-engineer-bed411f6685e https://hackernoon.com/meta-skills-of-a-software-engineer-be... For those who unfamiliar, the book is based on evidence observations of student groups builindg large systems and then reviewing and discussing complexity sources -- then they swap their systems with other groups. They then need to keep iterating... usually hitting problems that we find in the wild. The book is the result of his observations. The thing I would recommend John do next in his Stanford course is to encourage the students to infuse testing apporaches to the systems they build. This could reveal even more value of the craft in a setting that is somewhat controlled.
- MFogleman 8y agoThe three most powerful words for building credibility are "I don't know" I had a supervisor once who always had an answer to your question. He was always 100% sure he was right. He was not always right. Consequently, going to him for help would sometimes result in the problem becoming worse. The best supervisor I ever had was the one who routinely told me "I don't know, let me call {PersonInOtherDepartment}" or "See if the answer is in {RelevantManual} under {PossibleSection}. If you don't find it, give me a call." We treat "I don't know" as an admission of failure far too often. It should be seen as an entry point to improvement.
- csours 8y agoI had 2 team leads at one point - One of them would ALWAYS answer your question, and the other would sometimes say "I don't know/I have to research that/Let's look it up" They both had the right answer about 95% of the time, but the one who said "I don't know" was only wrong about 1% of the time.
- emmelaich 8y agoI'm always ready to say I don't know. But just to advocate for the opposite -- it is perfectly OK to have an clear opinion, weakly held. So, say what you think but at the same time ask (demand?) an argument or discussion. A friend has a T-shirt with the words: Always sure, often wrong. Also see: https://www.psychologytoday.com/us/blog/work-matters/201002/strong-opinions-weakly-held-wisdom-the-courage-act-your-knowledge-and-the https://www.psychologytoday.com/us/blog/work-matters/201002/...
- KKKKkkkk1 8y agoIn my experience, saying "I don't know" outside of an academic environment leads to two consequences: 1) People will stop listening to you in preference to loud people who "know"; 2) Loud people who know will use your admission against you. Sadly, the good habits that you learn in academia will come back to haunt you when you move into industry.
- schizoidboy 8y agoI doubt there are statistics on such things, so we'll have to deal in anecdotes, and I've had the total opposite experience (I make this comment so that any young people or academics aren't prematurely jaded). When a lot is at stake (e.g. high revenue, medicine, infrastructure, etc.), especially when a team has been burned by loud people, a person who says, "I don't know, but let's figure it out" (that's my job) is prized.
- asdfman123 8y agoI took a class from John Ousterhout. Great guy. However, file this under "too honest": > For example, a few years ago I started working on my first large Web application I've spent most of my career learning the do's and don'ts of building large web applications... I assumed Professor Ousterhout had more experience in this sort of thing than I do!
- deleted 8y ago[deleted]
- brlewis 8y agoSounds like excellent timing to me. I've been building web apps since 1994. If he wrote this in 2017, then tools for building large web applications had just started getting good.
- wenc 8y agoSide note: Ousterhout was famous for being the author of Tcl/Tk, which was a popular language and GUI toolkit in the early days of Linux (before Qt and GTK came along). I wouldn't be surprised if many older Unixes are still running Tcl/Tk apps.
- deleted 8y ago[deleted]
- rabidrat 8y agoThe main configuration language of F5 BIGIP (load balancers) is TCL.
- patrickg_zill 8y agoAOL's web properties were heavily dependent on Naviserver with its embedded Tcl interpreter, which they bought cheap and turned into AOLserver. The Vienna based university, TU-Wien, still runs AOLserver and serves 40K users with it. OpenACS.org and dotLRN.org still use the same Tcl-based webserver today. Gustaf Neumann shepherded the development of the use of OpenACS/dotLRN at TU-Wien, I think: http://nm.wu.ac.at/nm/neumann http://nm.wu.ac.at/nm/neumann
- gnachman 8y agoAOLserver was my first job out of college. Glad someone remembers it!
- patrickg_zill 8y agoI have customers that are still using it!
- keypusher 8y agoHis "projects" page also lists "Log Structured File Systems" (which inspired LSM used by many databases) and Raft (the consensus protocol) as things he made significant contributions to.
- severine 8y agoThanks for posting! The Projects page is a great read too: http://web.stanford.edu/~ouster/cgi-bin/projects.php http://web.stanford.edu/~ouster/cgi-bin/projects.php
- h4b4n3r0 8y ago>> If you don't know what the problem was, you haven't fixed it There’s a more pithy variant of this, which I use all the time: “You can’t fix what you don’t understand”.
- melling 8y agoUnder his Odds and Ends, there’s a link where he discusses his RSI. He has been dealing with it for over 20 years. http://web.stanford.edu/~ouster/cgi-bin/wrist.php http://web.stanford.edu/~ouster/cgi-bin/wrist.php
- l33tbro 8y ago>The three most powerful words for building credibility are "I don't know" I agree with this until you come across colleagues with the Jobsian 'reality distortion field'. Or even the social dynamics at play with the orange man that lives in the big white house. We absolutely assign credibility to people with integrity and self-awareness. But, unfortunately, we also seem to have a capacity to be charisma vultures and will happily believe someone's bullshit if they are making us feel good in the present moment.
- Normal_gaussian 8y agoOne of the ways to deal with this is to provide a positive assertion that includes the asker - "we shall need to work it out". "I don't know" is negative, reflects solely on yourself, and provides no path forwards.
- DubiousPusher 8y ago>> The most important component of evolution is death I appreciate the concept. And this has the fun of sounding morbid. But this is a bit like saying the most imoprant part of an ICE is a piston which is silly because a piston needs a confined space and a good fuel to operate. It doesn't work without all three (and more). In this case a mechanism of genetic change is equally (or more important in a way) to evolution than death. Death is obviously very important though.
- andrepd 8y ago>Programmers tend to worry too much and too soon about performance. Many college-level Computer Science classes focus on fancy algorithms to improve performance, but in real life performance rarely matters. Stopped reading there. A great plague of modern software development is a complete disregard for performance or resource conservation.
- needlepont 8y agoPerformance _or_ resource conservation. Which one is it? Application design and domain knowledge are more important than rote optimization. I think that is what Ousterhout is getting at.
- dcuthbertson 8y agoI agree with you. I've worked on drivers for virtual NICs. Every performance boost was well received by customers
- remoteorbust 8y agoIn case you didn't know the author has built the programming language that formed the backbone of some of the original multithreaded web servers that reached an incredible scale for their time. He is currently involved in research on "core aware thread management", "nanosecond-scale logging". This causes me to interpret statements like "Programmers tend to worry too much and too soon about performance." more charitably. I think he does care about real performance.
- froderick 8y ago> too much and too soon That's the critical part of that statement. It is not important to solve for performance concerns until the code actually works so you can verify you've solved the problem at hand.
- jccooper 8y agoThe problem is not this advice, but that people tend to stop reading (or remembering) there. It's misapplied or misunderstood so often that I wonder if it shouldn't be promulgated. Today something like this may be more appropriate: "You should pay attention to performance, but your algorithms probably won't be the problem. It's more likely you're doing something stupid or wasteful, probably with the help of your technology stack."
- KasianFranks 8y agoJohn is the reason why I use Tcl to this day. Good times back at Sun Labs.
- naveen99 8y ago> The greatest performance improvement of all is when a system goes from not-working to working Except when speed is part of the definition of working. For example deep learning. The correct implementation was not enough until the hardware was fast enough.
- mmt 8y ago> The correct implementation was not enough until the hardware was fast enough. This doesn't refute his argument, which I read as being, essentially, against performance optimization of software during initial construction. Knuth famously bemoaned premature optimizations, as well.
- dwaltrip 8y agoSpeed isn't in the definition of "working" for deep learning. Speed is an implementation detail. Perhaps a very critical one, but still an implementation detail. One can evaluate the success of a deep learning program (e.g. "is it working?") without knowing how much processing power it used.
- weinzierl 8y agoMy favorite saying form John Ousterhout: > What's Wrong With Threads? > Too hard for most programmers to use. > Even for experts, development is painful. I read the slides for his presentation "Why Threads Are A Bad Idea (for most purposes)" [1] in the late 90s and it saved me from a lot of confusion in the following decades. This was especially helpful in a time when Java peaked in popularity and people were like: "Hey, threads are cheap and easy now, what's the problem when our solution uses thousands of them?". [1] https://web.stanford.edu/~ouster/cgi-bin/papers/threads.pdf https://web.stanford.edu/~ouster/cgi-bin/papers/threads.pdf
- type0 8y agoThe take home message here should be: > There are 2 kinds of software in the world: software that starts out crappy and eventually becomes great, and software that starts out crappy and stays that way.
- renox 8y agoI'm surprised it doesnt talk about failures IMHO the most important thing is having a sane architecture which can deal with failures (like Chrome vs old Firefox) or Arcan https://arcan-fe.com/2017/12/24/crash-resilient-wayland-compositing/ https://arcan-fe.com/2017/12/24/crash-resilient-wayland-comp... vs Gnome/KDE compositor..
- srean 8y agoThank you for the link. Very nice read.