
Levels of Excellence - martian
http://johncarlosbaez.wordpress.com/2013/09/29/levels-of-excellence/
======
basicallydan
Nice article. One part in particular stood out to me:

> 7) The best swimmers don’t spend a lot of time dreaming about big goals like
> winning the Olympics. They concentrate on “small wins”: clearly defined
> minor achievements that can be rather easily done, but produce real effects.

Recently, I've found my own attitude changing towards focusing on the smaller
wins, too, and found myself both happier and more successful in the work that
I do. When you're putting together a large puzzle, it's quite difficult to
think of it as a picture which is made up of hundreds of little pieces. It's
easier to focus on a few large, more manageable chunks of the puzzle, each of
which is made up of several small pieces rather than hundreds. This can be
applied to many types of challenge.

This isn't new advice, but it's an important reminder not to let the bigger
picture cloud your view if you're trying to achieve something.

~~~
nyrina
But my boss keeps telling me to go look down from the helicopter, like it's
some magical answer.

"Hey, iPads aren't showing some of our websites at all, I've tracked it down
to IIS, I think, as every time I recycle the app pool, it shows our website
perfectly, but then fucks up every time you refresh it after that."

"Ohh, that's easy, just look at the bigger picture, take a trip in the
helicopter and look down"

Argh!

~~~
unlikelymordant
your boss sounds like he is at least 2 levels higher than you :p

