
John Ousterhout: My favorite sayings - blacksqr
http://web.stanford.edu/~ouster/cgi-bin/sayings.php
======
MFogleman

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

~~~
KKKKkkkk1
In 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
I 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.

~~~
dionidium
This is also my experience. I've heard the claims in this thread (i.e. that
people who pretend to know things get ahead, while those who admit that they
don't know stuff are never trusted) my entire life, but I've always thought,
"who are these people talking about?"

Whenever I've worked with a blowhard who couldn't admit when they didn't know
something literally _everybody_ smart thought of them as a blowhard who
couldn't admit when they didn't know something.

~~~
type0
> literally _everybody_ smart ...

Too bad this excludes so many managers, but really this is so much a company
culture issue than anything. So to cite from the article: "very few companies
are capable of making significant changes in their culture or business model,
so it is good for companies eventually to go out of business, thereby opening
space for better companies in the future."

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

~~~
patrickg_zill
AOL'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
AOLserver was my first job out of college. Glad someone remembers it!

~~~
patrickg_zill
I have customers that are still using it!

------
weinzierl
My 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)

------
renox
I'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-
comp...](https://arcan-fe.com/2017/12/24/crash-resilient-wayland-compositing/)
vs Gnome/KDE compositor..

~~~
srean
Thank you for the link. Very nice read.

------
tejinderss
His book a philosophy of software design is an excellent read.

~~~
chubot
Link: [https://www.amazon.com/Philosophy-Software-Design-John-
Ouste...](https://www.amazon.com/Philosophy-Software-Design-John-
Ousterhout/dp/1732102201)

Looks like it was just released!

~~~
davidw
Salvatore 'antirez' seems to think pretty highly of the book too; got a copy
on his recommendation and am just starting to read it.

~~~
chubot
For 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)

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

~~~
brlewis
Sounds 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.

------
melling
Under 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)

------
severine
Thanks 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)

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

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

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

------
KasianFranks
John is the reason why I use Tcl to this day. Good times back at Sun Labs.

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

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

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

~~~
mlevental
why do people post this kind of stuff "stopped reading right ....". congrats
now we all know you're too arrogant and too impatient to finish a 1000 word
essay. don't you realize that dismissing the bulk of the text based on just
one comment is ignorant? do you think it matters to anyone what you even think
relative to this person? do you think you have some deep insight that others
don't (such that they don't already realize that that particular point should
be contextualized appropriately). I just don't understand people constantly
trying to assert their delusional superiority at every vague opportunity - let
me kindly inform you that op posting this wasn't an invitation.

~~~
JoshCole
Worth noting that probabilistic reasoning via approximations are actually
pretty cool. Its just that the same sort of thing that makes them great is
also a thing which makes them terrible. The upside of not being thorough is
being fast and the downside in being fast is not being through.

I find it neat that the person arguing for speed is employing heuristics which
short circuit reading.

A great way to look at human biases is through the lens of the good they
cause. It makes them all make sense in a way that looking at them through the
lens of failure cases doesn't. The world is awe inspiring in its complexity
and coping with that efficiently and in real time requires trade offs. Catch
the same person who appears delusional in one real-time context at a time
wherein they can think for longer and their thinking can become much more
logical and mathematical.

