Nice article. One part in particular stood out to me:<p>> 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.<p>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.<p>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.
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..."<p>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.<p>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.<p>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.<p>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.<p>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").<p>[0]: <a href="http://www.lillyfellows.org/Portals/0/Chambliss-Mundanity%20of%20Excellence.pdf" rel="nofollow">http://www.lillyfellows.org/Portals/0/Chambliss-Mundanity%20...</a>
I'm reminded of pg's essay on the power continuum of languages. <a href="http://paulgraham.com/avg.html" rel="nofollow">http://paulgraham.com/avg.html</a><p>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.<p>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", <a href="http://norvig.com/21-days.html" rel="nofollow">http://norvig.com/21-days.html</a> but what about after that? And that is just one man's brief and not well-explained suggestions.<p>I'd love to see other developer's suggestions for how they advanced past that.<p>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).<p>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.<p>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.
Even though this article is about math. It reminds me of my chemistry education.<p>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.<p>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.<p>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.<p>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.<p>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.<p>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.<p>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.<p>Total # of people in that class? 3.<p>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.<p>"Learn to deal with it." "It is the best model that we have at the moment." "It just works." They say.
I think the answer is: infinite levels and it works like a fractal. Let me explain:<p>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.<p>ii) You play chess in your school, work hard and at the end of the year are the best there. You are a genius!<p>iii) Then move to regional contests and things start to sound different and the level of skills required is high.<p>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.<p>v) Another fastforward and the best computer chess game beats you.<p>An extra hint: if there were 10000x more chess players in the world the path would be longer.
What advice does anyone have for someone who wants to go up levels, in anything, but lacks the self-motivation to actually get started?<p>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.
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 :)
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.<p>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).<p>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.<p>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.<p>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.<p>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 <i>re</i>-working, in a medium I'm uncomfortable with, an application or problem domain that I've mastered with my old skill set
There are a lot of very well-expressed ideas in here, likely to resonate with people who practice things, or climb towers of abstractions.<p>The LessWrong culture has a related term, which I've found useful, called inferential distance: <a href="http://wiki.lesswrong.com/wiki/Inferential_distance" rel="nofollow">http://wiki.lesswrong.com/wiki/Inferential_distance</a>