Hacker News Reader

Comment by adamgordonbell | Hacker News Reader

Cedric Chin changed my mind on deliberate practice. Or maybe he pointed out the obvious to anyone who has tried to apply it to a mushy domain. DP is premised upon having a teacher and pedological method that you can hit hard.

Otherwise, you have to do something not quite DP. But that's ok, because in a mushy domain just acquiring the tacit knowledge that the experts have will put your far ahead ( because the pedological method and real coaches don't exist yet).

But yeah, it's not deliberate practice and reading books on deliberate practice might not help you much.

https://commoncog.com/tacit-knowledge-is-a-real-thing/

Here is my random programming take on it:

https://earthly.dev/blog/golang-streamers/

View on HN

Cedric Chin is massively underrated on the topic of Deliberate Practice. He literally has a whole bunch of a gem of articles on the topic of Expertise, which Deliberate Practice falls under.

See: https://commoncog.com/expertise/

I wished more people knew about his writings – so much to benefit from!

Thank you for the link!

I don't think he is that underrated? His blogs often get quite high on HN

Is the membership subscription worth the cost?

As someone who’s mid career trying to navigate corporate life and understand the hidden whys in business, I think so. I think of it like a Patreon or Substack. The blog has changed my mental model for the better on quite a few subjects and has changed how I view the world. I think it’s worth the spare change that I have.

I can't readily find any bio links, but what fields has Cedric Chin actually mastered with these techniques of his?

Whoa how cool to spot you in the wild on HN! I listen to your podcast, thank you for the awesome content.

When I was younger and more idealistic I took a chance and got a bachelor's in music. It didn't work out, but when I later became a programmer, one of things I took with me was this idea of "total immersion" - e.g. just hanging around and listening/watching the more experienced people do their thing.

Nice to see that I'm not alone in this idea!

Thanks for listening!

Yeah, I think immersion works, but I'm not sure how to make it not a huge time sink. It feels like its a slow path as measured by hours invested, but sometimes It's the only way.

Yeah the huge time sink aspect is definitely real. It gets much harder to justify when you already working 40+ hrs a week or have kids or whatever.

Going back to the earlier analogy, music has the same problem as programming in that the stuff you do for money doesn't necessarily translate to making you better at your craft. You end up being a factory that just produces the same thing over and over instead of growing in your craft.

I see this a lot at my job currently (I'm guilty of it as well) - speed is usually prioritized over anything else, and so bad patterns end up getting copied and "lifted and shifted" everywhere.

It's hard to find the balance.

Discord has communities for everything. In the last couple years I've recently taken up learning French and have found that Discord provides conversation on the topic at the same time as practicing the topic. There are servers for everything!

Side note: also a degree in music turned programmer, hi!

Hi! :)

Exactly. It’s easier to deliberately practice skills in closed domains or with an established pedagogy like piano where there are clear feedback loops. It’s harder to deliberately practice an open domain like doing business. That’s where you have not only to learn from experience but learn the right things from experience in the context of that experience.

Just because something worked doesn’t mean it will work all the time. You also have to learn the context it worked in and reason analogically. Cedric calls this concept instantiation and there’s more to it than that but it’s been a useful corrective to my previous adulation of first principles only thinking (which also only works in some circumstances and not others)

Feels like there should be a dedicated role for this at tech companies, like instead of it being an undefined thing that senior engineers have to do to mentor juniors but isn't really rewarded in most cases when it comes to promotions because it isn't visibly "high impact" to management.

so instead split it off into a specific role that selects for people who enjoy teaching. I think it would appeal to people looking for lower stress for maybe a slight pay decrease compared to a standard engineering role

Interesting to compare with how the UK army approaches training. Simplifying somewhat, it has dedicated schools that do trade-training for specific categories of soldiers (e.g. infantry, armour, artillery, etc). Soldiers go to these after basic training (how to be a generic soldier) when they have chosen their military specialisation. They then return as they go through career progression to do trade-specific professional development (e.g. going from tank driver, to gunner, to commander, etc).

Crucially, as soldiers (non-commissioned) go up through their rank structure (corporal, sergeant, etc) they can take instructor courses back at the schools that qualify them to do on-the-job training back in their parent units (and which increase their pay). The best of these instructors may be invited to undergo additional training that qualifies them to become an instructor at one of the schools. So some responsibility for training is fundamentally baked in to career development.

As a rule, on the modern world we study too much on the beginning of our lives and too little after it.

I don't think that model specifically can be adapted, but yes, it is a real problem and people should be thinking about ways to solve it.

I think a lot of it is that, in a modern world where we don't have kids out in the fields or milking the cows, we want something for them to do before sending them off to college (for which they need prep but probably not 12-13 years of it). And, on the other side, companies aren't really incentivized to do a lot of training of employees who will probably be gone in 3 years anyway. And the employees are often not really rewarded for doing training rather than their day job.

The military example is probably instructive because that's a case where a long-term career in a given military is relatively common.

> The military example is probably instructive because that's a case where a long-term career in a given military is relatively common.

Figures from the last decade [0] show that half of all British Army recruits will have left after four-to-five years service, and only 23% make it to ten years.

