Hacker News Reader

Comment by smlacy | Hacker News Reader

No. Not this. Net even close to this. Let me illustrate:

How to become great at Sports: - Read books about sports. - Watch other people play sports. - Read in-depth analysis of past sports games.

How to become great at Playing Violin: - Read books about playing violin. - Real sheet music by the great masters. - Listen to many concerts.

It's inherently obvious that the above approaches are totally and completely wrong. How do you become good at anything? You practice it. You do it. You have a coach or teacher or mentor who can give you pointers, but lets you make mistakes. You have someone who lets you get things wrong the first time, so that you can see the consequences.

There is a time and place for theory, for reading, for analysis, and this is too part of the learning process, but this is not at all the most important tool for becoming great at something.

Theory, analysis, critique, history, and context all matter when learning any skill, but first, you must build the fundamentals. First, you must do the thing and once you reach a level where you really understand the thing, then and only then can you begin the more introspective task of theory and analysis. Even without these steps, the best way of becoming great is to DO.

View on HN

Knowledge work is different.

How to become great at Chess: - Read books about chess. - Watch other people play chess. - Read in-depth analysis of past chess games.

How to become great at Math: - Read books about math. - Watch other people perform math. - Read in-depth analysis of math.

You also skipped a key assertion from the author: "Do exercises and try to explain common JavaScript concepts such as inheritance in your own words."

But you're right, nothing beats digging in and creating something.

I don't think that's actually the best way to be great at chess, or math.

On chess, from a GM: "The key to their success is that they kept playing a lot, and learning from stronger opponents. Don't get me wrong: I am not suggesting stone age technologies in studying. Of course, you should take advantage of the best modern learning methods. However, the most important component of success (at least at weak GM and below level) is practice."

http://www.chess.com/article/view/getting-better-in-chess-cr...

Math is similar. You really have to do math. Reading books and watching other people do math is not the critical part.

Well, wrt chess, we can have dueling GM quote battles over this point:

From "Andrei Istratescu's top 10 reasons for stagnation:"

1) Too much play Playing chess - practice - is very important for improvement. When you play chess (over the board, at tournaments), you put into practice what you have learned, you use your brain to think chess, you are in the testing environment, you test your accumulated knowledge and skill against another person. However, too much play and too little study holds you back. You can repeat the same mistakes over and over. You will tend to follow your own old patterns and not have time to develop a different, correct thinking process, and to learn proper strategy and new ideas. In this case, you should take a long break from playing and concentrate only on study for several months. You will make a significant improvement.

In my experience, the first chess book I read (Logical Chess, Move by Move) probably bumped my rating by 400 points. Then, more specialized openings and tactics books another couple hundred. After that, simply playing got me mostly nowhere.

In chess below the master level tactics will dominate. How do you get really good at tactics? Not just by playing lots of chess, but by consistently devoting effort to studying tactics via printed collections of positions and/or tactics training software.

As to becoming great, after years of running chess camps for young players IM Greg Shahade formed his somewhat famous hypothesis:

   There is one very reliable sign to how much potential and how strong a young chess 
   player is or is going to be, and it’s probably not what most people would think. 

   It’s not how quickly a student solves tactics or sees combinations (although 
   these two things always seem to be correlated with the main point of this article).
   It’s not the student’s positional understanding. It’s not even how much they 
   claim to study chess.

   Instead it is “How likely is this student to recognize a famous game/position
   and know the players involved?” [1]

As one data point illustrating Shadade's point, the current world champion seems to be a whiz at what ordinary people would consider chess trivia. [2] Carlsen's comment:

   "I like chess, I like chess books. You'd be surprised – I do read 
   as much chess as I can."

[1] http://www.uschess.org/content/view/12551/745 [2] http://www.uschess.org/content/view/12985/806/

Editing for formating: how do block quotes work here?

