Hacker News Reader

Comment by hliyan | Hacker News Reader

I'm still reading the article, but I stopped halfway to point this out:

Remember the ‘10,000 Hours’ Rule for Success? Forget About It

They should not have said that. I don't know whether 10K is the actual number, but I got good at two things that I was never naturally good at, simply through years of brute force repetition: coding and writing.

I was never a born hacker -- I struggled with Visual Basic when I was 21. But 15 years and maybe 300,000 lines of code later, I have an extremely high degree of proficiency in both C++ and JavaScript, with a good level of proficiency in Java, Python and Golang. I was extremely bad at writing. So much so my fingers used to sweat when I came to the essay section of any test. But after about a decade of keeping a personal journal, I would like to think I write rather well.

Anecdotal yes, but speaking personally, I would not discount the 10,000 hours concept.

View on HN

Unlike what this review seems to imply, the author of the book doesn't actually discount that concept - he says it's true for a certain kind of activity, one with reliable feedback, such as programming. Quote from the interview I linked:

"The way that chess works makes it what's called a kind learning environment. So, these are terms used by psychologist Robin Hogarth. And what a kind learning environment is, is one where patterns recur; ideally a situation is constrained--so, a chessboard with very rigid rules and a literal board is very constrained; and, importantly, every time you do something you get feedback that is totally obvious--all the information is available, the feedback is quick, and it is 100% accurate. Right? And this is chess. And this is golf. You do something: all the information is available; you see the consequences. The consequences are completely immediate and accurate. And you adjust accordingly. And in these kinds of kind learning environments, if you are cognitively engaged you get better just by doing the activity. On the opposite end of the spectrum are wicked learning environments. And this is a spectrum, from kind to wicked. Wicked learning environments: often some information is hidden. Even when it isn't, feedback may be delayed. It may be infrequent. It may be nonexistent. And it maybe be partly accurate, or inaccurate in many of the cases. So, the most wicked learning environments will reinforce the wrong types of behavior."

That is actually discussed in this review (kind versus wicked learning environments). It just isn't at the top of the article because it's not as catchy.

Would you count coding as a kind or a wicked environment? To me, it seems wicked - standards change, you switch languages, frameworks come and go. On the same token, it could be 'kind' if you isolate yourself to one or two robust languages (i.e. your career is built on C++).

Coding is kind. The dichotomy is based on feedback availability, quality, and delay. While the environment does change over time, it continues to be kind: 99% of the time, you're able to hit compile and see instantaneous, accurate feedback. Doesn't matter which language, framework, or standard you're using (except maybe Malbolge). Even debugging is kind save perhaps for heisenbugs, but that's a bit of a stretch to declare the whole field a wicked environment.

Coding is the kindest learning environment mankind has ever known.

Constructing valid experiments in software development is incredibly easy. Add an assert, recompile, and see if it gets triggered.

We programmers consider it unacceptably painful if testing a hypothesis takes ten minutes.

Real life is never that clean or easy.

Will it compile takes 10 minutes. Is this good long term design or am I building a castle on quicksand takes much longer.

>Will it compile takes 10 minutes.

That's a sign something is wrong.

He meant it will take a short amount of time to write and then compile, not that the compilation takes 10 minutes.

That's definitely less kind, and it's a huge problem in practice. I think it's still not that bad -- people can and do get much better at designing things for medium- to long-term maintenance over the course of a few years.

That's a very good point.

Even for that, though, if you define your criteria for success, it's mostly possible to measure the outcomes and learn whether your approach was successful or not. One key there is remembering that subjective metrics are valid - user happiness and developer happiness are two of the most useful ones I know of for measuring the system's overall health and effectiveness, and while they're not objective, they can still be measured reasonably quickly and regularly.

For fields like public policy, though, there are just so many confounding factors and the timeframes are so long that it becomes nightmarish, maybe even impossible, to genuinely learn anything. The subjective metrics of citizen happiness and functionary happiness that are analogous to my software ones above are worthless because of rollout times measured in years or decades and the infinite array of factors, confounding and otherwise, that go into people's satisfaction with society.

Even relatively straightforward things like farming have learning cycles measured in years for things like crop rotations.

The universe is just not a friendly learning environment.

Programming is an aberration in almost every respect, as a product of the human mind that can actually have useful impacts in the world (most friendly environments are human constructs that are not "useful" per se, like board games or musical performance or sports).