~~~
ansimionescu
Pointy-haired boss is so yesterday. I vote for [10] boss
[http://i.imgur.com/uKcUCHd.png](http://i.imgur.com/uKcUCHd.png)

------
hawkharris
This conclusion from the linked-to study [0] resonated with me as a
programmer: "Excellence is a qualitative phenomenon. Doing more does not equal
doing better." And in another section: "Excellence is mundane. [It] is
accomplished through the doing of actions, ordinary in themselves, performed
consistently and carefully, compounded together..."

Programming can be a solitary practice. Even if you're working with a team and
using GitHub, there's a lot of quiet, introspective time, during which you
draw on your own skills and judgement to make small decisions about code.

Because of this autonomy, it's easy to revert to the programming languages,
frameworks and workflow that you find most familiar. Many programmers answer
to managers who are outcome-oriented; they tend to care more about the end
result than the minute technical decisions made along the way.

But minute decisions, whether they concern optimization or design patterns or
frameworks, are compounded. Taken as a whole, they can affect the look, feel
and performance of a software product.

For this reason, I'm inspired by the swimmer's commitment to slow, persistent
improvement — approaching small decisions deliberately and thoughtfully, with
the realization that they add up over time.

I think the take-away for programmers is that we should focus not only on the
quantity of problems solved ("Show HN: I made 101 apps this year!"), but on
approaching small decisions with a fresh, qualitative perspective ("I tried
switching up my workflow and experimenting with new techniques").

[0]: [http://www.lillyfellows.org/Portals/0/Chambliss-
Mundanity%20...](http://www.lillyfellows.org/Portals/0/Chambliss-
Mundanity%20of%20Excellence.pdf)

~~~
noelherrick
You're right about focusing on quality over quantity, but if someone builds
101 apps in a year and uses each app to hone skills and improve methods, it's
a great way of doing exactly that. You have to practice, even if you want to
stay on the same level. The people who level up use practice to learn the best
way of doing something.

------
JackMorgan
I'm reminded of pg's essay on the power continuum of languages.
[http://paulgraham.com/avg.html](http://paulgraham.com/avg.html)

The power continuum of the developers wielding those languages isn't mentioned
as much, but clearly is an important issue. I've worked in blub languages with
developers who are so many levels above me they are not even speaking the same
language anymore. The problems they are trying to solve take for granted all I
know, all I struggle with, and all I still haven't even learned yet.

The more I "level up" in development, the more I'm convinced there is not
enough attention paid to how to really advance through those levels. Right now
I'm three languages into "Teach Yourself Programming in Ten Years",
[http://norvig.com/21-days.html](http://norvig.com/21-days.html) but what
about after that? And that is just one man's brief and not well-explained
suggestions.

I'd love to see other developer's suggestions for how they advanced past that.

The biggest issue though is it's almost impossible to know your skill relative
to the rest of the development world. We can't just time ourselves writing a
script, like in the olympics, so almost all of us have a hugely overinflated
or underinflated sense of our own skill. Everyone has hundreds of anecdotes
proving their value over those who by any metric would be our betters (years
of experience, languages mastered, formal education, etc).

I'm reminded of when I was a brand new developer in my first job, how pleased
with myself I was at my commit messages, compared to my officemate. Sure, he
worked on patching a financial aid system written in three languages, two of
which I'd never even seen, and I only wrote sql queries to be run by hand, but
I knew what made me better: commit messages.

This confirmation bias is one reason I like pair programming, especially
between two partners of different levels. Suddenly the lower gets to be faced
with someone who gets done ask the same things and avoids this problem and
that problem. They see their relative place, and can aspire for levels
greater, which before would never have occurred to them even existed.

~~~
arthurjj
"The more I "level up" in development, the more I'm convinced there is not
enough attention paid to how to really advance through those levels."

This for me is the major takeaway from the article. Trying to learn material 2
levels up is unhelpful. It's especially bad since most of us are used to
formal schooling where level progression is determined for you

~~~
inetsee
This is one of the fundamental ideas behind deliberate practice. You need to
work right at the edge of your experience level. If you continue to work well
inside your comfort level, you won't push your expertise out into new areas.
If you try to move too far outside your expertise too fast, you won't have the
foundation to support yourself; you'll flounder and get discouraged.

~~~
freehunter
I've been constantly looking for that progression. I'm a very poor programmer,
but I would love to get better. I know C, C++, C#, Python, Java, Bash, and Lua
all at a basic level just from having been introduced to them in classes or at
work, but I've never found a good path to take one of them and become good at
it. I've tried books and tutorials, but I can't find a progression of "Read
this book, then this book, then this book, then watch this Youtube series." I
can't figure out how to actually write programs once I've finished the first
class, the first book, the first tutorial. I feel like the second book that
people recommend to me is always two levels above me and makes no sense at
all. Especially when people recommend the programming practice sites where the
problems are all about solving math puzzles. I'm not that good at math,
either.

I really wish that every profession came with a tutorial (outside of a four-
year college program) saying "here's exactly what you need to learn, in exact
order, to get started."

~~~
blinduck
Completely anecdotal, YMMV.

I've found I don't really level up by reading books or tutorials.

I level up when I actually do a project by myself from start to end. For the
projects I do, there tend to be parts I know and parts I don't, so I still
Google for the relevant bits and pieces that I don't understand.

So I guess keep working on projects that have parts you don't understand.
There also need to be parts that you do understand, so that you don't feel
like you're jumping in at the deep end.

On a side note, I'm not knocking reading books. They help me become aware of
certain ideas, but I don't learn them completely until I've implemented it
myself.

~~~
dkersten
I agree - I've read a ton of books, but usually only take small nuggets of
knowledge from them and end up having to reread them every few years. Instead,
most of what I know about programming I gained by doing. Writing a lot of code
levels you up, not reading about writing code.

I find reading books, articles, tutorials is a great way of finding out what
you don't know and what you might want to try tinkering with next to level up,
because otherwise you just use the same techniques over and over, but to
actually level up you need to get down and dirty and write a lot of code.

~~~
JackMorgan
I used to get little value out of books, then I started reading better books.
Check out this Amazon list for some high quality books. Don't let the
"Clojure" theme scare you, these will make you a better programmer in any
language.

[http://www.amazon.com/Clojure-
Bookshelf/lm/R3LG3ZBZS4GCTH](http://www.amazon.com/Clojure-
Bookshelf/lm/R3LG3ZBZS4GCTH)

~~~
dkersten
_Don 't let the "Clojure" theme scare you_

Actually, I use Clojure quite a bit, so that won't scare me at all!

I've already got Programming Clojure (and The Joy of Clojure - not on the
list), Structure & Interpretation of Computer Programs and Concepts,
Techniques and Models of Computer Programming. Purely Functional Data
Structures and How to Solve it have been on my list for a long time too. Some
other books that I haven't heard of before on that list look very interesting
though!

I didn't really mean that I don't get value from books - I do - just that I
find books to be only the first stage of learning and most useful in telling
me what it is I don't know, which I then can study and try for myself and its
the experimentation and tinkering that actually makes it sink in.

------
thelogos
Even though this article is about math. It reminds me of my chemistry
education.

1st year, you only learn about the basic concepts of general chemistry. For
most science and engineering majors, this is the only time that they'll be
exposed to chemistry.

2nd year, you learn about organic chemistry. It is only at this point that you
start to catch a glimpse of what chemistry is really about. It forces you to
really understand electrons and how they behave in reactions and as part of a
structure.

This is where many pre-med, and chemistry students hit the wall and decide to
change their major. Those that do survive through it with actual understanding
instead of rote memorization can now look at chemical structures and reactions
and know the exact number of electrons, charges and understand the flow like
2nd nature.

Then comes quantitative analysis and physical chemistry. Now you're really
forced to understand and analyze the external enviroment and the myriad of
physical conditions because reactions rarely take place in ideal isolation.

Next comes biochemistry, and it finally dawns on you that living beings are
nothing more than complex machines put together by chemistry. Extremely
complex machines, but still machine nonetheless.

I had a sort of existential crisis after being through biochemistry. But with
that knowledge, it is now possible to read neuroscience text and catch a small
glimpse of meaning.

Then finally, we come to advanced organic reaction mechanism. A course that is
only offered every other year at my uni, taught by a guy older than Gandalf
and Dumbledore put together.

Total # of people in that class? 3.

Now, we go deep, to the darkest pit of insanity. You realize that everything
before was only a small preparation. Minding-bending subjects like orbital
theory which makes no intuitive sense. The worse part was the professor and
the book offered no consolation.

"Learn to deal with it." "It is the best model that we have at the moment."
"It just works." They say.

------
wslh
I think the answer is: infinite levels and it works like a fractal. Let me
explain:

i) Your father teaches you how to play chess, because he just know the rules.
Then you beat your father because of some simple chess tricks and can see two
moves ahead.

ii) You play chess in your school, work hard and at the end of the year are
the best there. You are a genius!

iii) Then move to regional contests and things start to sound different and
the level of skills required is high.

