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.
David Brailsford (Performance Director of the GB cycling team) implemented a very similar strategy. The general gist is that anyone who already excels at something is unlikely to manage to improve on that thing by any measurable amount by just focusing on being better at it. If instead you break down everything that intersects with it and improve those by 1% then you get an 'aggregation of marginal gains'.
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.
I can relate to the puzzle analogy. Take my profession - IT engineering as an example. When you are just starting out, you know nothing and you're completely overwhelmed - you feel like you're sitting in front of a shuffled million piece puzzle. The only thing you can do is slowly start piecing the puzzle together bit by bit. Eventually (after a long time) you have enough pieces in place to start seeing "the big picture".
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"
(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 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").
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.
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.
In my opinion, compiler implementation is such a path. You can touch almost every aspect of a modern system, and many well trodden areas of Computer Science:
1. Lexing - DFA's and NFA's, hand coded or with a lexer generator, relationship with regexes
"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
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.
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."
You are taking a sort of a bottom up approach of learning the languages. It's sort of similar to learning Japanese for the sake of it (which is fine). Language is for communication and of course programming languages are to make things with them. You'll find the process more enjoyable and easier to learn if you learn it with the goal of doing something with it, not just being good at it in general. If you need to make something and you can identify what you need to do to get there, you can start chipping away at the requirements and get closer to your goal, making the whole journey more exciting.
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 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.
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.
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.
Niels Henrik Abel, when asked how he so quickly became proficient in mathematics said that he accomplished it "by studying the masters, not their pupils." I've learned languages by reading the writings of the author(s) of a language. Reading books is good, reading papers is even better. I didn't have a good foundational understanding of Lisp until I read McCarthy's paper on it.
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've been in the same boat and I've discovered that the way to get better at programming is to get better at computer science. Most books on programming usually contain a lot of basic knowledge about language constructs. It's all variables, functions, classes, and then maybe some things about web programming. For the most part language constructs usually aren't enough to solve problems. It's very hard to take that knowledge and apply it to a fundamentally different problem than what was worked out in the book. And because the problems the book worked on were most likely trivial, you don't really gain much perspective on how you would build something more complex.
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 see this personally particularly when giving talks. Many early academics / PhD students try to go straight to the "Steve Jobs" style of talking, trying to explain things with no (or very minimal slides).
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.
"They see their relative place, and can aspire for levels greater, which before would never have occurred to them even existed."
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.
> You end up with secretaries doing the equivalent of a simple SQL "JOIN" by hand.
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.
Sure they did. That was my point, in '96 the master customer list was a word processing file. They use a spreadsheet now because mere mortals can't figure out columns in Word.
> 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
Spreadsheets were a thing before they were put into computers, you know...
> 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.
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.
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.
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.
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.
> 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.
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.
The OP made a point indirectly related to your issue.
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.
You'll find motivation to master anything if you actually love it. When you truly enjoy learning something, it isn't a chore anymore.
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.
> 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'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).
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.
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
> 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.