It depends, in some regards it's kind as the results are seen immediately (is a path bringing more or less compilation errors, etc), whereas as in others it takes time to see if the decision you made was good or bad (did the architecture you chose scale).

I disagree with the other responses. I think it's both. You can get very quick results and feedback for experiments related to implementation. Code compiles or doesn't, tests pass or they fail. But whether you actually built the correct thing is definitely "wicked." A lot of times subtle bugs and user feedback surface weeks or months after the fact. It can be very hard to find out whether what you did worked for the business need, which is ultimately the main point of the job.

Once you code for long enough, every language begins to look the same and it becomes easy to switch. I have worked full time with PHP, JS, Java, Python, Objective C, and C++. That's at both multiple startups and at a FAANG.

In fact, if you choose one strongly typed language and one weakly typed to know in depth (eg Java and JS) it's really easy to move to others.

The trap that people fall into is that they focus too much on learning the ins and outs of a framework and not the important concepts. Or they are stuck in a problem domain that's very thin on CS concepts, like web dev or frontend dev. You don't learn concepts that make it easy to transition.

From my own experience, focusing on CS and math (esp. stats) and systems programming have made it really easy to move around.

It has helped that in the last 10 years most of the languages have converged to an extent.

Like before things like generics and lambda expressions C#/Java were quite different to Python/Ruby, and js used to be quite an abysmal language but with some nice features nothing else had (still is an awful language to an extent). I think C# 2.0 and 3.5 really changed that language for the better, Java spent a lot of time getting to the C# 3.5 level.

And I remember a time when C++ was almost incomprehensible if you'd never worked in it, but now it seems to be a lot less daunting as you've got bridging languages like Rust and Go.

I must admit I've still no interest in Haskell/F#/etc. I tried Lisp about 10 years ago and it just seemed such a pain, for me I find imperative programming so much easier to map out complex interactions in my head. I also find set based programming like SQL very easy. But functional, ugh.

Agreed, I feel like most languages have converged into some kind of variant of C#. Even JS, if you count Typescript.

For multithreading, I would take functional over imperative any day though. The multithreaded code I write in Java ends up looking like functional code by way of chaining futures, but it is still hindered by the use of shared memory and synchronization (or lack thereof).

I enjoy C++, and the additions in C++ 11 and 14 are mostly good ones. But they don't do anything to make the language more approachable IMO.

Coding - kind, software engineering - wicked.

Coding is something you can learn on your own with a tool, some books or manuals, and time. The compiler provides a lot of feedback, debuggers and manuals give you a lot of information to develop your skillset. A few books on algorithms and data structures and specific domains (like graphics or network) will get you to a solid point as a programmer.

But developing systems that are high quality, multi-component, interacting with other complex systems, and sustainable is another thing altogether. It is costly, tradeoffs are sometimes non-intuitive, and you probably need to have a mentor or a good work environment to really get skilled at it, or the right kind of analytical mind. But you'll still have a lot of failures along the way and need to develop a lot of different skills.

Nah, even that is extremely kind, unless you never see how your program is doing a few years later.

Usually you get feedback within 1/2 a year. That complicated search system with your own fantastic DSL an absolute nightmare to modify? Kind feedback. Your system works fine with 100 users but falls over with 10,000? Kind feedback. You used a trendy new js framework that disappeared 2 years later? Kind feedback.

And better still our industry has tons of people who write lots of books or do podcasts or do conferences where they talk about how their projects went wrong, and how they fixed them. Whether it was the GoF design patterns, or Code Complete or one of the many others.

To me, all of that is clearly kind feedback.

Interesting paradigm. It's like wicked learning environments are the SLAM of life.

neat, that's how i basically intuit the difference between playing basketball and working. feedback in basketball is immediate and (mostly) obvious; not so in many work environments. basketball for me is like a microcosm of work (working in teams, varying skillsets, differing tactics, etc), which leads directly to my oft-reliance on basketball analogies at work. =)

Curious, how do you think a decade of journaling has made you a better writer? Most writing advice heavily features feedback, from peers, instructors, friends, editors, and so on. But journaling almost by definition prevents that. And it's not like hoisting jumpers in basketball -- you don't really know if you "made the shot" in writing, no? In the article's language, writing seems like a very wicked environment.