One reason (not the only one) for the military emphasis on training is they can't fully utilise their skills in peacetime, unlike most other professions.

[0] https://assets.publishing.service.gov.uk/government/uploads/...

Fair enough though I'm guessing those are still fairly high numbers compared to industry in general. People with over ten years are probably something of an outlier at most companies these days so 23% still seems like quite a few.

>One reason (not the only one) for the military emphasis on training is they can't fully utilise their skills in peacetime, unlike most other professions.

That makes sense. I attend conferences and the like which is training to some degree. But training in the sense of actual courses of some sort wouldn't be a lot of use to me at this point in general.

Mentoring juniors is both an explicit job requirement and rewarded during the performance cycle / promotion consideration at my employer.

I've felt the same too. I've been at companies where there were dedicated "teachers" and the instruction was 100x better.

Anders Ericsson, in his book Peak, states that having a coach is not optional. It's a core piece of the puzzle and people will plateau fairly quickly without one. It's a very interesting problem for software engineering since it's not typically an area I see a lot of coaching in.

PhD training teaches people how to not plateau, as (1) it teaches one how to focus on the unknowns (in that context, in the entire field, so one can dig into them; more easily applicable to one’s own knowledge) and (2) teaches one how to learn without professors / classes, which mostly consists of evaluating the quality of textbooks and/ or research papers in a field, and also how to skim at just the right level so as to learn what one needs to know.

That depends on the domain. For technical skills where rapid feedback is required during performance, coaching is critical and even reviewing video of yourself immediately after the fact is much worse. For non-technical things where skill involves knowing the correct combination of simpler actions to take to achieve a complex objective, coaching is helpful but not required.

Nobody is going to succeed at gymnastics without a coach, but you can totally reach a high level in a game like chess just by reviewing your games afterwards, reading theory and studying the games of past masters.

Lots of mushy domains still have aspects of their foundations that are amenable to deliberate practice.

For software engineers, problem solving with math and leetcode style questions can be trained in a deliberate practice style, as well as (for example) learning the ins and outs of the most import parts of your language's standard library or the most used core unix utils, or how to construct various SQL queries.

Getting those out of the way means you can focus more on the fuzzy aspects.

So I'd say there's still a role for deliberate practice in broadening and deepening your foundations.

Dan Luu has written about similar things: https://danluu.com/p95-skill/

The funny thing is that most people who use the term "deliberate practice" don't even read Peak.

When they say deliberate practice, they just mean practice. Or practice with focus at most.

Deliberate practice isn't just practicing extra hard. Remember the original research is about violinists.

> Deliberate practice isn't just practicing extra hard. Remember the original research is about violinists.

So, what's missing ?

Objective feedback.

According to Ericsson, violin performance is relatively "objective": most professionals agree on what's bad and what's good, even in a blind test environment. It's the opposite of what general people believe: that music comes down to "individual's taste". It might be true for pop, but not for classical violinists.

I really don't believe coding works like that. If it does, there won't be so many "consider harmful..." memes. You can delibrately practice leetcode, but I doubt if you can delibrately practice coding in the general sense.

Thanks !

In the meantime I opened multiple tabs to skim through and also thought "hmm, small repetitive tasks you practice again and again to perform them perfectly... not applicable to every field then ?".

Yes, having a teacher and method matters. As a cautionary tale, I tried to teach myself touch-typing years ago without either, and it was a disaster. I invented my own 'hover' method using the wrong fingers for the keys, practiced extensively, and as a result ended up having to unlearn bad muscle memory which is much harder than learning the right muscle memory from the beginning. This is apparently also a common problem for people who try to teach themselves the violin.

Unfortunately even finding a teacher doesn't necessarily solve the problem, as a fair amount of teachers end up passing on bad habits they themselves learned and adopted. However, if a teacher can clearly explain the rationale for taking a certain approach if a student asks about it (without getting upset about having their authority/method questioned), that's a good sign.

I don't get it. I learned "touch typing" after playing a lot of games and frustrated unable to type quickly to reply to teammates or argue with opponents... forced to use Vim and SSH in college and ended up getting pretty good with "just keyboard." It's probably just an environment problem sometimes. I guess my method is to learn angrily, rage against dying of light.

Are you touch typing correctly though. I assume not based on the quotes. My younger brother did the same thing you did. He’s very very fast, but he doesn’t use all his fingers and many of his movements are inefficient. He’d be even faster if he was using the correct technique.

> https://earthly.dev/blog/golang-streamers/

This is a great list. Some of my all time favorite hackers in there such as Casey Muratori and Andreas Kling.

Something that I have realized as I have gotten more experienced, is that things take time. I tried to shortcut my learning through every trick in the book and while I did manage to get pretty good in the first few years of hacking, only after I was close to 10 years of programming did I start noticing patterns and have an instinctive understanding of what to avoid and what to do.

In other words taste formation is a function of building hard things over a period of a very long time. There is simply no way of short circuiting that.

Speaking of which, I last took a programming class 20 years ago; has the pedagogy there improved any? It was quite terrible back then.

Reply on news.ycombinator.com