Completely agree. I never truly understood discrete math until I had to teach it. I didn't understand sales until I ran a vendor booth for my wife's sci-fi novel. I didn't understand ballistics until I built model rockets and potato cannons from scratch. I didn't understand cooking until my coworkers at Waffle House marooned me at the grill during a Sunday morning rush. I didn't understand linear algebra until I had to write a software rasterizer and a best-fit modeling function. I didn't understand money management until I was poor. I didn't understand relational algebra and database systems until I wrote an ORM. I didn't understand digital electronics until I had to build a kiosk system from scratch (for a client!). I didn't understand analog electronics until I had to build a music synthesizer. I didn't (really) understand AC until I had to rewire my house!

Maybe some people can read a book and just know how to do things based on that. I used to be very caught up into thinking I needed a book to learn things. But that's not really me. I have to do. Most books aren't written in that regard. The authors want to pontificate on minutia. Now, I know I just need to jump in the deep end of making something and--somehow, be it through Wikipedia or Wolfram Alpha or StackOverflow or MSDN or MDN or what have you--I will learn what I need to get it done. Give me a cheat-sheet, some pliers, and a bail of wire any day. Until then, it's all just noise.

I think it ties in naturally to the Lean Startup ideology, i.e. the whole "release early, release often" thing. Using the example of chess, if you're just reading books on chess and are not playing games, then you're no better off than a startup who is working out of someone's basement, no marketing plan, no market feedback, just coding away based on some blue-sky ideology. "Release early, release often" isn't so much about success as it is about getting out of the basement, seeing the flow of things, and opening your eyes to reality.

Indeed.

