Levels of Excellence
johncarlosbaez.wordpress.com
johncarlosbaez.wordpress.com
> 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.
"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!
(You probably are talking about a meta helicopter, but it sounds like you should take the company helicopter for a ride to think about it. I like the idea.)
This can be things directly related, or something really as simple as, I believe I remember hearing, making sure that the athletes own pillows are packed for them when staying at hotels for events rather than relying on people getting used to the bedding provided.
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...
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 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.
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
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."
Ideally you would approach this from both ends. On one end you are learning bottom up. On the other end you see what you need to make and you backtrack from there until something you know and you try to make your way up.
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.
I second the practical approach of working on projects. I've learned so much just by trying to do things I wanted to do, but didn't know how to do at the time.
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.
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.
That's where computer science comes in. CS deals mostly with abstract concepts -- algorithms, data structures, parsing...that type of stuff. If you train your mind to think in these terms, then you start seeing programs as the sum of their parts (state machines, stacks, trees, grammars) and complex programs become less of a black-box. In effect you're transforming And because you can now picture how someone else has built their program, you just put those same pieces together and with a bit of thinking and googling, you can glue them up into something similar. Eventually you'll be able to picture your own solutions from scratch.
The thing, though, is that computer science is math. A different type of math, but math all the same. It's something you have to work at your own pace, patiently. Deliberate practice is not just a catchy phrasing. It's a very important concept. I stress this because I made the mistake of rushing through a lot of this stuff. I only half got it, but it's worth taking the time to fully understand even seemingly simple concepts because it opens up so many possibilities!
So in order to solve your tutorial problem ("what you need to learn, in what order, to get started"), I would suggest you pick a problem that's interesting to you, find out what sorts of concepts it depends on (what data structures are involved, what fundamental algorithms, ... that sort of thing) and work your way from those concepts to the solution (a working program). For example, if you were interested in building databases, you might want to learn more about b-trees, but in order to learn about b-trees you might need background in simpler data structures and work your way up. You might also want to learn about how to build a query engine, so you might want to learn more about lexing, parsing, and all that. From there you just learn how to implement those things (or find a decent library) in your language of choice and go from there.
I'm increasingly sure you simply can't go straight from nothing to no slides, and trying to force it will just cause you and your audience pain. In particular, only by giving a number of talks do you learn what the 3 things are you HAVE to have on your slides -- just being minimal for minimal's sake isn't useful.
Note this applies to UI design. A bad UI makes it impossible for the end users to "level up".
Typical example: Start with the corporate standard database system, Excel. You end up with secretaries doing the equivalent of a simple SQL "JOIN" by hand. Hopefully using copy-paste instead of hand typing. Sadly I only dream I was kidding. On the bright side technology has improved as in 2013 we use Excel for this task but in 1996 I worked at a big iron financial services corp where the master customer database was a word processor file.
Before Excel, they wouldn't be doing it all. Baby steps.
Spreadsheets as a paradigm is HUGELY successful at allowing normal people to do number crunching—number crunching that pre-spreadsheets would have required a programmer, and most likely, would never have been done at all. I think that's a win, even though we can (and hopefully will) go beyond that over time.
Spreadsheets were a thing before they were put into computers, you know...
http://en.wikipedia.org/wiki/Spreadsheet
> The word "spreadsheet" came from "spread" in its sense of a newspaper or magazine item (text and/or graphics) that covers two facing pages, extending across the center fold and treating the two pages as one large one. The compound word "spread-sheet" came to mean the format used to present book-keeping ledgers—with columns for categories of expenditures across the top, invoices listed down the left margin, and the amount of each payment in the cell where its row and column intersect—which were, traditionally, a "spread" across facing pages of a bound ledger (book for keeping accounting records) or on oversized sheets of paper (termed "analysis paper") ruled into rows and columns in that format and approximately twice as wide as ordinary paper.
Spreadsheet applications made book keeping jobs much easier, to the point that book keeping (not programmer) is on the outs as a speciality job.
1. Lexing - DFA's and NFA's, hand coded or with a lexer generator, relationship with regexes
2. Parsing - LL, LR, table driven, recursive descent, hand coded, parser generator generated
3. Interpretation - simulate control flow and data representation in a host language
4. Translation - generate bytecode for an existing vm like JVM or CLR, or assembler for processor architecture of your choice
5. VM - implement you're own vm, choose an instruction set, implement garbage collection
Getting a handle on this set of knowledge and skills will take you a considerable way to becoming a 'master'.
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.
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.
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.
I'd first think about why I'd want "to go up in anything".
Looks to me (I may be wrong of course), that you don't know what you really want/would like to do, so you're heading for the easy route(1), which is, to be successful in something for the sake of being successful.
If this is the case, if you'd find something you really wanted, plenty of motivation would come by itself (of course, that wouldn't be everything, but it would be a good starting point).
(1)=from an awareness perspective.
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...
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.
6) Features of the sport that low-level swimmers find unpleasant, excellent swimmers enjoy. What others see as boring – swimming back and forth over a black line for two hours, say – the best swimmers find peaceful, even meditative, or challenging, or therapeutic. They enjoy hard practices, look forward to difficult competitions, and try to set difficult goals.
It sounds like you should contemplate why you want to get back into math. Do you actually want to do it or is there some alternate reason? Make sure you are honest with yourself.
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
The LessWrong culture has a related term, which I've found useful, called inferential distance: http://wiki.lesswrong.com/wiki/Inferential_distance