iv) Fastforward a few years and you are the national champion. A genius^3!.
Moving to the international scene you realize that you need more skills to
beat your opponents.

v) Another fastforward and the best computer chess game beats you.

An extra hint: if there were 10000x more chess players in the world the path
would be longer.

------
gaius
In his Culture novels, Iain M Banks likens technological progression to a
rockface rather than a ladder. There are many routes to get up.

~~~
npsimons
As a rock climber, this seems _so_ apropos: I've seen so many different people
bouldering and rock climbing, that were different not just in physically
obvious ways (ie, height, arm reach, etc), but in how they approached problems
(skill versus strength, etc), that it really resonates that there's no one
perfect way for anyone to learn.

------
Xophmeister
What advice does anyone have for someone who wants to go up levels, in
anything, but lacks the self-motivation to actually get started?

It's convenient that the OP is about higher maths education: I flunked my
maths degree for various reasons. I managed to graduate, but not at the level
I am capable of. In the intervening years, I've been tempted to get back in to
it, however real life (and various other excuses) get in the way. It's a big
mountain and climbing for the sake of it isn't overly inspirational... Small,
achievable goals seem like a potential solution, but I'm at a loss when it
comes to setting any and am blinded by lofty (futile?) ambition.

~~~
kerkeslager
> What advice does anyone have for someone who wants to go up levels, in
> anything, but lacks the self-motivation to actually get started?

I was in a similar situation to you a few years ago; I actually still haven't
graduated. However, I feel like I'm working hard and leveling up a lot over
the past few years. This perception is validated by advancements in my career
and social standing within the teams I've worked with. What it took for me was
to to find a goal that I was intrinsically motivated to achieve.

See here for info on intrinsic versus extrinsic motivation:
[http://en.wikipedia.org/wiki/Motivation#Intrinsic_and_extrin...](http://en.wikipedia.org/wiki/Motivation#Intrinsic_and_extrinsic_motivation)

It's easy to judge yourself for not being motivated, but that doesn't actually
fix the problem in any way. And it also fundamentally misunderstands the
nature of motivation: you have no control over what motivates you. If you try
to coerce your motivation into some arbitrary activity, it's not likely to
work, and if it does work, it could work a lot better, and it's going to be
very stressful in any case.

So, a good place to start is by trying different things until you find
something that intrinsically motivates you. Once you find that thing, a lot of
things will fall into place (at least, this has been my experience). Tasks
which were tedious when they were only extrinsically motivated become
something you rush home to work on when they're intrinsically motivated.

------
jdmitch
Thanks - really helpful for me as I am "finishing up" my PhD. It never
occurred to me that I need to see it as a more mundane task than I do
currently! (Probably also wouldn't hurt to stop reading HN :)

------
osteele
In my own experience, some optimizations seem to come along on their own
accord if I repeat a task (constructing and refactoring a code base using a
known language and platform, keeping a meeting on track, getting the timing
and finger angle pressure and muting right while playing a guitar piece), so
long as I'm well-rested and attentive during the task, and repeat it enough
times.

Other improvements only occur if I consciously decide to try something
different (trying a different programming paradigm, changing the cadence or
invitation of meetings, using a different voicing or fingering or replacing
picked notes by legato or vice versa).

The optimizations that take care of themselves feel more analog. I suspect
that they're more susceptible to local optimization. In the case of music (and
running, and juggling), I suspect there's some involvement from the
cerebellum.

The ones I have to direct feel more quantized; more digital. Optimizing them
seems like simulated annealing. Sometimes I learn by knocking myself out of my
comfort zone, or copying someone I admire or whose artifacts or performance I
admire, or trying out gratuitous variations on approaches to something I
already know how to do (I'll write in it Haskell! I'll avoid using my left
index finger for a week!) to see what they lead me to.

I don't know if this is the same distinction as the one between progressing
within a level versus going to the next level, but that's what I was reminded
of when I read this.

The things that I've felt have taken me to the next level are those where I
kick myself out of my comfort zone; often in a toy or side project where I've
given myself the permission to take huge risks that I don't feel responsible
with on a paying gig and/or when other people are depending on me; and often
by _re_ -working, in a medium I'm uncomfortable with, an application or
problem domain that I've mastered with my old skill set

------
bradleyjg
I guess I'm not the only one in the intersection of HN readers and MR readers.

~~~
anusinha
What is MR?

~~~
bradleyjg
marginalrevolution.com a blog by two Econ professors where I saw this linked
two days ago.

------
benched
There are a lot of very well-expressed ideas in here, likely to resonate with
people who practice things, or climb towers of abstractions.

The LessWrong culture has a related term, which I've found useful, called
inferential distance:
[http://wiki.lesswrong.com/wiki/Inferential_distance](http://wiki.lesswrong.com/wiki/Inferential_distance)