When I was in "prépa" (see https://en.wikipedia.org/wiki/Classe_pr%C3%A9paratoire_aux_g... ) my English teacher, an American told us that the way he saw the system was to train us at math, just as a way to discriminate us between those who'll get to pick the best school and those who will take what's left. And he said, they might as well train you to do chess for 2 years and let the strongest one pick his school.

He also told me that back in the US where he came from, with his local chess club he went to a prison play with the inmates. They got destroyed, because the inmates played chess all day long so they were all very good.

a lot of people out there don't have access to mentors, so I (unfortunately) feel that the self-learning by books approach is still the most practical, generally speaking.

This is a pattern of behavior I see in people, that they think they need a "mentor" to get good at anything. I've even had people explicitly ask me to be their mentor. Like, people here, on HN, reading my comments, contacting me through my email address in my profile, asking me to be their mentor.

Frankly, now that I'm experienced, if someone were to agree to be my mentor when I was a beginner, I should have been suspect of their expertise, because I don't know anyone who is actually any good at what they do who has time to do anything called mentoring.

Where does this idea of mentorship come from? I have never seen it. I've had examples in my life of people to look up to, but when people talk about mentorship they seem to be talking about some sort of creepazilla relationship where the student sits at the feet of the master and receives wisdom. Yeah, no, that doesn't exist in the real world, at least not for the vast majority of people.

If that's what it takes to be successful, to be reallly good at anything, then buddy, we're all in a world of hurt. It's an appealing idea, but who the hell does it ever actually happen to? I'm convinced it's a fantasy.

Strictly speaking, you don't need a mentor to get good at anything. However, it can really help in the areas that are defined more by people than by things working or not.

As a mentor, I have found that is mostly about reviewing others work and thinking and giving feedback. For instance, you don't really need a mentor to get better at solving problems. You may need a mentor to help you communicate details about the solution.

Any great chess player (let's define that as near-IM fide ratings and up) will tell you that it's a highly iterative process between practice, analysis and reading that is very much anchored around practice.

They play thousands and thousands of hours and, yes, also spend quite a bit of time reading, thinking, analyzing (both their own and others') games and learning from mentors/teachers. However, practice is king and all the reading/analysis would be worthless in its absence. They would have no anchors to grab onto in your brain - no way to really become operational.

A chess "player" that mostly reads, studies and analyzes with a little bit of practice sprinkled in between would indeed be hilariously weak.

Take a beginner player who has been playing at the local chess club once a week (two hours) for 12 weeks. This player enjoys the game and wants to be better. He plays anyone who will give him a game. He occasionally wins against other beginners. He loses to the stronger players when he gets a chance to play them. This player has 24 hours available to work on chess over the next 12 weeks. What is the best way for this player to improve? Suppose the options are, 1) continue attending chess club for the next 12 weeks, or 2) stay at home and study two hours a week for the next 12 weeks. The study material is Logical Chess Move By Move by Irving Chernev (mentioned above by msluyter). The book covers 33 master-level games in two categories: kingside attack, and queen's pawn opening. Chernev, a Grandmaster, explains the reasoning behind every move in all 33 games. When the player shows up at chess club on week 25, will he be better off having chosen option 1 or option 2?

Reading, watching and in depth analysis might be necessary conditions for true greatness but they do not constitute the biggest part of improvement/greatness.

The biggest part is the ability to move a large part of the necessary skillset to your unconscious mind. As a joke Capablanca said "I only see one move ahead, but it is always the best one", this is how every strong chess player thinks, they can instantly evaluate the position. It is just like once you have learned to drive well, you would recognize a potentially dangerous situation(a child playing with a ball on a sidewalk) without actually thinking about it consciously.

I believe this is how the best programmers work too, they have an immediate grasp of possible techniques they can apply without necessarily thinking about them or looking them up in google.

You become great at your craft when you internalize/obtain unconscious mastery of a large number of techniques in your craft. You become truly great when you can combine these techniques in novel ways.

I will mostly speak about chess, because I am an average programmer and average mathematician but am a pretty good chess player near IM strength FM (2350) and have spoken to various strong chess players (up to 2700) on this subject.

There have been players who have become very strong with very little reading (GM Flohr is a famous example from 1930s) but with a lot of playing, however I am not aware of anyone who become good without practice.

So let's start with a simple example. You must absolutely learn how the pieces move, this would be equivalent to what loops and conditionals are in a programming language. If you have to think how the horsie jumps when playing, you are not going to get very far.

A more complicated example, it is very useful to be aware of the standard h7/h2 sacrifice. As you get stronger, you develop a better sense on when this sacrifice will be strong and when it will be likely fail, even before starting to calculate consciously.

How do you obtain this knowledge, the best way is iterative by playing and applying in practice what you learned.

Dunno about chess, but when it comes to doing original pure math research, bookwork is necessary but not sufficient. Practice is also necessary, and lots of it. Even when it comes to reading math textbooks, the exercises are the most important part.

Not really. The practice in knowledge work is to read and watch. That is in itself the practicing.

You must work and do to become great at something.

There is a saying in coaching: "practice does not make perfect. Only perfect practice makes perfect."

What that means is that the point of practice is to reset habits to the best possible technique, so that when the athlete is under duress, they are habitually as efficient/effective as possible. Any practice done with poor technique is basically wasted time, and potentially counterproductive. This is true at any point in the athlete's development, from day one to just before the title game (or match or whatever).

So, just writing a lot of javascript will not make someone a great javascript developer. If they write a lot of crappy code, they will become an experienced, crappy developer.

The best way to achieve greatness is to have a great coach (or teacher, or mentor). That person can help one shortcut to the best technique, and they can catch and correct one when one strays from that.

But if one does not have that, then disciplined self-study of known great performers is an ok substitute.

And, when it comes to "how to become great" articles, I think the writer usually assumes that the reader is already somewhat engaged--that their target audience is already writing javascript but wants to get better at it.

It continually amazes me that programming books are as popular as they are. I can't think of a format I'd prefer less than static text when it comes to learning new programming languages.

Much better to just jump in and start figuring things out. Google your questions, find Stack Overflow questions. Fiddle with CodePen (etc) examples to see what variables and functions do what. Once you're well versed, read the occasional blog post about emerging techniques and patterns.

I work in JS day in, day out, and this approach hasn't seen me wrong. But we're all different.

Because they have the depth of experience that is otherwise unavailable except by months or years of hard-fought struggle.

It only takes being bitten a few times by rushing into a new tech and doing everything completely wrong from the start. The smart learn from their own mistakes, but the truly wise learn from others'.

This still holds true in JavaScript.

Books are about communicating experiences. A great book can give you the knowledge it would take years to get by personal experience alone. If anything, people involved in programming don't read nearly enough. We have giants on whose shoulders we should be standing, and instead we just retrace their footsteps. We need to stop ignoring our past.

Obviously, practice is also critical, but my point is most people who love to program love the act of programming, so they obviously already do a lot of that.

In my opinion programming is a linguistic skill. A more apt analogy is trying to learn French by reading textbooks on learning French. I spent 5 years teaching English as a foreign language and I can tell you that learning a language from textbooks will not allow you to be "good" at the language when compared to the fluency and proficiency of a native speaker. You will certainly be able to accomplish various tasks and to get your message across to others, but you don't really have a hope of being a "good" speaker or writer of the language compared to even the average child. Your language will be full of tortured constructions that are (hopefully) grammatically legal but idiomatically terrible.

I hope this situation seems familiar to programmers because we see it every day -- programmers who write code that "works", but is tortured in its design. We can see people who can not express themselves in code because they are not fluent enough to do so. We can see people who can not understand common idioms because they never have read other people's code (in quantity). They ivent their own idioms, just like baby talk, and often decide that their baby talk is superior to the living language around them.

The biggest difference between a human language and a computer language is that most people aren't exposed to incredibly fluent users of the language in great quantity. It is really easy to fool yourself into thinking that you are a great programmer, when actually you can just barely make the code work. The same happens very frequently to learners of a foreign language that are rarely exposed to native speakers. You have no yardstick to measure your progress other than your textbooks.

Although I agree with your assesment that you must DO, but even more so you need to seek out communities of fluent users of the language and interact with them. That means reading their code, writing code, having them correct it, etc, etc.

A professional software engineer should be regularly reading to keep up with their craft. It's a balance, and one that I've generally noticed is tipped away from focused reading/learning because the modern Stack Overflow-driven world nudges people to "just do it." Telling people "you should read a lot of books" shouldn't be necessary, but nowadays it is.

In one of my recent interviews, I was asked how do I learn a new language. I rely on good 'ol practice of reading from top to bottom intertwined with YouTube, conf videos and blogs. This highly experienced architect called my approach non-agile. He was expecting me to take a quick and dirty SO-route for fast results.

I think of books/knowledge as an experience accelerant. One could set a log on fire and it will burn, but it will burn a 'hek of a lot faster when liquid oxygen is poured onto it. Books do the same thing for practice. You'll get there one day with practice but you'll get there much faster when you're practicing under the influence of performance enhancing books.

One example from my own experience is Estimating.

It's something we all do, week in, week out. Yet there are still plenty of developers with years of experiences who delivery poor estimates week in, week out. I was one of these poor souls when I started developing. I would spend countless nights up late trying to finish a feature I promised someone else would be delivered yesterday.

So I did what my grandpa always recommended and I picked up a book, Steve McConnell's Software Estimation : The Black Art. And it taught me all types of tricks like making sure to break tasks into the smallest possible pieces.(Along with many other things. Seriously by this book, and every book Steve McConnell has written)

Maybe I would have eventually figured out tips like these on my own. But instead of having to wait to practice breaking up tasks into smaller more estimatable chunks, I got a 5 year head start and quickly was able to surpass many coworkers who had more years of experience but had spent less time in a book.

And now I can spend those late night posting on hacker news and not writing code trying to catch up for work :P.

TL;DR : Books are awesome. I read one once and I am a better estimator for it. And being a better estimator lets me spend more time on Hacker News. So if you wanna spend more time on hacker news, read a book.

Maybe I'm in a minority, but I've never read a programming book that didn't have me writing and testing out code in my console while I read.

Also, the kinds of things I tried out on my own while reading were unique and new. Not the kind of things I would necessarily run into in my job.

Doing is one thing, but if I just keep doing with my current knowledge then it's easy to fall into a situation where improvement is minuscule.

Exercises are very different from projects. When you support a project over the long-term, you engage a very different set of skills than what you'll get in a book. You learn how to push your way through a seemingly unsolvable bug that nobody has encountered before, often one in code that you didn't write. You learn how to make technical choices that reduce the likelihood of encountering these bugs. You learn how to come back to your program in a few months and pick up where you left off, and what sorts of coding practices will inhibit this. You learn what sorts of bugs occur in practice, and how to avoid them. You learn how to diagnose performance problems, how to speed them up, when to speed them up, and you build up a mental model of how the systems you work with behave. You learn how to limit complexity, and what the complexity budget of your brain is, and how to break up projects so that you stay within that budget. You learn how to communicate with other programmers, and what they care about. You learn how to build up a codebase incrementally, how software evolves, and how the why of the code usually matters more than the how. You learn how to communicate with users, and how to accept their input, and how to weigh the costs of their feature requests against the complexity of the code base.

All of these are emergent problems that only occur when you work with large, long-lived software systems. You won't get them out of a book.

This is bad advice. Theory is vastly more important in computer science and math. Given your logic, one will simply practice their way to linear algebra, machine learning or AI. Good luck with that. There's a giant toolbox of shortcuts that seem like magic to the inexperienced. Becoming a great _user of tools_ (programming languages, etc.) is level 1.

Isn't reading books a good way to build fundamentals? I don't think reading a book necessarily precludes you from working on the exercises in that book, which would indeed be a great way to build your understanding of a language. This is the way I approach learning new languages - working through a tutorial, or, indeed, a book. Giving someone the advice, "Hey, just go write some JavaScript," probably isn't great if they don't know any JavaScript.

While I see where you're coming from I think your analogy is flawed and it doesn't quite apply here.

As a martial artist and weight lifter that totally makes sense - practice, sparring, doing the actual activity is what will make you good. The more you do it, the more you train your subconscious to intuitively know what to do.

As an engineer and tutor it only applies in a limited way. I have taught people who want to learn programming but lack all sorts of fundamentals. What they need to do is just go back to basics - read a book - do the exercises. I find that as an adult learner missing the basic background on things just makes everything hard. You will need to ask questions every step of the way. Who will be on hand to answer those questions? People like me, who have sat down and studied the basics and learned from first principles, i.e. worked through the books.

Coding is like math. Both practice and theory are important. If you don't read the chapter first and try to jump right into the exercises, you will not be able to do them properly. If you read the chapter but do not do the exercises, then you will forget everything you've read.

Having a coach is a luxury. For us software developers the closest thing we get to coaching is a code review by a more experienced developer. That is certainly valuable but rather hard to come by consistently if you are past certain level.

So what to do without a coach? Find something that will direct your practice. For this reading quality code is indispensable as it shows you the range of possibilities of what you can do with certain technology.

Considering your example of sports: past certain level it is essential to meticulously study video footage of yourself and your opponents in action as it provides insight into your weaknesses and your opponents' tricks which you can then adopt or learn to counter. Also when someone comes with spectacular advancement in technique (think Fosbury flop) it is quickly analyzed and adopted by others. So watching others is sometimes very useful.

I agree, one must oscillate between theory and practive. Acquire data, follow your intuitions, reflect on it, explore alternatives, communicate with others a little.

What do you think about Platonic teaching ? asking question to direct exploration without giving 'free' (~bad) knowledge.

This is the best comment I've read on HN! I guess you need to become great at something to understand this. For you to keep doing something though, you need to think it's fun! Then it will be much easier.

I kind of read it as the assumption is, if you're wanting to be a great JS programmer, that all these recommendations come on top of programming in JS as much as possible.

People already 'practice Javascript' a lot .It's the only language where people start writing without ever formally learning it.

Reply on news.ycombinator.com