Not the OP, but one of the hardest parts of writing (at least initially) is simply knowing how to take the thoughts in your head and put them into words. This is a skill that just takes practice, and improvements to it are fairly obvious even without external feedback—you become much faster and your writing starts to sound better and flow more smoothly.

Source: Someone who struggled with writing and became better with practice. :)

Edit: I just want to point out that getting better at "writing" in the broadest sense is very different than getting better at specific kinds of writing, like academic or journalistic, where particular patterns are important and much more difficult to self-teach.

All you say is 100% true, at least in my own experience as well.

But none of that means you will be able to reach a certain audience. Although I have to say, I care very little about that. Good technical writing which is appreciated by my colleagues -- and being eloquent and expressive in casual conversations -- is good enough for me.

I think often you do know, because your taste is better than your abilities, just from reading other people's work. Knowing that you made the shot might be hard, but knowing that you definitively missed it often isn't.

Relevant quote by Ira Glass: https://www.goodreads.com/quotes/309485-nobody-tells-this-to...

I don't know how to explain it, only that it worked. If I had to guess, I got feedback from my future self. I would often read my old journal entries, and notice errors and improvements that I would not have noticed at the time. That, I suppose, is how I know I've improved. I also read a lot, so each year I learn more about what good writing looks like and therefore have a progressively improving basis of comparison for my journal entries.

Edit: I'm not a native speaker of English.

Editors won’t help if you cannot get words on the page.

The original author is saying success, not proficiency. There's plenty of programmers who didn't end up like John Carmack. Defining success is pretty difficult. I generally agree with everything you're saying though, and it's hard to say any good programmer won't be nominally successful in their own right. Any skill-based career will enable someone to be employable, which in 2019 is more successful than average.

The counter argument is that trade-crafts (of which I include programming) are one of the clearest examples of different people have vastly difference proficiencies in the lower tiers of skill outside mastery.

The 10k hours rule is actually a misunderstanding from a paper on violin practice by Anders Ericsson. An error that the author himself explains in his book Peak: Secrets from the New Science of Expertise. It doesn't mean that you can't learn something to mastery in 10k hours or less. It just means that 10k hours is kind of an invented number. Some skills require more time, some less, but all of them require purposeful practice.

The 10k rule is falling out of social favor nowadays, as are most systems of thinking that suggest success requires hard work and (most importantly) persistence.

"If hard work pays off, show me a rich donkey."

Persistence will make you a master in a skill -- and you can do it almost subconsciously afterwards.

It doesn't give you a broader culture and overview of the world though. Or at least, it rarely does.

> ”If hard work pays off, show me a rich donkey."

What a weird analogy, as if spending all night pointlessly digging hole in your background correlates with wealth. Though I think if you did have the grit to do that you will find success in many endeavors.

It takes hard work to go from nothing to something. People doing the hard work are not confused about what’s meaningful.

"What a weird analogy"

Not sure why you find it weird. There are a lot of hard working people out there. And very few of them ever go "from nothing to something" as you put it.

I don’t know where the concept of meaningless physical and mentally hard work — regardless of its effect or purpose — is somehow guaranteed to produce wealth comes from. I don’t know anyone who believes that.

You don't, but here in Eastern Europe most of the working people I know absolutely believe exactly that.

Around here "work smart, not hard" is a mind-blowing revelation for many. And it bears repeating since people forget it regularly.

> It takes hard work to go from nothing to something. People doing the hard work are not confused about what’s meaningful.

If that were true, every startup would be successful.

As opposed to success not being predicated on hard work and perseverance? I think if that were true there would be many more successful startups.

I have always liked the saying that "the only place success comes before work is in a dictionary". It's clearly not entirely accurate, because of course you can gain advantages through something like inheritance that look a lot like being successful, but there is a lot of truth in it if you look beyond factors that really are dumb luck.

The outcome of a high quantity of deliberate practice isn’t an opinion. It may be true that it’s more popular to deride top performers and perhaps try not to hire them, but we can’t help but value the contributions that people with deep expertise make to the economy, the arts, infrastructure, and so on.

Is it? My impression is that nowadays people accept hard work and persistence are still necessary but no longer sufficient.

I thought "grit" was the watchword a few years ago, but maybe what you're describing is even more recent than that.

Thanks for sharing. Everything I ever struggled with programming wise, I got better at simply by putting in the hours.

Reply on news.ycombinator.com