Comment by jrochkind1 | Hacker News Reader

Comment by jrochkind1 | Hacker News Reader

Parent Full thread

It's specifically about practicing/drilling. Which is definitely important to musicianship. The article doesn't even suggest musicians ought not to enter a "flow" state when performing.

I'm not sure how important it is to programming. While I know some younger coders who "practice" and "drill" programming problems, this is pretty foreign to how I've learned to program (over a couple plus decades). I've just... programmed. No shade, whatever works. But as a kind of aside, I'm curious how many programmer readers of HN do "practices" or "drills" of programming (and what stage of your career you are at; even the most expert musicians have to keep practicing and drilling. I think expert programmers just... produce programs).

(But I did find this article enlightening and I predict useful to my amateur musicianship! It's not a bad article at all. I'm just not sure how applicable it is to computer programming -- which it does not claim to be, but I assume is why it was posted on HN -- I think they are very different skills and practices. The muscle memory/physicality aspect of musicianship just doesn't apply to programming I think).

I think being a musician and programmer both require practice. As a musician, I would practice a lot of mechanics - producing the desired sound in a specific way every time. When practicing programming, I personally (and suspect most) would practice certain elements of mental recall. In some cases that would translate into a mechanical memory (vim and tmux key-strokes in particular for me). But I sometimes also force myself to not use IDE shortcuts (or copy-paste) when I am trying to learn a new library or other programming paradigm. For example, I thought learning how to do "Pandas Python" after being fairly proficient in normal Python (and general programming) was hard in making that mental model shift. But I would learn ("practice") by forcing myself to type things that I could have copy-pasted. I think the key is to be aware of what you personally require to become proficient at something. My programming practice methods might not work for everyone, and I know a lot of people who seem to instinctively "get" a new programming process. As you say "I think expert programmers just... produce programs" - this is the best place to be in! You are subconsciously "practicing" but it is wrapped up in your daily life that whatever worked to become an expert has become a habit and is no longer the burden of "practice."

I definitely agree with avoiding copy-paste. I always type tutorials - I guess it's part muscle memory, and partly because you have more time to think, but it definitely sticks better when doing that. And you usually get to see a few new compiler errors on the way :)

In a previous job I was transcribing letters from a requirements document into a program to generate nicely formatted PDFs. Officially, we were meant to copy and paste them to avoid typos. Unofficially, I always typed them and picked up a lot of errors that the clients were happy to fix. And they usually looked fine when I was just reading them with shallow focus.

The programming equivalent of "just playing" is watching conference talks on youtube, or writing code in a language/framework that you're already super comfortable with. These things are good for you, but they won't accelerate you as quickly as learning a new language, working through a challenging book, etc.

I find it highly applicable when you're approaching a new domain or skill you're not proficient or even familiar with, or when handling complex systems that you shouldn't mindlessly touch without forethought.

You don't deal with those by just winging it, there's a deliberate process you apply to get yourself into these things, and more often than not, these deliberate processes are not your state-of-flow stuff (e.g. heavy research on a subject matter, writing documentation before working on a large feature, etc.)

If I’m working on a specific algorithm, I’ll drill it. Setup a test rig and test my assumptions. I’m often wrong about a lot of things, and playing around with something in isolation is great practice.

For example, when learning ant colony optimization, I started with a naive approach. Then I tried to see if I could estimate an ideal termination condition. Then, researched known methods and refined my approach. Then looked at ways to optimize, refactor, specialize for different use cases. The hours I spent would be considered excessive to some, but far more effective than writing something that works and moving on.

As a result, I’ve used ACOs to model NPC swarm behavior for ground troops that respect mutual collisions, multiple openings, and group behavior that looks very convincing with minimal computation cost. It never would have occurred to me if I only saw it as a graph path optimization technique. I can also with an ACO from memory.

I do similar things when learning new languages. Start with something and focus on interactively refactoring it to be as idiomatic to the language as possible. For hybrid languages like Scala & Ocaml, I try different approaches and try to solve in as many ways as possible.

The only time I've ever "practiced" or "drilled" was when I was getting ready for interviews. This was as much as anything so I could get used to writing code on a whiteboard (although I actually typically just wrote out on paper).

Definitely do some serious practicing when I'm trying to learn a difficult piece of music, though.

When I was a student, I'd practice writing various search/sorting algorithms by hand to remember them in my free time (even after the tests) but reality set in where I don't need to be able to actually code these on the fly, so I stopped.

Reply on news.ycombinator.com